Reconsider how to specify dependencies on internal libraries

[ezyang]

Right now, if I define an internal library helper in the package foobar, I refer to it by adding an extra line to build-depends:

name: foobar
version: 1.0
library helper
  ...
library
  build-depends:
    base >= 4.4,
    helper

This is... kind of "wrong" from a semantic sense. There are two big reasons: (1) the primary reason that build-depends exist is to specify version bounds on external packages, but if we are referencing an internal library, you never want to actually specify a version bound: you want to refer to the library internally, and (2) we're clobbering the global namespace of packages, you can't name a helper the same name as an external package you also want to use.

We still have an opportunity to fix this, since internal libraries have not been published in a real release of Cabal. In particular, a new feature of Backpack might be a good way to fix this: the mixins field. Here are the proposed new semantics:

1. We define a new syntax for referring to internal libraries within a package. One possibility (to get the bikeshedding going): pkg/libname refers to the libname internal library of pkg. To refer to the current package, you can use a dot, as in ./libname, or the full package name.
2. The build-depends syntax remains UNCHANGED. Instead, we augment the mixins syntax to accept qualified library names; e.g., mixins: foobar/helper, foobar/other-helper.
3. Here is how module visibility works. As in Backpack today, if a library is mentioned in build-depends but not in mixins, we do the historical behavior: the public library of that package is brought into scope. Otherwise, if ANY mixin refers to a package, we no longer bring that into scope; we bring precisely only the libraries identified by mixins into scope. So for example:

name: foobar
library
  ...
library helper
  ...
executable fooexe
  build-depends: foobar
  mixins: foobar/helper

this package only brings the modules of helper into scope for fooexe, not the main library foobar. (BY THE WAY, if we hate the fact that referring to a package via a mixin causes its default "import" to not be brought into scope, we could add a new variant of build-depends for packages we want to depend on, but should not have any modules brought into scope; maybe just version-depends?)
4. Optionally, we can make it optional to specify the name of the current package in build-depends if you want to use libraries from it in mixins. So continuing the example from above,

name: foobar
library
  ...
executable fooexe
  mixins: foobar/helper

is OK (you can omit the build-depends.) This is a bit clearer. If we ever end up supporting multiple public libraries per package, you'll have to specify that package in build-depends (since we need to know to depsolve for it, and what your version constraints are.)

CC @Ericson2314

[abooij]

What about foreign libraries? I can imagine hypothetical scenarios in which executables might want to depend on foreign libraries.

Though such code is probably solving the wrong problem :)

[ezyang]

That would be a different kind of dependency, so it would have its own field, I think.

[Ericson2314]

I mentioned it on IRC, but just to log it here for posterity, the only issue I have with this is ":" being used as an analogous separator in many other contexts.

[ezyang]

Yeah we can use ":". I am just a little mournful that we can no longer use "./" as an idiom for "in this namespace."

[ezyang]

I implemented this, but actually I'm pretty unhappy with the use of the mixins keyword here: it ends up being pretty confusing if you're not actually using Backpack, and also it is just so natural to put library dependencies in build-depends, it's a bit hard to kick the habit.

So my new counter-proposal is that we should fix (2), but for (1) settle for making it "manifestly obvious" what package an attached version bound corresponds to.

1. Extend build-depends syntax to accept the form pkgname:cname bounds and :cname bounds. If you are in a package named pkg, to refer to the internal library helper, you write pkg:helper or just :helper. Because internal packages must always be qualified, there is no longer any ambiguity problem. Furthermore, if there is an attached version bound, it applies to the package that the component is contained in. This is easy for the dependency solver to read off, because the package that the bound should be applied to is directly written in the syntax. As before, package bounds on internal libraries are nonsensical and will result in check warnings, but if we ever support dependencies on internal libraries from external packages, the bounds are useful.

2. Extend mixins syntax to accept the form pkgname:cname renamings and :cname renamings. If you specify a mixin, this overrides the default from build-depends (as before.) However, you can now specify internal libraries in mixins without declaring them in build-depends.

@hvr, @Ericson2314, @abooij, @dcoutts, @23Skidoo what do you think about this plan?

[Ericson2314]

That sounds great! A slight nit is : as the first char gives me absolute-path vibes, so something analogous to . for the current package might still be nice---but maybe I'm biased from prior discussion and this won't confuse most users.

[hvr]

Having some special symbolic identfier to refer to the current package would be nice; however, if we can't agree on one (I'm not sure about the leading :int-lib-name thing either; would a lonely : denote the default library of the current package then?), it wouldn't be the worst thing to just always require the explicit pkgname:-qualifier...

@ezyang That being said, I like the general direction of (1) in #4155 (comment) ; haven't thought about the (2) part yet

[ezyang]

I picked leading colon because it's how Bazel seems to do it. Bare colon seems like too much: you can just specify the name of the package by itself (which is how existing code does.) But I won't add this feature in for now. Simpler code!

Don't worry about the (2) part, it's just the "obvious" thing.

[Ericson2314]

Ah, so all named/internal library deps will need an explicit package name, whether that library is part of the current packatge or not? That strikes me as the perfect first step :).

[ezyang]

Yep.