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

[Hackage]

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

 Replying to [comment:10 igloo]:
 > Does anything else automatically install into `~/bin`? I always assumed
 that it being in the path by default was just to make things easier for
 users who wanted to put things there.
 >
 > Incidentally, I don't think you shouldn't touch it /at all/, but that
 you shouldn't touch it without being explicitly told you can (e.g. "I see
 you haven't made a .cabal/config yet. Do you want me to make one for you?
 [Yn] Do you want me to automatically symlink binaries into ~/bin?" [Yn]).

 As we've already seen, ~/bin is by no means a standard (I use ~/local/bin
 myself, so ~/bin would be pointless for me).  But typically when you tell
 a build system to "install", you expect it's going to put its stuff where
 it needs to to be found.  Fortunately for the Haskell libraries this can
 be in cabal's own private area, but binaries don't have that luxury.
 Compare GNU Automake: when you run ./configure without --prefix, it
 assumes /usr/local.  When you run "sudo make install" you know full well
 it's putting stuff in system directories (polite makefiles will also
 uninstall, which is nice).  Or if you don't have superuser access, it
 gives you an error message saying it can't write where it wants to, and
 the user needs to either run it again as su, or else re./configure with a
 new, writable, prefix.  And this intentional re-prefixing means he'll pick
 somewhere that he *knows* has a bindir in the path.

 I point all this out because as I see it, cabal-install is broken out of
 the box.  A naive user (like myself a few weeks ago) will download Cabal
 and cabal-install, along with their dependencies, from Hackage, and
 install cabal-install (which ends up in /usr/local by default, a
 reasonably sane place).  He'll be excited that packages now install
 painlessly and won't bother looking at any of the config files, because
 things basically seem to "just work".  Then, whenever cabal-install
 attempts to meet a binary dependency, it appears to run in an endless
 loop, repeatedly installing the same software but with no effect.  In my
 case, I didn't even realize Alex was a binary, so I installed it easily
 ten times before I realized what was happening - I imagine many others
 might take much longer.  In any case, not one warning or error was raised
 during this time (other than "can't find Alex", which I thought I'd just
 installed), because the current warning is only issued when there's a
 symlink-bindir specified, when by default there is none.

 I sent in a couple patches (one to Cabal and one to cabal-install) to
 address some of these issues, but I'm not sure if anyone saw them.  I can
 resend them if anyone would like.  But I'll summarize what I think should
 be done:

 1. cabal-install needs to either
   * be more pushy in the user's homedir -- people don't like this,[[BR]]
   * be more stubborn with its default prefix, like automake, or[[BR]]
   * issue clear warning messages *out of the box* when binaries are
 installed outside the path (this is what I implemented in the patch I
 sent).
 2. Cabal should find some way to look inside cabal-install's bindir
 whether it's on the PATH or not.  I implemented this in a somewhat clunky
 way in the other patch I sent (which I'm almost positive didn't make it
 onto cabal-devel), but it could be done better (at least on Posix systems
 - do Windows systems have similar issues, or is this a Unix-only problem?)
 with System.Posix.setEnv: cabal-install can just insert its bindir into
 the PATH before passing control along to Cabal.

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