Skip to content

Hackathon 2016

Jump to bottom
Mikhail Glushenkov edited this page Oct 8, 2016 · 21 revisions

This is a page to collect ideas for Cabal/Hackage hacking tasks/mini-projects for the Haskell eXchange Hackathon 2016. It is an updated version of a similar page for the 2015 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 2.0 and related.

  • 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/cabal.project.freeze 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.

Link to https://github.com/haskell/cabal/issues?q=is%3Aopen+is%3Aissue+label%3A%22meta%3A+easy%22

  • Improve cabal new-build

    See Edward's blog post: http://blog.ezyang.com/2016/05/announcing-cabal-new-build-nix-style-local-builds/ for an intro to new-build and explanation why it's important.

    This is not a neat self-contained project. There are lots of parts to this project and it will require people to work together.

    List of all open new-build issues: https://github.com/haskell/cabal/issues?q=is%3Aissue+is%3Aopen+label%3A%22cabal-install%3A+nix-local-build%22

  • Cabal documentation.

    Cabal's user guide got quite a bit better recently, but there's still a lot of room for improvement. In particular, we want to put more emphasis on the cabal-install tool at the expense of the Setup.hs interface and add a tutorial section. Ideally, the user guide would look like approximately this:

    1. Intro
    2. Tutorial, p.1 - how to use cabal-install to build and install existing packages
    3. Tutorial, p.2 - how to develop programs using cabal-install and write .cabal files -- basically, an updated version of https://wiki.haskell.org/How_to_write_a_Haskell_program.
    4. .cabal format reference
    5. cabal-install command reference
    6. cabal new-build chapter
    7. Appendix: Cabal spec (i.e., the Setup.hs interface)

    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 new website for cabal-install/Cabal.

    Our website hasn't been updated in ages, so a facelift is long due. It doesn't have to be super-advanced, a simple Hakyll-based static page with a blog/news feed would suffice. Start by looking at the https://github.com/haskell/cabal-website repo.

  • Improvements in the release process.

    This is mainly about automating the process of producing binaries for various platforms (Linux i386/x86-64, OS X, Windows x32/x64). We can either use Travis and AppVeyor or the haskell.org infrastructure. The latter requires extending the code of GHC Builder to support arbitrary Haskell projects besides just GHC, because that's what they (haskell.org) want to use for their build farm. Talk with Gershom (@gbaz/@sclv) if he's online about haskell.org integration.

  • Rewrite of the .cabal file parser. #2865

    @phadej (Oleg Grenrus) is the person to talk to about this issue. This is in a good shape already, and we want to merge the code into mainline soon (but not enable it by default!) to ease the transition. Help Oleg with merging, experiment with using the new parser instead of the old one, write tests.

  • Include-able Common Stanzas #2832

    Builds on the new parser+AST. Allow to reduce duplication by moving common definitions to include-able common stanzas which can then be included from other stanzas.

Clone this wiki locally