Is it accurate to say that for a single user system, one could just alias cabal to use default mode of sandbox, and transparently ti would just work the same, but avoid cabal library conflicts? ------------------------------------------------------- Personally I'd like for it to be the default, but I don't if everyone agrees. If we make it the default, people who wanted a "global" install would have to use `cabal install --user`. On Fri, Nov 1, 2013 at 2:30 PM, Gregory Guthrie mailto:guthrie@mum.edu> wrote: "I *strongly* suggest everyone start transitioning from cabal-dev to cabal sandboxes." Is there any reason that this is not just the default install mode for Cabal? Anything that prevents the current cabal-swamp of broken dependencies is a great help. I have tried to use Haskell in some classes, but it is hard when students (and I) cannot install packages, and the only answer is the Microsoft-like; "delete everything and start over; reinstall". It certainly reduces their confidence that Haskell is a feasible working environment.

theres a bit of work planned out for the next year or so to make it so cabal can have reasonable "package manager" esque powers so you can evade many of the issues none sandboxed builds have. Theres also the flip side, that having sandboxed builds by default would make it none obvious how to install all sorts of neat CLI utils like pandoc! if you want to help out, get involved in cabal / cabal-install dev! they always need more people helping! :) --Carter On Fri, Nov 1, 2013 at 1:58 PM, Rogan Creswick wrote:

On Fri, Nov 1, 2013 at 6:30 AM, Gregory Guthrie wrote:

...

"I *strongly* suggest everyone start transitioning from cabal-dev to cabal sandboxes."

Is there any reason that this is not just the default install mode for Cabal?

I'm on the fence about this -- iirc, ruby has a similar concept (revn?) that has this default, and it can be quite confusing (and, in my experience, generates a fair bit of clutter, although that would probably go down with experience.)

Perhaps if cabal prompted for confirmation when creating a new sandbox (but only if running in an interactive context)? I could see my self inadvertently cabal-installing utilities (eg: newt, bnfc, etc...) in sandboxes on accident.

--Rogan

...

Anything that prevents the current cabal-swamp of broken dependencies is a great help. I have tried to use Haskell in some classes, but it is hard when students (and I) cannot install packages, and the only answer is the Microsoft-like; "delete everything and start over; reinstall". It certainly reduces their confidence that Haskell is a feasible working environment.

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

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

node.js's npm doesn't seem to have a problem with this. Sandboxed builds are the default, and when you want to install a tool globally you do it with npm -g. On Fri, Nov 1, 2013 at 11:09 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

theres a bit of work planned out for the next year or so to make it so cabal can have reasonable "package manager" esque powers so you can evade many of the issues none sandboxed builds have. Theres also the flip side, that having sandboxed builds by default would make it none obvious how to install all sorts of neat CLI utils like pandoc!

if you want to help out, get involved in cabal / cabal-install dev! they always need more people helping! :)

--Carter

On Fri, Nov 1, 2013 at 1:58 PM, Rogan Creswick wrote:

...

On Fri, Nov 1, 2013 at 6:30 AM, Gregory Guthrie wrote:

...

"I *strongly* suggest everyone start transitioning from cabal-dev to cabal sandboxes."

Is there any reason that this is not just the default install mode for Cabal?

I'm on the fence about this -- iirc, ruby has a similar concept (revn?) that has this default, and it can be quite confusing (and, in my experience, generates a fair bit of clutter, although that would probably go down with experience.)

Perhaps if cabal prompted for confirmation when creating a new sandbox (but only if running in an interactive context)? I could see my self inadvertently cabal-installing utilities (eg: newt, bnfc, etc...) in sandboxes on accident.

--Rogan

...

Anything that prevents the current cabal-swamp of broken dependencies is a great help. I have tried to use Haskell in some classes, but it is hard when students (and I) cannot install packages, and the only answer is the Microsoft-like; "delete everything and start over; reinstall". It certainly reduces their confidence that Haskell is a feasible working environment.

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

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

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

On Fri, Nov 01, 2013 at 01:31:33PM -0500, Gregory Guthrie wrote:

"I could see myself inadvertently cabal-installing utilities (eg: newt, bnfc, etc...) in sandboxes on accident.

What is wrong with this?

My guess is that Rogan was suggesting they wouldn't appear on the PATH.

On Fri, Nov 1, 2013 at 11:37 AM, Tom Ellis < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> wrote:

On Fri, Nov 01, 2013 at 01:31:33PM -0500, Gregory Guthrie wrote:

...

"I could see myself inadvertently cabal-installing utilities (eg: newt, bnfc, etc...) in sandboxes on accident.

What is wrong with this?

