This project is mirrored from Pull mirroring updated .
  1. 28 May, 2008 2 commits
    • Duncan Coutts's avatar
      First version of the top-down package dependency resolver · bc07102a
      Duncan Coutts authored
      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.
    • Duncan Coutts's avatar
  2. 21 May, 2008 2 commits
  3. 16 May, 2008 1 commit
  4. 12 May, 2008 1 commit
  5. 10 May, 2008 5 commits
  6. 09 May, 2008 6 commits
  7. 08 May, 2008 1 commit
    • Duncan Coutts's avatar
      Restructure the package installing code · 111e9bd0
      Duncan Coutts authored
      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.
  8. 07 May, 2008 10 commits
  9. 06 May, 2008 3 commits
  10. 05 May, 2008 2 commits
    • Duncan Coutts's avatar
      Switch from DepGraph to InstallPlan · 5d8d0d74
      Duncan Coutts authored
      The dependency resolver has had to be extended in a slightly hacky
      way to gather the extra information needed by an install plan. In
      particular it requires the flags to use to configure each package,
      the actual versions of dependencies to use and all of the
      installed packages and their closure of dependencies.
      However the current resolver is fairly naive and so can be easily
      persuaded into producing an invalid install plan, in which case
      you'll get a detailed list of reasons as to why it is invalid.
    • Duncan Coutts's avatar
  11. 04 May, 2008 4 commits
  12. 01 May, 2008 1 commit
  13. 30 Apr, 2008 2 commits
    • Duncan Coutts's avatar
      Remove the resolveDependenciesLocal, implement it via resolveDependencies · bbd4fca1
      Duncan Coutts authored
      The local variant was for the case that we were starting from a package
      description rather than a dependency to a named package. In the local
      case we not only need to resolve the dependencies of the package but also
      to find a flag assignment for the local package. This case crops up in
      the resolver normally when we try to satisfy a dependency, we have to
      pick a flag assignment for the dependency and resolve its dependencies.
      It is annoying to have both entry points, especially as we want the
      resolver to be plugable. So instead we define the local package as an
      available package, then by resolving a single dependency on exactly the
      name and version of the local package then we can get an install plan for
      the local package. It also requires generalising installPkg to deal with
      the local case.
    • Duncan Coutts's avatar
      Generalise and rename PkgInfo to include local packages · 55beae12
      Duncan Coutts authored
      Renamed to AvailablePackage since that what it is really.
      Now instead of just representing packages from a remote hackage repo
      it includes an alternative for a local unpacked package. In future
      we should add more alternatives, eg for other local packages (ie not
      just the one that's unpacked in the current dir) and for remote
      packages in source control like darcs, git etc.