[Hackage] #289: symlink binaries into ~/bin
trac at galois.com
Sun Aug 3 09:43:19 EDT 2008
#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
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,
> > 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
> 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
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: Cabal and related projects
More information about the cabal-devel