[Haskell-cafe] ANN: castle 0.1.0.0
erochest at gmail.com
Thu Jan 16 03:31:02 UTC 2014
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
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 at metadecks.org> wrote:
> On 16 January 2014 12:38, Eric Rochester <erochest at 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.
>> On Jan 15, 2014 7:30 PM, "Ivan Lazar Miljenovic" <
>> ivan.miljenovic at gmail.com> wrote:
>>> On 16 January 2014 07:24, Eric Rochester <erochest at 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
>>> >> 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.
>>> >> keeps the package versions for all of these projects in line. It also
>>> >> 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
>>> >> system.
>>> > This tool is still pretty rough around the edges, but I've been using
>>> > 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 at gmail.com
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe