Skip to content

Hackathon 2015

Jump to bottom
Mikhail Glushenkov edited this page Oct 7, 2016 · 1 revision

This is a page to collect ideas for Cabal/Hackage hacking tasks/mini-projects for the Haskell Infrastructure Hackathon

Please use the #hackage IRC channel on freenode for online discussions.

Feel free to expand individual bullet points into full (linked) pages or tickets/issues.

Strategically important projects

Mostly Cabal Hell and related.

  • Enabling Cabal library refactoring

    The Cabal library has some strong stability constraints that have prevented us from making certain kinds of cleanups that would break APIs. In particular Setup.hs scripts historically had no mechanism to say which version of the Cabal library they needed.

    Now they do. We can build on this work to automatically make all old Setup.hs scripts implicitly depend on say Cabal < 2.0 which then gives us the opportunity to make significant refactorings that will simplify Cabal and let us add new features more sanely.

    So this project is to use the existing functionality in cabal-install for Setup.hs deps to add implicit dependencies for old Setup.hs scripts, and test that this works in practice, which will then enable breaking changes in future Cabal library versions without breaking all existing Setup.hs scripts.

    This is an important project for the future health of the Cabal library, which is used by all our other packaging infrastructure, cabal-install, stack, hackage-server, distro tools, IDEs etc etc. It's not that large a project. Probably two people working together could make a good start within a weekend and finish it up within a week or so.

  • package collections in cabal-install and hackage-server

    The idea here is to support package collections directly in our infrastructure. Currently package collections like stackage are implemented indirectly by specially crafted cabal.config files. Collections are also to be distributed via hackage, allowing anyone to define and distribute collections.

    A specification was posted to the libraries list recently. There is also some prototype code available for cabal-install. The cabal-install code adds solver support and allows for set-like operations on collections. Nothing has been started yet for hackage-server.

    This is an important feature since package collections are one of the two big solutions to cabal hell. This is not a huge project. There's probably enough for two people to work on the client side and two on the server side.

  • nix-style & local builds for cabal-install

    This is the other major plank in the solution to cabal hell. This is not a neat self-contained project. There are lots of parts to this project and it will require people to work together.

    This is an ongoing rewrite of the cabal-install build/install/sandbox functionality. The goals are:

    • replace sandboxes, make all builds local by default
    • full sharing of built packages, so new projects don't require rebuilding everything
    • steal mechanisms from nix: nix style hashed package ids and store
    • a UI focused on working with several packages at once, not just individual packages
    • incremental rebuilds of packages within projects (cabal sandbox does this but not well)
    • a stateless UI, e.g. solver choices don't depend on what you built previously
    • a UI that does the necessary prerequisite steps, e.g. cabal build will always configure and build dependencies if necessary
    • react automatically to changes in .cabal and config files, e.g. cabal build just does the right thing

    There is existing code that's good enough to dog-food, i.e. it can build Cabal + cabal-install and their dependencies. There is lots to do:

    • The existing code needs to be extended and made more mature so that it can replace the existing code paths.
    • Building on top of the new cabal build code to support cabal {repl,test,run,haddock} etc.
    • New cabal project file system
    • Implementing new UI semantics for cabal install
    • Adjusting cabal configure for a stateless UI style.
    • Merging code into the main branch.

More modest projects

  • Cabal documentation.

    Cabal's user guide could be a lot better. It's currently a mix of tutorial and reference without being great at either. It also mostly only covers the .cabal file stuff and Setup.hs CLI, hardly touching on cabal-install.

    Anyone considering this should feel empowered to make decisions. You could decide to start from scratch with a new structure and just pinch material from the existing docs. You might want to fully split into tutorial and reference.

  • A man page for cabal-install #848

    cabal-install has been lacking a man page since forever. Would be nice to add one, perhaps auto-generated from --help output by cabal-install itself. Or cabal help foo could show a man page, like git help does.

  • Include-able Common Stanzas #2832

    Allow to reduce duplication by moving common definitions to includable common stanzas which can then be included from other stanzas.

  • Rewrite of the .cabal file parser and AST. #2865

    The existing parser has no formal grammar, has terrible error messages and is sometimes very slow and memory hungry. In large part this is because ReadP is a terrible parser. Now that the ghc library no longer depends on the Cabal library, Cabal is now allowed to depend on parsec.

    The Cabal parser is two-stage, outline then individual fields. This approach will remain. There is a prototype new parser (with a grammar!) using parsec for the outline phase which has had some significant testing (the new grammar only rejects a very small number of old quirky .cabal files). This new parser needs to be integrated and tested further. Additionally the infrastructure for parsing the individual fields needs to be rewritten to use parsec. There is also experimental code for a new more flexible AST for cabal files.

    Further future goals would be to preserve more information in the parser so that editing and re-saving .cabal files becomes possible, preserving layout and comments.

  • (Opt-in) automatic installation of build-deps for cabal {build,test,bench}

    cabal {build,test,bench} already automatically reconfigures. Extend the automatism by adding convenience --install-dependencies/--dependencies-install flags (which can be abbreviated to e.g. --install or maybe --dep) to cabal {build,test,bench}. Maybe have a configuration setting in ~/.cabal/config to enable this mode of operation by default (as it's too controversial to have this on by default for everyone, so give people a choice and postpone a change of default till there's consensus to change)

    Note: this is about adding this feature within the existing cabal-install code, not in the ongoing nix-style local builds branch. That branch already does this, but that branch will not be completed for a while longer.

  • Add HTTP support to cabal sandbox add-source #2769. See also next item.

Useful links

Clone this wiki locally