Re: cabal-install rebooted?

[Kosyrev Serge]

Bardur Arantsson  writes:

> On 09/09/2015 12:22 AM, Gershom B wrote:
>> That _does_ look simpler!
>> 
>> However, I think there are multiple efforts underway towards the
>> nix-style stuff. We had a GSoC on that for example. And in that
>> workflow, if it all works out properly, then we end up with a
>> situation where since the general-user-db has no conflicts, then
>> sandboxes are the tools that become generally not required.
>> 
>> So I would be quite hesitant about moving things in the other direction...
>> 
>
> I do see some advantages to having sandboxes still, namely isolation of
> the binaries into a single directory that you can put into $PATH, but
> I'm assuming/hoping there's some way to handle that in nix-style
> cabal/cabal-install as well. (If that turns out to be wrong, I imagine a
> middle-of-the-road approach here would be to just have a single package
> database and treat it as a simple cache of all the binaries ever
> compiled and we could still keep sandboxing for binaries and such..That
> might also nicely solve the problem of redudant compilation which
> happens with sandboxes now.)
>
> Just out of curiousity, when is the GSoC deadline?

Success was recently announced:

  https://www.mail-archive.com/cabal-devel%40haskell.org/msg10091.html

Excerpts:

,
| Cabal should never tell you it can't install a package because some
| reinstalls would be necessary.
`

,
| Try building things without a sandbox and see what happens!
| (When I test, I've tried installing multiple version of Yesod
| at the same time.)
`

-- 
с уважениeм / respectfully,
Косырев Серёга
--
“And those who were seen dancing were thought to be insane
 by those who could not hear the music.”
 – Friedrich Wilhelm Nietzsche
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Re: cabal-install rebooted?

[Bardur Arantsson]

On 09/09/2015 10:08 AM, Kosyrev Serge wrote:
> Bardur Arantsson  writes:
> 
>> On 09/09/2015 12:22 AM, Gershom B wrote:
>>> That _does_ look simpler!
>>>
>>> However, I think there are multiple efforts underway towards the
>>> nix-style stuff. We had a GSoC on that for example. And in that
>>> workflow, if it all works out properly, then we end up with a
>>> situation where since the general-user-db has no conflicts, then
>>> sandboxes are the tools that become generally not required.
>>>
>>> So I would be quite hesitant about moving things in the other direction...
>>>
>>
>> I do see some advantages to having sandboxes still, namely isolation of
>> the binaries into a single directory that you can put into $PATH, but
>> I'm assuming/hoping there's some way to handle that in nix-style
>> cabal/cabal-install as well. (If that turns out to be wrong, I imagine a
>> middle-of-the-road approach here would be to just have a single package
>> database and treat it as a simple cache of all the binaries ever
>> compiled and we could still keep sandboxing for binaries and such..That
>> might also nicely solve the problem of redudant compilation which
>> happens with sandboxes now.)
>>
>> Just out of curiousity, when is the GSoC deadline?
> 
> Success was recently announced:
> 
>   https://www.mail-archive.com/cabal-devel%40haskell.org/msg10091.html
> 

Thanks for the pointer. Not sure how I missed that.

Looks very promising -- I'll give it a whirl some time in the next few days.

Regards,

___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel