On 2014-04-09 09:07, Magnus Therning wrote:
Change 2: Make a news item stating that cabal-install is now the recommended way to install haskell packages. This wouldn't pollute the filesystem since cabal-install installs packages to the ~/.cabal directory by default. We might need to include a tip sheet about how you would handle ghc updates since it requires extra user steps.
It should be noted that cabal-install isn't a package manager in the true sense[1]. I'm not sure this is an argument against making the change you propose, but it's worth noting.
With sandboxing/hsenv I've actually found cabal-install it to work much better than attempting to use distro packages for some libraries. (There error messages for stuff that requires native C libraries aren't always stellar, but that's something you quickly get used to.)
There are quite a few other language/frameworks that have language-specific build/package systems, Python, Ruby, Perl, node.js... Are Python developers on Arch pointed towards using pip to install Python libs?
I can only speak to node.js, but I think the general consensus there is to only use the distro-provided node.js and npm and then have user-specific/project-specific node_modules directories. (This is driven in part by npm's design and the extreme pace at which the ecosystem seems to be moving.) Given the limitations of GHC when it comes to module interoperability between versions, I think this approach makes sense for GHC too. (Btw, there's work afoot to adress this, but it's probably a few years off: http://plv.mpi-sws.org/backpack/ )
I think sometimes the right thing is to point users to another package manager, e.g. packaging vim scripts for system wide installation is a bit silly, since installing a vim script affects ALL users on the system. So doing that would require providing some sort of vim-script manager to users. Then there's very little difference compared to just telling users to use Vundle/Pathogen/whatever directly instead. However, this isn't the case for Haskell/GHC...
AFAIK (and unfortunately) globally installed Haskell/GHC packages can greatly constrain what other packages you can install in a sandbox. That's been a huge problem for me in practice, which is why I personally always install ONLY ghc and cabal-install and use cabal sandboxing/hsenv for the rest. (Did this on Ubuntu as well when I was a user of that.) I think it would be a good idea to strip everything back to just having GHC and cabal-install in the "base" and to take some time to rethink how packaging everything else should work. I don't know if Cabal supports such a thing, but one idea off the top of my head for a new approach would be to have a distro-provided read-only *sandbox* which other read/write sandboxes could be *overlaid* on top of. That would mean that you could opt out of the distro-installed packages if you need to, but could still install distro packages if you, e.g. wanted/needed a Haskell program which depended on having haskell packages installed (git-annex?). Crazy idea? Regards,