Re: [Haskell-cafe] ANN: castle 0.1.0.0

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 wrote:

On 16 January 2014 12:38, Eric Rochester 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 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