ANN: castle 0.1.0.0

Eric Rochester

15 Jan 2014 15 Jan '14

3:24 p.m.

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-installhttp://hackage.haskell.org/package/cabal-install(see Cabal Sandboxes http://coldwa.st/e/blog/2013-08-20-Cabal-sandbox.html for more information).

I got tired of waiting for big packages like Yesodhttp://www.yesodweb.com/and Lens http://hackage.haskell.org/package/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. Thanks, Eric

Attachments:

attachment.html (text/html — 1.7 KB)

Show replies by date

Ivan Lazar Miljenovic

15 Jan 15 Jan

7:30 p.m.

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

Christopher Allen

7:45 p.m.

I typically do the same, fairly frequently, using a Makefile to handle configuring builds/cabal/whatever to all point to the same sandbox or pulling it from my environment variables. On Wed, Jan 15, 2014 at 4:30 PM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> 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

Eric Rochester

8:38 p.m.

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. 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

Conrad Parker

9:47 p.m.

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" < ivan.miljenovic@gmail.com> 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

Eric Rochester

10:31 p.m.

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 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" < ivan.miljenovic@gmail.com> 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

11:05 p.m.

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

Eric Rochester

16 Jan 16 Jan

6:45 a.m.

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@gmail.com> 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

7:01 a.m.

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

Eric Rochester

8:51 a.m.

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@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

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

...
...
...
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

...
...
...
...
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

started them. 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

4148

Age (days ago)

4149

Last active (days ago)

List overview

Download

9 comments

4 participants

participants (4)

Christopher Allen
Conrad Parker
Eric Rochester
Ivan Lazar Miljenovic

ANN: castle 0.1.0.0

Eric Rochester

Ivan Lazar Miljenovic

Christopher Allen

Eric Rochester

Conrad Parker

Eric Rochester

Ivan Lazar Miljenovic

Eric Rochester

Ivan Lazar Miljenovic

Eric Rochester

tags

participants (4)