[Haskell-cafe] ANN: castle 0.1.0.0

Thu Jan 16 13:51:32 UTC 2014

Sounds fine. It may be next week, but I'll see if I can add an add-source
command in.
Eric

On Thu, Jan 16, 2014 at 7:01 AM, Ivan Lazar Miljenovic <
ivan.miljenovic at gmail.com> wrote:

> On 16 January 2014 22:45, Eric Rochester <erochest at gmail.com> wrote:
> > 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.
>
> The cases I can think of:
>
> 1) Benchmarking against various libraries (release versions could be
> used, but unless I'm doing something wrong with my usage of
> cabal-install, unless I change the lower bound it doesn't bring in
> newer versions of libraries unless you explicitly tell it to, so by
> tracking HEAD you can make sure you're always comparing against the
> latest library verions).
>
> 2) Working on interrelated projects amongst several people: you
> yourself might not be working on a library foo that someone else is
> developing, but you know you need to make sure your code works against
> the latest version (either to be ready for when it releases or because
> you need functionality that isn't in a release of foo yet).
>
> 3) Related to the previous point: you've tracked down a regression in
> a dependency of your project, and so you're tracking its source repo
> to help its developer track down the problem (admittedly this one is a
> bit tenuous: either upstream can use your code to test, or you can
> manually sync the few times upstream thinks they might have a fix and
> see if it works, rather than needing it automated).
>
> >
> > 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
> >
> >
>
>
>
> --
> 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/575a7f5b/attachment.html>