[Haskell-cafe] ANN: castle 0.1.0.0

[Eric Rochester]

If the package lists a source repository, that shouldn't be too difficult.

But would it be helpful to do that in a shared sandbox? I'm trying to think
about when I use add-source, and I think that it's generally on a
project-specific basis.

But you have other uses cases, I'd be happy to consider it.

Eric



On Wed, Jan 15, 2014 at 11:05 PM, Ivan Lazar Miljenovic <
ivan.miljenovic at gmail.com> wrote:

> On 16 January 2014 14:31, Eric Rochester <erochest at gmail.com> wrote:
> > 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.
>
> There's been a utility I've been thinking of since I started using
> sandboxes (but haven't had enough of a need to write myself as yet):
> to automatically do a "git pull", "darcs pull", etc. for  dependencies
> if you're using "cabal sandbox add-source"  whilst developing based
> upon packages from HEAD.
>
> Would you consider adding such functionality to castle?
>
> >
> >
> >
> > 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
> >>>
> >>
> >
>
>
>
> --
> Ivan Lazar Miljenovic
> Ivan.Miljenovic at gmail.com
> http://IvanMiljenovic.wordpress.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140116/b5905e04/attachment-0001.html>