Commits on Jun 3, 2008
  1. Bump version number to help with bug reports

    The new resolver is a significant change in behavior so it's
    useful to know when people report problems.
    dcoutts committed Jun 3, 2008
  2. Switch the defaultResolver to the new topDownResolver

    Time for wider testing.
    dcoutts committed Jun 3, 2008
  3. Make the 'upgrade' command take optional deps

    Up to now 'upgrade' took no args and tried to upgrade all installed
    packages to the latest versions. It retains that mode but also has
    a new mode rather like 'cabal install'. The difference is that with
    $ cabal install foo
    it means install latest version of foo but otherwise prefer the
    installed versions of deps of foo, while
    $ cabal upgrade foo
    means install the latest version of foo and also the latest
    versions of all the dependencies of foo.
    dcoutts committed Jun 3, 2008
Commits on Jun 2, 2008
  1. Change the DependencyResolver type to take a per-package version pref

    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.
    dcoutts committed Jun 2, 2008
  2. Fix improvePlan so the index is updated incrementally

    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.
    dcoutts committed Jun 2, 2008
  3. Support top level dependency version constraints

    and error messages for when they're unsatisfiable or conflict
    dcoutts committed Jun 2, 2008
  4. Fix bug in passing the verbosity value when re-executing cabal

    It was passing the value as another argument, distinct from the flag.
    Saizan committed Jun 2, 2008
  5. Implement plan improvement

    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.
    dcoutts committed Jun 2, 2008
Commits on May 30, 2008
  1. As a heuristic, use topological order for the order of package choices

    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.
    dcoutts committed May 30, 2008
  2. Switch install to use resolveDependenciesWithProgress

    And show progress messages at verbosity level 2.
    dcoutts committed May 30, 2008
  3. Add resolveDependenciesWithProgress

    nd clean up header info
    dcoutts committed May 30, 2008
Commits on May 29, 2008
  1. Switch DependencyResolver to return Progress and String errors

    rather than Either and structured error type [Dependency]. The reason
    we cannot use that as a structured error type any more is because
    missing dependencies is not the only failure reason. There are
    several reasons, several of which are pretty complex. For now we'll
    have to do with a human readable message. Perhaps we may be able to
    find a common structured type that the different dep resolvers can
    all agree on. I'm not hopeful however as error reporting seems to be
    closely tied to the dep resolution approach.
    dcoutts committed May 29, 2008
  2. Use thisPackageVersion and notThisPackageVersion from Distribution.Pa…

    rather than the local definitions
    dcoutts committed May 29, 2008
Commits on May 28, 2008
  1. First version of the top-down package dependency resolver

    This is a new dependency resolver that produces valid install plans.
    It works in polynomial time however because the search space is 
    exponential in size it is not guaranteed to find a solution even if
    one exists. It works by generating and then exploring the search
    space represented as a lazy tree. It uses constraints to prune
    choices and heuristics when guesses are necessary. Currently it can
    generate install plans for 99% of the packages on hackage. The
    remaining 6 packages should be doable with two extra tricks.
    It is not finished and is not yet usable in practice.
    dcoutts committed May 28, 2008
Commits on May 21, 2008
  1. Hide any available base and ghc-prim packages from the dep resolver

    Previously if the base package was available on hackage then the dep
    resolver might try to upgrade it. Unfortunately that's almost
    certainly technically impossible at the moment. So now since the dep
    resolver does not see these available packages it cannot pick them.
    This should fix ticket #174.
    dcoutts committed May 21, 2008
Commits on May 16, 2008
Commits on May 12, 2008
  1. Update for distPref changes

    dcoutts committed May 12, 2008
Commits on May 10, 2008
  1. Move the upgrade action into the Install module

    It shares most code anyway.
    Also fixes ticket #260 becuase we use the right entry point now.
    dcoutts committed May 10, 2008
  2. Rewrite getUpgradableDeps so it's simpler and linear time

    Also change so that instead of giving the available package with
    the highest version number (where that is higher than the installed
    package) it gives us a dependency on a version of the package that
    is strictly greater than the one installed. This is more flexible
    since when resolving we do not necessarily have to pick the very
    latest version if that turns out not to be possible.
    dcoutts committed May 10, 2008
Commits on May 9, 2008
  1. Split the two resolvers out of the Dependency module

    It's clearer what is the generic stuff and what is specific to the
    current resolver. So it should be a bit easier to swap in new ones.
    dcoutts committed May 9, 2008
  2. Swap Either args so it's Either Error Ok

    Which seems to be the normal convention.
    dcoutts committed May 9, 2008
  3. Make the existing dep resolvers to use the DependencyResolver interface

    That is the standard naive dep resolver and the bogus one that has to
    make up a plan assuming that all dependencies are installed.
    dcoutts committed May 9, 2008
  4. Change the result type of DependencyResolver

    and add a wrapper that makes InstallPlans
    dcoutts committed May 9, 2008
  5. Change InstallPlan.done and .next into .ready that returns a list

    So kind of like uncons style rather than null and head.
    It returns all the ready ones by lazily so it's no extra expense.
    It'll allow parallel installations since all ready packages are
    independent of each other. Also update callers.
    dcoutts committed May 9, 2008
Commits on May 8, 2008
  1. Restructure the package installing code

    Previously each layer called the next layer down and therefore the
    top layer had to take all of the params that the bottom layer needed
    even though they were mostly or wholly unmodified on the way down.
    Now each layer takes the next layer as a parameter so we do not need
    to take the params that are not used directly by the current layer.
    The overall stack is then built by applying each layer to the next.
    dcoutts committed May 8, 2008
Commits on May 7, 2008
  1. executeInstallPlan now takes an installer instead of calling installPkg

    Four of the executeInstallPlan param were just passed through directly
    to installPkg so this decouples them a bit.
    dcoutts committed May 7, 2008