Draft of a GSoC proposal: Cabali!

gistfile1.md

Improve the feedback of the cabal-install dependency solver

GSoC Questions

• What is the goal of the project you propose to do?

  The dependency solver can be a mysterious piece of the installation process. I want to give the user the possibility to see what is happening and also give them a better chance to understand what happened if something does not just work. Further, I would like to enable them to use that information to fix the installation in some cases.

• In what ways will this project benefit the wider Haskell community?

  Installing and using packages is arguably one of the most important features in any programming environment. I would like to make it a little less painful in case it does not run as smoothly as intended.

• Can you give some more detailed design of what precisely you intend to achieve?

  The main goals are to give the user more and also more useful information about the installation process, while also enabling the user to influence the process. In the following I describe the means as to how I want to achieve that.

  • Create a simple IDE (ghci style) to interactively walk the dependency tree. This part requires very little and very local changes to the existing codebase and mostly adds new functionality without replacing old. Hence the aim is to have that part included into the HEAD repository by the end of the summer.

    The IDE should allow to

    • (Basic functionality) manually choose versions/flags at every step of the solving process. Including choices the solver would not allow. Provide the ability to step back in the tree.
    • (Advanced) set breakpoints and include more advanced, semiautomated steps. Provide tools to help with navigation in the dependency tree (e.g. finding minimal unsatisfiable subsets (MUSes) in a given subtree guided by current research).

  • Expose index editing to the cabal UI to allow the use of, e.g. forceDependency (see the example session) from the command line. This subsumes functionality like "--ignore-upper-bounds". That part requires more extensive changes in Cabal.

  • (Optional) Based on experiments with the interactive solver I would like to generally improve the error messages from the solver.

  • Very basic example Session:

      cabal install foo --interactively
      Welcome to cabali!
    
      (1) foo version 1.1
      (2) foo version 1.2
      > choose 1
      (1) bar version 0.1
      (2) bar version 0.2 (installed on ...)
      > back
      (1) foo version 1.1
      (2) foo version 1.2
    

  • More advanced usage should allow to interactively weaken constraints. This might produce a functioning installation if the interface did not change too much.

      cabal install foo --interactively
      Welcome to cabali!
    
      (1) foo version 1.1
      (2) foo version 1.2
      > choose 2, auto
      Error: foo depends on bar and baz, bar depends on foobar version 4.1 and baz depends on foobar version 4.1.1
      > forceDependency "bar" "foobar-4.1.1"
      Ok
      > choose 2, auto 
      Generated a valid installation plan given the weakened constraints.
      > install
    

    The basic functionality is one of the core goals. At the moment it is unclear if finding MUSes is feasible. Trying to do so is worth the effort, though, because finding all MUSes ultimately gives exactly the reason why and how the constraint network is unsatisfiable.

• What deliverables do you think are reasonable targets? Can you outline an approximate schedule of milestones?

  • 28. May - 16. Jun (19 days): Preparation phase.
    • Familiarize myself with the internals and make the necessary changes to allow for interactivity.
    • Milestone: Implement zipper-like navigation of the search tree.
  • 17. Jun - 29. Jul (42 days): First half.
    • Milestones:
      • Implement basic UI with simple navigation commands.
      • Allow for both, interactive and automatic search from within the UI.
  • 29. Jul - 02. Aug (5 days): Mid-term evaluation
  • 02. Aug - 16. Sep (46 days): Second half.
    • Improve the error messages from the solver.
    • Milestones:
      • Implement MUSes and more advanced commands.
      • Expose index-editing functionality.
  • 16. Sep - 23. Sep (7 days): Use the last week to polish the project.

• What relevant experience do you have? e.g. Have you coded anything in Haskell? Have you contributed to any other open source software? Been studying advanced courses in a related topic?

  • I have been toying with Haskell for several years now and used it for my day-to-day programming for several months.
  • I attended several classes on Graph Theory and Algorithmic Learning as well as on the Design of Computer Programs.
  • I have contributed to and lead the development of the package management system (sorcery) of the linux distribution Sourcemage.

• In what ways do you envisage interacting with the wider Haskell community during your project? e.g. How would you seek help on something your mentor wasn't able to deal with? How will you get others interested in what you are doing?

  • I am on the relevant haskell-related IRC channels on a daily basis.
  • I will blog about my progress.
  • The code will be hosted publicly on github thus making it easy to follow the progress.
  • Of course I know and am able to discuss on the relevant mailinglists.

• Why do you think you would be the best person to tackle this project?

  I am reasonably confident about my Haskell skills and my background in mathematics allows me to comfortably deal with the required abstraction. Furthermore, I am very interested in that project in particular and in constraint solving in general.