Re: [Haskell-cafe] ANN: castle 0.1.0.0

On 16 January 2014 22:45, Eric Rochester 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 wrote:

...

On 16 January 2014 14:31, Eric Rochester 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 wrote:

...

On 16 January 2014 12:38, Eric Rochester 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" wrote:

...

On 16 January 2014 07:24, Eric Rochester 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@gmail.com http://IvanMiljenovic.wordpress.com

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com