My guess is that Rogan was suggesting they wouldn't appear on the PATH.

That, and I don't want sandboxes scattered around in (somewhat) random places. I might later want a sandbox there for a specific purpose, and a pre-existing sandbox could confound things. Mostly I don't like clutter, and the tools wouldn't be on the PATH though. (To be clear, these *are* pretty minor complaints.) --Rogan

This. Actually the Mac brew folks are hitting this issue exactly. Subtlty being you want to be able to install bin and share assets both to a custom location. Unclear how to do that currently. On Friday, November 1, 2013, Tom Ellis wrote:

On Fri, Nov 01, 2013 at 06:37:13PM +0000, Tom Ellis wrote:

...

On Fri, Nov 01, 2013 at 01:31:33PM -0500, Gregory Guthrie wrote:

...

"I could see myself inadvertently cabal-installing utilities (eg: newt, bnfc, etc...) in sandboxes on accident.

What is wrong with this?

My guess is that Rogan was suggesting they wouldn't appear on the PATH.

I wonder if some compromise is possible whereby the binary builds in the sandbox but is installed to some user-wide location on the PATH.

Tom

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

I quite like the approach taken by 'brew' where you can 'link' and 'unlink' executables to and from a specific folder in the path: *brew install apple-gcc42

**brew link apple-gcc42 **brew unlink apple-gcc42 *

The installed package has the knowledge of what needs to be linked and unlinked to/from the path (btw, it is a path managed by brew in /usr/local/bin similar to .cabal/bin or Library/Haskell/bin) and it is quite easy to manage the path with it. On Fri, Nov 1, 2013 at 5:49 PM, Bob Ippolito wrote:

symlinks are generally how this gets "solved" in practice.

On Friday, November 1, 2013, Carter Schonwald wrote:

...

This.

Actually the Mac brew folks are hitting this issue exactly. Subtlty being you want to be able to install bin and share assets both to a custom location. Unclear how to do that currently.

On Friday, November 1, 2013, Tom Ellis wrote:

...

On Fri, Nov 01, 2013 at 06:37:13PM +0000, Tom Ellis wrote:

...

On Fri, Nov 01, 2013 at 01:31:33PM -0500, Gregory Guthrie wrote:

...

"I could see myself inadvertently cabal-installing utilities (eg: newt, bnfc, etc...) in sandboxes on accident.

What is wrong with this?

My guess is that Rogan was suggesting they wouldn't appear on the PATH.

I wonder if some compromise is possible whereby the binary builds in the sandbox but is installed to some user-wide location on the PATH.

Tom

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

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

As a noob to haskell, is there a tutorial or anything someone can point me to that's up to do date about how to use cabal with sandboxes? Now that I'm trying to do more than play around at the repl, I'm trying to get up to speed with cabal and the ecosystem, but all the tutorials I see either recommend cabal-dev or don't mention sandboxing at all. On Fri, Nov 1, 2013 at 1:34 PM, Carter Schonwald

wrote:

my prior email is about how the BREW folks are having a hard time using cabal sandboxing to support providing brew formulae for things like pandoc etc

On Fri, Nov 1, 2013 at 4:14 PM, Yuri de Wit wrote:

...

I quite like the approach taken by 'brew' where you can 'link' and 'unlink' executables to and from a specific folder in the path:

*brew install apple-gcc42

...

**brew link apple-gcc42 **brew unlink apple-gcc42 *

The installed package has the knowledge of what needs to be linked and unlinked to/from the path (btw, it is a path managed by brew in /usr/local/bin similar to .cabal/bin or Library/Haskell/bin) and it is quite easy to manage the path with it.

On Fri, Nov 1, 2013 at 5:49 PM, Bob Ippolito wrote:

...

symlinks are generally how this gets "solved" in practice.

On Friday, November 1, 2013, Carter Schonwald wrote:

...

This.

Actually the Mac brew folks are hitting this issue exactly. Subtlty being you want to be able to install bin and share assets both to a custom location. Unclear how to do that currently.

On Friday, November 1, 2013, Tom Ellis wrote:

...

On Fri, Nov 01, 2013 at 06:37:13PM +0000, Tom Ellis wrote:

...

On Fri, Nov 01, 2013 at 01:31:33PM -0500, Gregory Guthrie wrote: > "I could see myself inadvertently cabal-installing utilities (eg: newt, bnfc, etc...) in sandboxes on accident. > > What is wrong with this?

My guess is that Rogan was suggesting they wouldn't appear on the PATH.

I wonder if some compromise is possible whereby the binary builds in the sandbox but is installed to some user-wide location on the PATH.

Tom

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

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

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