[Hackage] #645: confusing interface: cabal "install" subcommand has two clashing meanings

[Hackage]

#645: confusing interface: cabal "install" subcommand has two clashing meanings
---------------------------------+------------------------------------------
  Reporter:  StefanK             |        Owner:         
      Type:  defect              |       Status:  new    
  Priority:  normal              |    Milestone:         
 Component:  cabal-install tool  |      Version:  1.6.0.1
  Severity:  normal              |     Keywords:         
Difficulty:  unknown             |   Ghcversion:         
  Platform:                      |  
---------------------------------+------------------------------------------

Comment(by StefanK):

 Replying to [comment:2 duncan]:
 > 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

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