[Haskell-cafe] ANN: castle 0.1.0.0

[Eric Rochester]

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 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.
>
> Conrad.
>
>
>> 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
>>> 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 at gmail.com
>>> http://IvanMiljenovic.wordpress.com
>>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140115/03b1bf33/attachment.html>