Eric Rochester | 15 Jan 21:24 2014
Picon

ANN: castle 0.1.0.0

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.

Thanks,
Eric
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Ivan Lazar Miljenovic | 16 Jan 01:30 2014
Picon

Re: ANN: castle 0.1.0.0

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
Christopher Allen | 16 Jan 01:45 2014

Re: ANN: castle 0.1.0.0

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

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Eric Rochester | 16 Jan 02:38 2014
Picon

Re: ANN: castle 0.1.0.0

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" <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
Conrad Parker | 16 Jan 03:47 2014

Re: ANN: castle 0.1.0.0



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


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Eric Rochester | 16 Jan 04:31 2014
Picon

Re: ANN: castle 0.1.0.0

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



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Ivan Lazar Miljenovic | 16 Jan 05:05 2014
Picon

Re: ANN: castle 0.1.0.0

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
Eric Rochester | 16 Jan 12:45 2014
Picon

Re: ANN: castle 0.1.0.0

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

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Ivan Lazar Miljenovic | 16 Jan 13:01 2014
Picon

Re: ANN: castle 0.1.0.0

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
Eric Rochester | 16 Jan 14:51 2014
Picon

Re: ANN: castle 0.1.0.0

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

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

Gmane