Skip to content

ZuriHac 2018

Jump to bottom
Francesco Gazzetta edited this page Jun 8, 2018 · 3 revisions

This is a page to collect ideas for Cabal/Hackage hacking tasks/mini-projects for the ZuriHac 2018 hackathon. It is an updated version of a similar page for HaskellX2gether 2017.

Please use either the #hackage IRC channel on freenode or the #cabal channel on the ZuriHac Slack for online discussions.

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

Easy tickets suitable for beginners

If you're a newcomer to the Cabal code base, start by taking a look at the issues tagged "easy" and "newcomer" on the bug tracker. You should be able to find something to cut your teeth on there.

Strategically important projects

Mostly Cabal 3.0-related. 3.0 is the future version in which new-build will replace old build commands and sandboxes.

  • Improve cabal new-build

    new-build is a major reworking of how Cabal/cabal-install works internally that unifies old build commands and sandboxes and is the main focus of our efforts right now. See Edward Z. Yang's blog post for an intro to new-build and a more detailed explanation.

    Note that there's a GSoC project happening right now touching many of the same tickets, so please announce what you're planning to work on via the communication channels mentioned above to avoid duplication of effort.

    There is a lot of work still to be done on new-build, and most of it can be done in parallel and in groups. We compiled the following list of tasks (roughly sorted by difficulty) that we feel are offering the most pay off right now and are suitable in scope for the hackathon:

    • Integration tests for new-build (e.g.: new-build everything on Stackage). #3322.
    • Fix this annoying issue: #3883 — ghc-options applies to all dependencies, not just local packages.
    • Work on cabal new-update (desirable features: index freezing by default, interaction with cabal.project.freeze, see #3832). Talk with @ezyang, @hvr and/or @angerman if they're online. There's a WIP PR by @angerman at #4809 that can be used as a starting point.
    • Go through the remaining issues in #3104 (difficulty: moderate).
    • Go through the issues in the Galois meta tracking ticket: #3577.
    • Make cabal new-{test,bench} accept all arguments that cabal {test,bench} does. Relevant tickets: #4643, 4766.
    • Fix these remaining bugs in new-{run,test,bench}: #4619, #4676.
    • Improve cabal new-haddock.
    • Add support for git/darcs/... dependencies, #2189 (makes sense to start with tarball dependencies before tackling SCM ones -- tarballs are easier to test)
    • Support new-build projects in cabal outdated. #4627.

If the above is not enough, you can take a look at this GitHub project compiled by @fgaz during HSoC2017, this GitHub project compiled by @typedrat during GSoC2018, or pick a task from the list of all open issues tagged nix-local-build.

Not critically important, but good to have

  • 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. The new user guide TOC should look like roughly 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 the existing Travis and AppVeyor build bots or Jenkins. Jenkins is what GHC is going to use for its release infrastructure and we may be allowed to piggyback on that in the future. Right now we don't have a Jenkins build bot, though, so you will have to set it up. Since it will be initially used infrequently, producing an AWS or Docker image that could be spun up on demand should suffice.

  • Add support for rust-files, analogous to c-files.

Maybe also implement a similar feature for other languages, like Objective-C or Swift. Take a look at the recently merged PR #4810 that added support for cxx-files for inspiration.

  • Add a cabal typecheck command.

See #1176. Stretch goal: use this to add native support for Liquid Haskell (look at the existing integration as inspiration).

  • New AST for .cabal files (not an easy one!).

Builds on the new Parsec parser work (see #2865). This should make it possible to programmatically edit .cabal files while preserving comments and formatting. Talk with @phadej or @dcoutts. There's a prototype at http://code.haskell.org/~duncan/cabal-ast-experiment/.

Clone this wiki locally