confusing interface: cabal "install" subcommand has two clashing meanings #638

Open
bos opened this Issue May 24, 2012 · 5 comments

Comments

Projects
None yet
1 participant
Contributor

bos commented May 24, 2012

(Imported from Trac #645, reported by StefanK on 2010-03-19)

This is not a duplicate of #601. Installing a package with

rm -rf ~/.ghc ~/.cabal
cabal clean
cabal configure --user --prefix="${HOME}/opt"
cabal build
cabal install
will install the binaries in '/home/sk/.cabal/bin' instead of '/home/sk/opt/bin'.

I'll attach a toy project demonstrating this.

System:

sk@watarrka:~> ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.1
sk@watarrka:~> cabal --version
cabal-install version 0.8.0
using version 1.8.0.2 of the Cabal library
Contributor

bos commented May 24, 2012

(Imported comment by StefanK on 2010-03-19)

toy cabal project

Contributor

bos commented May 24, 2012

(Imported comment by @dcoutts on 2010-03-19)

Replying to StefanK:

{{{ rm -rf ~/.ghc ~/.cabal cabal clean cabal configure --user --prefix="${HOME}/opt" cabal build cabal install }}} will install the binaries in '/home/sk/.cabal/bin' instead of '/home/sk/opt/bin'.

So what is confusing here is that cabal install does everything. It configures, builds and installs. In particular because it configures, it takes all the configuration options and overrides any previous configure. So it will work as expected if you do:

cabal clean
cabal install --user --prefix="${HOME}/opt"
The problem is that we have two clashing meanings for install. There's the original meaning from the simple single package setting, where it means "assume we have configured and built, now install". The package manager meaning is "configure, build and install this package, and all of its dependencies".

The question is how we reconcile these two meanings. One might imagine that we could tell if the package is already configured and not-reconfigure. In general, for an arbitrary build system that's not really possible.

Suggestions welcome.

Another option might be for cabal install to use the saved configuration rather than a fresh configuration.

Contributor

bos commented May 24, 2012

(Imported comment by StefanK on 2010-03-27)

Replying to @dcoutts:

So it will work as expected if you do: {{{ cabal clean cabal install --user --prefix="${HOME}/opt" }}}

Thank you very much, that worked.

The question is how we reconcile these two meanings. One might imagine that we could tell if the package is already configured and not-reconfigure. In general, for an arbitrary build system that's not really possible. Suggestions welcome.

This is what I personally would expect from a user's perspective: The order of precedence should be:

  1. command line arguments.
  2. previous run of cabal configure.
  3. The user's ~/.cabal/config.
  4. Maybe some global setting, e.g., /etc/cabal/config.
  5. Cabal's builtin defaults.
An algorithm to achieve this for cabal install would be reading the sources in reverse order, each read overwriting settings from a previous read, silently skipping sources that don't exist:
  1. Initialise with builtin settings.
  2. If /etc/cabal/config exists read it, and adopt everything it says.
  3. If ~/.cabal/config exists read it, and adopt everything it says.
  4. If there was a previous cabal configure read it, and adopt everything it says. If we cannot determine whether there was a previous configure, act as if there was none.
  5. Read command line arguments, and adopt everything they say.
An algorithm for cabal configure would work identically, i.e., reuse settings from a previous cabal configure. Of course, cabal clean should remove settings provided by a previous cabal configure.

Kind regards,
Stefan

Contributor

bos commented May 24, 2012

(Imported comment by @dcoutts on 2010-03-27)

See also #802 about consequences of people using cabal copy instead of cabal install.

Contributor

bos commented May 24, 2012

(Imported comment by @kosmikus on 2011-02-11)

There is cabal install --only now, which could be documented better. It is still confusing behaviour for users who don't know about it, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment