That's one use case that I've used some.

Another motivation has been to make it easier and faster to get started on a new project. I may want to do a relatively small web app or command-line utility. It shouldn't take long. But if I require any of a number of larger (but very useful) packages, then installing them into a new sandbox does take a while. This short-circuits that and lets me get started on the project itself almost immediately.

After the project's going, I often find that I switch over to a sandbox in the project directory, but I can do that after I've moved on to another task.

Basically it allows me to get started on a project very quickly while still having the benefits of sandboxes.



On Wed, Jan 15, 2014 at 9:47 PM, Conrad Parker <conrad@metadecks.org> wrote:


On 16 January 2014 12:38, Eric Rochester <erochest@gmail.com> wrote:

It doesn't differ at all. In fact, that's just what it does. It's just a  management utility keeping all of the sandboxes in one place.

Overkill? Certainly.

It doesn't sound like overkill to me -- cabal gives a mechanism for having sandboxes, but doesn't impose any policy about why you would use them.
 
Is the point that you maintain multiple sandboxes, like a lens sandbox and a yesod sandbox; and this tool makes it easier to manage those? ie. you might maintain separate lens-3.9 and lens-3.10 sandboxes, and when compiling a new project that uses lens, choose the appropriate lens sandbox.

Conrad.
 
On Jan 15, 2014 7:30 PM, "Ivan Lazar Miljenovic" <ivan.miljenovic@gmail.com> wrote:
On 16 January 2014 07:24, Eric Rochester <erochest@gmail.com> wrote:
> I'd like to announce the first release of castle
> (http://hackage.haskell.org/package/castle and
> https://github.com/erochest/castle). From the README:
>>
>> I really like having sandboxes baked into cabal-install (see Cabal
>> Sandboxes for more information).
>>
>> I got tired of waiting for big packages like Yesod and Lens to compile in
>> project after project that used them. However, I still didn't want to
>> install them in the user database. I wanted to maintain some sandboxing
>> among a group of projects that all share a common set of packages, but I
>> wanted to be able to switch from them or upgrade them easily.
>>
>> That's the itch I was trying to scratch with castle.
>>
>> It allows you to share one Cabal sandbox between multiple projects. This
>> keeps the package versions for all of these projects in line. It also means
>> that you don't have to constantly be re-installing everything, but you still
>> get the ability to blow away a set of packages without borking your whole
>> system.
>
>
> This tool is still pretty rough around the edges, but I've been using it
> some, and it's to the point that more feedback would be helpful. Let me know
> what bugs and rough patches you find.

How does this differ from doing "cabal sandbox init
--sandbox=../my-common-sandbox" for all these projects?

--
Ivan Lazar Miljenovic
Ivan.Miljenovic@gmail.com
http://IvanMiljenovic.wordpress.com

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe