[arch-general] [aur-general] GHC 7.8.1 packaging decisions for Arch Linux

[Bardur Arantsson]

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,