Don't require manually generating a `package.bzl` file

[thumphries]

From internal issue tracker:

Currently, Hazel requires manually generating a packages.bzl file that reifies the Stack resolver:

load("//:packages.bzl", "prebuilt_dependencies", "packages")

hazel_repositories(
    prebuilt_dependencies=prebuilt_dependencies,
    packages=packages)

We ought to be able to do better; the only thing that we should need to pass is the resolver name (and potentially extra-dep versions), and have Hazel do the rest:

hazel_repositories(
    resolver="lts-11.6",
    extra_deps = {
        "optparse-applicative": "0.14.2.0",
        ...,
    }) 

Note that for parsing a Cabal file we could just use GHC + built-ins, but for a YAML file we don't get enough from the built-in packages. Instead I think we can just write a Python script using the yaml package. (Bazel already requires Python to be installed anyway.)

Subtasks

• Write a Python script to generate a packages.bzl file for a given Stackage resolver
• Change hazel_repositories to take the resolver name directly, as described above,
  call the above Python script and save packages.bzl in @hazel_base_repositories.
• Update docs

[nmattia]

I had an idea for removing the need for packages.bzl and making bazel aware of the package version and hash generation steps:

1. let's forget about Stackage.hs and packages.bzl
2. have the user specify the resolver and the hash of the corresponding .yaml resolver file from commercialhaskell/lts-haskell in their repo
3. use the above to get a dict of { package_name: package_version } for the given LTS
4. specify a dict of { package_name: package_version } for extra deps
5. merge those two dicts
6. have the user specify a commit for https://github.com/commercialhaskell/all-cabal-hashes/blob/hackage/
7. write a macro/rule/whatever that uses all-cabal-hashes for decorating the package dict with the sha256
8. pass that dict to hazel_repositories

this means specifying:
• a resolver and the hash of its yaml representation
• a list of custom packages and their versions
• a commit and hash for the cabal hashes

limitations:
• it'll always pull the initial cabal revision, but same with Stackage.hs

I suspect this is doable but I don't have enough experience with bazel to be truly confident that it'll work as expected.

[thumphries]

Using all-cabal-hashes for this sounds promising indeed!

[shmish111]

Couldn't you just generate the packages.bzl file and store it in a github repo which is tagged to the stackage version? I.e. create a new repo, https://github.com/FormationAI/hazel-packagesets that contains a single packages.bzl file but many tags, one tag for each version. You could even set up CI to build nightlies. Then the user just has to specify the package set version in WORKSPACE.