<div dir="ltr"><div>If the package lists a source repository, that shouldn't be too difficult.<br><br>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.<br>
<br>But you have other uses cases, I'd be happy to consider it.<br><br></div>Eric<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 15, 2014 at 11:05 PM, Ivan Lazar Miljenovic <span dir="ltr"><<a href="mailto:ivan.miljenovic@gmail.com" target="_blank">ivan.miljenovic@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 16 January 2014 14:31, Eric Rochester <<a href="mailto:erochest@gmail.com">erochest@gmail.com</a>> wrote:<br>
> That's one use case that I've used some.<br>
><br>
> Another motivation has been to make it easier and faster to get started on a<br>
> new project. I may want to do a relatively small web app or command-line<br>
> utility. It shouldn't take long. But if I require any of a number of larger<br>
> (but very useful) packages, then installing them into a new sandbox does<br>
> take a while. This short-circuits that and lets me get started on the<br>
> project itself almost immediately.<br>
><br>
> After the project's going, I often find that I switch over to a sandbox in<br>
> the project directory, but I can do that after I've moved on to another<br>
> task.<br>
><br>
> Basically it allows me to get started on a project very quickly while still<br>
> having the benefits of sandboxes.<br>
<br>
</div>There's been a utility I've been thinking of since I started using<br>
sandboxes (but haven't had enough of a need to write myself as yet):<br>
to automatically do a "git pull", "darcs pull", etc. for dependencies<br>
if you're using "cabal sandbox add-source" whilst developing based<br>
upon packages from HEAD.<br>
<br>
Would you consider adding such functionality to castle?<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
><br>
> On Wed, Jan 15, 2014 at 9:47 PM, Conrad Parker <<a href="mailto:conrad@metadecks.org">conrad@metadecks.org</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On 16 January 2014 12:38, Eric Rochester <<a href="mailto:erochest@gmail.com">erochest@gmail.com</a>> wrote:<br>
>>><br>
>>> It doesn't differ at all. In fact, that's just what it does. It's just a<br>
>>> management utility keeping all of the sandboxes in one place.<br>
>>><br>
>>> Overkill? Certainly.<br>
>><br>
>> It doesn't sound like overkill to me -- cabal gives a mechanism for having<br>
>> sandboxes, but doesn't impose any policy about why you would use them.<br>
>><br>
>> Is the point that you maintain multiple sandboxes, like a lens sandbox and<br>
>> a yesod sandbox; and this tool makes it easier to manage those? ie. you<br>
>> might maintain separate lens-3.9 and lens-3.10 sandboxes, and when compiling<br>
>> a new project that uses lens, choose the appropriate lens sandbox.<br>
>><br>
>> Conrad.<br>
>><br>
>>><br>
>>> On Jan 15, 2014 7:30 PM, "Ivan Lazar Miljenovic"<br>
>>> <<a href="mailto:ivan.miljenovic@gmail.com">ivan.miljenovic@gmail.com</a>> wrote:<br>
>>>><br>
>>>> On 16 January 2014 07:24, Eric Rochester <<a href="mailto:erochest@gmail.com">erochest@gmail.com</a>> wrote:<br>
>>>> > I'd like to announce the first release of castle<br>
>>>> > (<a href="http://hackage.haskell.org/package/castle" target="_blank">http://hackage.haskell.org/package/castle</a> and<br>
>>>> > <a href="https://github.com/erochest/castle" target="_blank">https://github.com/erochest/castle</a>). From the README:<br>
>>>> >><br>
>>>> >> I really like having sandboxes baked into cabal-install (see Cabal<br>
>>>> >> Sandboxes for more information).<br>
>>>> >><br>
>>>> >> I got tired of waiting for big packages like Yesod and Lens to<br>
>>>> >> compile in<br>
>>>> >> project after project that used them. However, I still didn't want to<br>
>>>> >> install them in the user database. I wanted to maintain some<br>
>>>> >> sandboxing<br>
>>>> >> among a group of projects that all share a common set of packages,<br>
>>>> >> but I<br>
>>>> >> wanted to be able to switch from them or upgrade them easily.<br>
>>>> >><br>
>>>> >> That's the itch I was trying to scratch with castle.<br>
>>>> >><br>
>>>> >> It allows you to share one Cabal sandbox between multiple projects.<br>
>>>> >> This<br>
>>>> >> keeps the package versions for all of these projects in line. It also<br>
>>>> >> means<br>
>>>> >> that you don't have to constantly be re-installing everything, but<br>
>>>> >> you still<br>
>>>> >> get the ability to blow away a set of packages without borking your<br>
>>>> >> whole<br>
>>>> >> system.<br>
>>>> ><br>
>>>> ><br>
>>>> > This tool is still pretty rough around the edges, but I've been using<br>
>>>> > it<br>
>>>> > some, and it's to the point that more feedback would be helpful. Let<br>
>>>> > me know<br>
>>>> > what bugs and rough patches you find.<br>
>>>><br>
>>>> How does this differ from doing "cabal sandbox init<br>
>>>> --sandbox=../my-common-sandbox" for all these projects?<br>
>>>><br>
>>>> --<br>
>>>> Ivan Lazar Miljenovic<br>
>>>> <a href="mailto:Ivan.Miljenovic@gmail.com">Ivan.Miljenovic@gmail.com</a><br>
>>>> <a href="http://IvanMiljenovic.wordpress.com" target="_blank">http://IvanMiljenovic.wordpress.com</a><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Haskell-Cafe mailing list<br>
>>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
>>><br>
>><br>
><br>
<br>
<br>
<br>
--<br>
Ivan Lazar Miljenovic<br>
<a href="mailto:Ivan.Miljenovic@gmail.com">Ivan.Miljenovic@gmail.com</a><br>
<a href="http://IvanMiljenovic.wordpress.com" target="_blank">http://IvanMiljenovic.wordpress.com</a><br>
</div></div></blockquote></div><br></div>