[Haskell-cafe] ANN: castle 0.1.0.0

Thu Jan 16 12:01:28 UTC 2014

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