[Hackage] #688: adopt XDG basedir spec

[Hackage]

#688: adopt XDG basedir spec
---------------------------------+------------------------------------------
  Reporter:  guest               |        Owner:         
      Type:  enhancement         |       Status:  new    
  Priority:  low                 |    Milestone:         
 Component:  cabal-install tool  |      Version:  1.8.0.4
  Severity:  normal              |     Keywords:         
Difficulty:  hard (< 1 day)      |   Ghcversion:  6.10.4 
  Platform:  Linux               |  
---------------------------------+------------------------------------------

Comment(by duncan):

 Replying to [comment:6 Syzygies]:

 > A related piece of de facto convention comes up here: It is crazy to
 sprinkle pieces of a system like GHC into separate global locations like
 /usr/local/bin, /usr/local/share, unless one will only ever use one
 version, with no desire to look under the hood or move the installation.
 In other words, I have no issue with Linux or OS X shipping this way, but
 major additions should be localized by default. Some are, e.g. TeX. GHC
 should.

 You can already do this if you want to. You just set the --prefix to be
 what you want, e.g. instead of using /usr/local as the prefix, use
 /opt/ghc/6.12.1 or whatever, then you'll get paths like
 `/opt/ghc/6.12.1/bin`, `/opt/ghc/6.12.1/lib`, `/opt/ghc/6.12.1/share` etc
 etc.

 > Fortunately, to avoid Siamese twin installations with accidentally
 shared parts, one can use the ./configure --prefix option while building
 GHC. Then, it becomes apparent that "cabal install" is the remaining
 holdout to ideal version localization. There is a perfect storm of tiny
 factors keeping Cabal from gracefully localizing. I wanted to elicit
 advice before contributing a fix; this ticket seems to have touched on a
 key issue.

 > I did not know about the "--config-file=..." command-line option; I will
 start using it in scripts. However, we need a better default for global
 installs.

 The "default" default, should follow global conventions, meaning using
 /usr/local. Again you can override the prefix and all other install
 directories.

 It's true that there is not currently a sensible way to have a global
 cabal config file, in the style of /etc/cabal or something like that.
 Following the XDG spec in that regard might make some sense.

 > Environment variables are one "right" way to handle this. In short, a
 symbolic link is like changing state, while environment variables are like
 functional programming.

 You mean you would like an environment variable to set the location of the
 Cabal config file? You can set the `$CABAL_CONFIG`, it acts like setting
 the "--config-file=..." option.

 > However, not only does .cabal/config fail to allow external environment
 variables, it doesn't allow forms like one sees in its own comments. (Who
 reads documentation? We all read sample code.) For example, even though I
 see the comment "-- bindir: $prefix/bin" I cannot write "remote-repo-
 cache: $prefix/packages". I would prefer to be able to write anything that
 would evaluate correctly in a shell to an absolute path, e.g. `which ghc`
 or `perl -pe ...` and so forth.

 The prefix is something that makes sense in the context of an
 installation. It is not clear that basing the cache location on that makes
 sense. It means for example that it will not find the default cache if you
 override the --prefix on the command line. Perhaps what you really want to
 do is to specify the default prefix and cache dirs in the config file
 based on some other variable, rather than having the cache dir follow the
 prefix.

 > Ideally, a global install would by default use a global location for the
 Cabal config file,

 Do you mean an install run as root, or do you mean an install run as a
 user? Or do you mean that you'd like to be able to have a shared/global
 set of connfig defaults that can be overridden in per-user config files?


 As a user when you run `cabal install --global --su-cmd=sudo` you're using
 your own config, but installing to a global location (the exact prefix etc
 is set in the config file). It does the build as user and installs as
 root.

 > but we slam back into the original problem: By default the global
 install of GHC did not use the --prefix option, so there is no well-
 defined location parametrized by the version of GHC.

 You can either use versioned ghc binaries, (called `ghc-6.10.4`,
 `ghc-6.12.1` etc) in a shared prefix like `/usr/local` or as I described
 above you can use separate prefixes for different ghc installations. Note
 that by default, cabal installs libs in dirs including the ghc version, so
 it all works. As mentioned before you have complete control over the
 prefix (and other detailed layout of bindir etc) so you can put files
 where you like, according to some ghc version scheme. You can use the
 compiler id in the cabal prefix for example.

 > The simplest change that would help my issue would be to allow both
 absolute and relative paths in .cabal/install, with a relative path
 relative to the location of `which ghc`.

 Honestly I don't think that is sensible. Allowing people to use more
 variables so that you can specify a prefix that happens to correspond to
 your ghc installation is one thing, making that the meaning for relative
 paths is rather another. Usually you do not want to install things into
 the ghc tree, so using relative paths would encourage that dangerous
 behaviour.

 > However, it just shouldn't matter which authorized user works on a
 global install. Relying on ~/.cabal/config for a global install should be
 viewed as a bug, as it prevents several admins from cooperating in
 consistently maintaining GHC on a shared system.

 I don't understand this bit. Perhaps you can explain what config you would
 like to use for global installs. Where would it live? Do you assume global
 installs are only performed by root?

 I think it would help if you could explain what you're actually trying to
 achieve. The mailing list might be the better place for that discussion.

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/688#comment:7>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects