sublibraries in stack_snapshot rule

[ylecornec]

Depends on #1641.

This PR adds support for sublibraries in stack_snapshot.

• They can now be added to the components attribute as lib:<sublib-name>.
• As for the main library and executables, the dependencies returned by stack ls snapshot json are also added to those of the sublibraries. These dependencies seem to be the union of the dependencies of the components, so there may be to many of them.

The components_dependencies attribute.

This new attribute enables declaring internal dependencies between components.
This is most often needed when the main library depends on a sublibrary, as in the example.

Since the types of bazel's attributes are is a bit limited, I went for a dict of json strings, but maybe there is a better interface for this.

    ```
    components_dependencies = {
      "package-name": \"""{"lib:package-name": ["lib:sublib1", "lib:sublib2"]}\""",
    },
    ```

Aliases

• The sublibraries are named @<stack_snapshot_name>//:_<package_name>_lib_<sublib_name> and aliases are created (in the same repository) so that they can be referenced from BUILD files as @<stack_snapshot_name>//<package_name>:<sublib_name>.

• For now there is also a new alias for the main library: @<stack_snapshot_name>//<package_name>.
  But if I believe the conclusion of Build executables in stack_snapshot and use them as tools #1306 maybe it's not a good idea.

• Maybe these aliases could be in an other repository (@<stack_snapshot_name>-libs or @<stack_snapshot_name>-sublibs) to mimic what is done with the executables. But, as @kczulko pointed out, it is natural to have them in the same repository as the main library, and I don't see any possible naming conflict.

Tests

• An archive made from the tests/haskell_cabal_library_sublibrary_name test is imported in a custom stack snapshot. Since stack resolves local archives to absolute paths, this archive is downloaded from an ealier commit of the rules_haskell repository.

• The new tests/stackage_sublibrary test adds a binary that directly depends on the sublibrary of this package via the stackage repository.

• I was not sure in which stack_snapshot rule to add the test, or if it's better to create a new one ?
  So I added this to the @stackage-pinning-test workspace for now.

Setup_deps attribute

I noticed that setup_deps was present in the parameters to format but not used in the generated haskell_cabal_binary rules. It looks like it may also concern the binary rules so I added it.

[aherrmann]

Since the types of bazel's attributes are is a bit limited, I went for a dict of json strings, but maybe there is a better interface for this.

An idea that was discussed here in the past is to have packages accept a struct that can be used to pass more information in a more structured way. As you rightly point out, Bazel's attribute types are quite limited, so in this case the stack_snapshot Starlark function would have to go through all these structs and distribute their fields across the appropriate attributes of the underlying repository rule.

That said, I'd consider this orthogonal to this PR. Let's go with components_dependencies for now. I think the better solution here would be to extend stack ls dependencies json to produce all the information that we need.

• For now there is also a new alias for the main library: @<stack_snapshot_name>//<package_name>.
  But if I believe the conclusion of Build executables in stack_snapshot and use them as tools #1306 maybe it's not a good idea.

IIUC this means that all executables go into @<stackage>-exe//<package-name>:<exe-name> and all libraries into @<stackage>//<package-name>:<lib-name> while the main library also goes into @<stackage>//:<package-name>, correct? I think a question was whether the use of <package-name> as both a Bazel package name (//<package-name>) and a target name (//:<package-name>) at the same time would be an issue. Did you test if this causes any problems? If not, then this seems like a good naming scheme for the aliases.

• I was not sure in which stack_snapshot rule to add the test, or if it's better to create a new one ?
  So I added this to the @stackage-pinning-test workspace for now.

That's fair. Once we have bazel-in-bazel integration tests available, it would be good to have a dedicated one in there.

I noticed that setup_deps was present in the parameters to format but not used in the generated haskell_cabal_binary rules. It looks like it may also concern the binary rules so I added it.

Good catch, that looks like an oversight.

[ylecornec]

IIUC this means that all executables go into @<stackage>-exe//<package-name>:<exe-name> and all libraries into @<stackage>//<package-name>:<lib-name> while the main library also goes into @<stackage>//:<package-name>, correct? I think a question was whether the use of <package-name> as both a Bazel package name (//<package-name>) and a target name (//:<package-name>) at the same time would be an issue. Did you test if this causes any problems? If not, then this seems like a good naming scheme for the aliases.

Yes that's it, from what I tested it does not seem to cause any problems, and the :stackage_sublibrary-repl of the test works fine.

[dpulls]

🎉 All dependencies have been resolved !

[ylecornec]

It should be good to go, I have updated the url of the package1.tar archive to a commit that won't be garbage collected.

[aherrmann]

Thank you!