This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 10 Jun, 2008 4 commits
  2. 09 Jun, 2008 1 commit
  3. 08 Jun, 2008 3 commits
  4. 07 Jun, 2008 2 commits
    • Duncan Coutts's avatar
      Use a smarter preference when picking a Cabal lib to build Setup.hs · 9d650d2c
      Duncan Coutts authored
      Instead of just using the latest version we use the best version
      according to the following preferences in priority order:
      - the same version as cabal-install was itself built with
      - the same major version number as cabal-install was built with
      - a stable version of Cabal (even second digit of major number)
      - the latest version
      9d650d2c
    • Duncan Coutts's avatar
      Only inspect the needed parts of the installed and available indexes · 8d9cef62
      Duncan Coutts authored
      The available package index is loaded lazily so if we can avoid
      forcing all the packages then we can save a huge amount of slow text
      parsing. So select out the maximal subset of the index that we could
      ever need based on the names of the packages we want to install. For
      the common case of installing just one or two packages this cuts
      down the number of packages we look at by a couple orders of
      magnitude. This does not help with the installed index which is read
      strictly, though most people do not (yet) have hundreds of installed
      packages, so that's less of an immediate problem.
      8d9cef62
  5. 06 Jun, 2008 9 commits
  6. 05 Jun, 2008 1 commit
  7. 04 Jun, 2008 3 commits
  8. 03 Jun, 2008 10 commits
  9. 02 Jun, 2008 6 commits
    • Duncan Coutts's avatar
    • Duncan Coutts's avatar
      Change the DependencyResolver type to take a per-package version pref · df953acf
      Duncan Coutts authored
      And add a few global package version pref policies and use them in
      ordinary install and upgrade. For install we use a policy that says
      that we prefer the latest version of a package that we specifically
      request and prefer the installed version of any other package. For
      upgrade we simple always prefer the latest version. One can imageine
      other policies where we prefer the latest version for only some
      interesting subset of packages and installed otherwise.
      No resolvers actually make use of this preference yet.
      df953acf
    • Duncan Coutts's avatar
      Fix improvePlan so the index is updated incrementally · df947224
      Duncan Coutts authored
      It's important since later packages can depend on earlier ones having
      been changed from configured to pre-existing. That is afterall the
      whole point of considering them in reverse toplogical order.
      Also, remove duplicates in the dependencies list of installed
      packages since ghc-pkg does not currently prevent duplicates in (eg
      multiple depends on the same version of base). See ghc bug #2230.
      df947224
    • Duncan Coutts's avatar
      Support top level dependency version constraints · 6835d7f6
      Duncan Coutts authored
      and error messages for when they're unsatisfiable or conflict
      6835d7f6
    • Saizan's avatar
      Fix bug in passing the verbosity value when re-executing cabal · 8c63bd1a
      Saizan authored
      It was passing the value as another argument, distinct from the flag.
      8c63bd1a
    • Duncan Coutts's avatar
      Implement plan improvement · e3f09219
      Duncan Coutts authored
      The idea is to improve the plan by swapping a configured package for
      an equivalent installed one. For a particular package the condition
      is that the package be in a configured state, that a the same version
      be already installed with the exact same dependencies and all the
      packages in the plan that it depends on are in the installed state.
      e3f09219
  10. 30 May, 2008 1 commit
    • Duncan Coutts's avatar
      As a heuristic, use topological order for the order of package choices · 3f4868d1
      Duncan Coutts authored
      The general case in exploring the state space is that we have a set of
      choices (package names) and for each choice we have a number of
      versions of that package we could pick. If there's only one version of
      a package then we make that choice first. Otherwise we have to pick
      some package and select one of the available versions. The question is
      which package should we make a choice for first? Previously we picked
      completely arbitrarily. Surprisingly this actually works pretty well.
      An improvement is to pick packages in topological order. This works
      better because it allows dependencies from earlier choices to
      constrain our later choices.
      3f4868d1