[Hackage] #289: symlink binaries into ~/bin

[Hackage]

#289: symlink binaries into ~/bin
---------------------------------+------------------------------------------
  Reporter:  duncan              |        Owner:                     
      Type:  enhancement         |       Status:  new                
  Priority:  normal              |    Milestone:  Cabal-1.4          
 Component:  cabal-install tool  |      Version:                     
  Severity:  normal              |   Resolution:                     
  Keywords:                      |   Difficulty:  very easy (<1 hour)
Ghcversion:  6.8.2               |     Platform:                     
---------------------------------+------------------------------------------
Comment (by duncan):

 Replying to [comment:5 Isaac Dupree]:

 > (1. It's on my `$PATH`)

 > 2. so that I can explicitly invoke `~/.cabal/bin/alex` without giving a
 version number, maybe?  What I don't want is the "unversioned" feature to
 be combined in an essential way with another feature that I don't want.  I
 suppose I could put my symlink-bindir as `$HOME/.cabal/unversioned-bin`,
 but that seems like it would be messing with cabal's area a bit without
 its permission.

 I guess you can tell cabal to put symlinks in ~/.cabal/bin instead of
 ~/bin and to use versioned binaries. Would that do?

 The features are quite separate. You can install versioned binaries or
 not. You can add symlinks to some other dir or not. (You're not restricted
 to versioned binaries, you can specify arbitrary prefixes and suffixes on
 binaries and they can contain vars like the package name, version,
 compiler, etc).

 > > I don't think we should ignore a `~/bin` just because it is a symlink.
 Users who don't want the feature can easily turn it off in the
 `~/.cabal/config`.
 >
 > Only if you tell anyone who installs a binary that they can turn off the
 feature there, and how, and how to clean up the mess that cabal has
 already made... (unless you ask the user first)

 Mess what mess? There will be some symlinks in `~/bin` pointing to
 `~/.cabal/bin`. Using `ls -l` they will be easily identifiable if you want
 to delete them.

 > > I'm not sure what you mean about trampling, we're being pretty careful
 not to trample anything. By default we only touch `~/.cabal` and are
 careful with setting symlinks in `~/bin` so that we do not overwrite
 anything created by the user or any other program.
 >
 > It's because I'm paranoid about that, because I prefer to have full
 control over what is in my home filesystem structure, separate from what
 programs want to automatically store.  True, the proposed system won't
 delete any important data, so the worst that can happen is that I don't
 notice for a while, it causes a little havoc when some GHC build uses a
 version of Alex that I didn't expect (e.g. if I installed Alex through my
 system's package manager), and eventually I have to figure out what
 happened, clean up the mess, and if I'm feeling lucky, find out how I can
 turn it off in the cabal config file.

 This should just work. You have `/usr/bin` in your `$PATH` before
 `$HOME/bin` so the alex you get will be the one installed by your system
 package manager, not the one installed by Cabal.

 > This is no figment of my imagination -- I only went to such a weird-
 looking scheme because of repeated problems with miscellaneous programs
 that I maybe only used once (it became even worse on Ubuntu where things
 run even when you don't explicitly configure them to, AND make a mess in
 `$HOME`).  By all means, go ahead and do things automatically in Cabal for
 the users that like that, because I've lost all trust in that sort of
 thing and I've found a way to avoid it (so far, I've never had a problem
 with different programs messing with $HOME in ways that they break each
 other automatically -- that would be more difficult to deal with :-).
 Grudging thanks for reminding me never to put anything of my own in
 `$HOME`, unless it's modifying a config-file in `$HOME/.something` that
 can't be stored elsewhere.

 Ok, but do you have any specific problems with what we're proposing? If so
 what is your suggestion for the best default behavior?

 > er, sorry for the rants, did it explain anything?  I think if all
 programs had always been as polite as Cabal is planning to be, I ''might''
 have appreciated it doing that automatically...

 So you mean this sounds ok?

 > Anyway, which version are you planning to symlink as the unversioned
 one?  The one with the greatest version?  Is there a way to modify that,
 that'll last longer than just changing the symlink target?

 The one that was just requested to be installed. No way to modify it yet,
 no, except by changing the symlink yourself. This is no worse than before
 where the binaries would just overwrite each other. Of course you can not
 symlink and just put `$HOME/.cabal/bin` on your `$PATH` and use versioned
 binaries in there in which case all versions will be available all the
 time.

 We're not really so concerned with people who know what they're doing,
 except to the extent that we do not annoy them. What we want is for things
 to "Just Work"(tm) for users who don't know and don't care. The current
 behavior of installing just to `~/.cabal/bin` fails that test.

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