Get ready for sublibraries.

[philderbeast]

Please get ready for sublibraries. Cabal is mostly there. This is good for distribution of closely related libraries within a single package.

-- wanted pkgA.cabal
name: pkgA

library
  build-depends: foo

library foo
  visible: True

# package.yaml
name: pkgA

library:
  build-depends: foo

library foo:
  visible: True

> hpack
WARNING: package.yaml: Ignoring unrecognized field $.library.build-depends
WARNING: package.yaml: Ignoring unrecognized field $.library foo
generated pkgA.cabal

-- generated pkgA.cabal
cabal-version: 1.12

-- This file has been generated from package.yaml by hpack version 0.34.6.
--
-- see: https://github.com/sol/hpack

name:           pkgA
version:        0.0.0
build-type:     Simple

library
  other-modules:
      Paths_pkgA
  default-language: Haskell2010

SEE: haskell/cabal#5660
SEE: brendanhay/amazonka#671

[tfausak]

I think this could work the same way that executables do. (See #161 for some commentary about that.) We could introduce a new top level libraries key that allows them to be named. Then we could make library: ... a shortcut for libraries: { PACKAGE_NAME: ... }.

[philderbeast]

There is already internal-libraries and these can have visibility: public, see #382.

[philderbeast]

Should we rename these to libraries? With visibility: public they're not that internal anymore.

[sol]

Yesterday, I pushed a change that allows to have aliases for fields: 92c6c94

Optionally, aliases can be deprecated.

This facilitates renaming in a backwards compatible way.

I would still want to see a working, fully self-contained example before deciding to do that.

Instead of renaming, we may also decide to add a new libraries field that sets visibility: public by default + deprecate internal-libraries. I think this would be more appropriate if public libraries are the common case, not sure.

As a side note, Cabal having both exposed / visibility is not a great user interface.

[philderbeast]

Thanks for picking this up @sol. I went looking for libraries but somehow missed internal-libraries.

This alias work is amazing. I have an hpack dependency. Others have a cabal build-dependency. With this we might bridge the gap.

Could aliasing eventually cover all fields so that we might use hpack with a phrasing matching cabal's?

On 92c6c94, aliases seem second class when I see a test "gives the primary name precedence". Could we give this more of a "warns on duplicate fields" feel?

[brandon-leapyear]

✨ This is an old work account. Please reference @brandonchinn178 for all future communication ✨

---

Another issue I found: you can explicitly depend on the main library by using the package name as a sublibrary name, which allows you to do:

mylib:{mylib, internallib}

But hpack seems to strip it out:

dependencies:
- mylib:{mylib, internallib}

build-depends:
  mylib:{internallib}

https://fgaz.me/posts/2019-11-14-cabal-multiple-libraries/