haskell package layout: a proposal

[Neil Mitchell]

Hi

> I think I can summarize the feedback and concerns expressed on the reddit discussion, the blog's comments, and here on the mailing list:
>
> 0) "Nice proposal", "I heartily recommend it.", 28 up votes, 2 down (93%)

I should say, I voted that up because it looked interesting (and it
does). However, voting up meant it was interesting, not that I
reviewed the proposal and that it answers everyone's needs :-)

> 1) Executables should be on the user's path.
> 2) need to be sure to rebuild haddock index, and per tree
>
> Both of these are about "making things just work". I agree. The binaries on the path *is* something we should preserve, and cabal
> already supports the symlink-bindir feature for just this reason. It allows one to put the binaries in one place, and symlink them into a
> bin directory on the $PATH. Such a scheme facilities easy removal in the future (kill the appropriate install tree, then remove broken
> symlinks in the $PATH bin dir -- otherwise you have know which binaries were in the package or packages you just deleted...)

Remember Windows when doing these steps. Symlinks on Windows is a bad
idea (they are technically supported on some file systems, but in
practice they aren't a great idea, since no tools can work with them).

> Keeping the haddock index up-to-date is also very important, and again, cabal-install already does this, though I believe it only ever
> updates the --user index. For distributions, distributing a built index for the distributed --global docs is important. I suspect we all have
> little scripts for doing this. I'll try generalizing mine and making them available to packagers.

There is more per-package data than just the haddocks - there are also
hoogle databases for packages. It's not critical, but if you keep that
in mind when designing things it would be a lovely bonus.

> 5) By putting non-executable data in a separate place, it can be shared from a central server to machines with multiple architectures.
> 6) Compiler isn't specific enough: need os-processor-abi etc...
> 7) Cabal's dist structure is problematic in some cases.
>
> These are concerns mostly for people building and installing in special environments. The vast majority of installs are on single user
> machines, with a single architecture. And .cabal/conf can still be customized to support any layout one can achieve now.

Many Windows machines end up being per user because of permissions,
often only admin can write to shared areas.

Thanks, Neil