Building Private Libraries/Executables with Lock Directory

[rgrinberg]

Private libraries and executables are those that do not belong to any particular package. However, they still need to be built and may depend on public packages. There should be a way to specify which packages are necessary to build such libraries and executables.

[Alizter]

What if we allowed for (package...) in a deps like field?

[rgrinberg]

Where would the field go?

[rgrinberg]

Here's a simple suggestion:

1. Allow users to define a "private" package. That's a package for which we don't setup any install rules
2. Users can now attach additional dependencies/conflicts to this private package to build their private libraries/executables

[Alizter]

I was thinking of adding it to the library/executable stanza and make it mutually exclusive with package/public_name.

[rgrinberg]

See the discussion in #8356 for the problems with such an approach

[Alizter]

Thanks, the discussion there makes sense. I had some similar reservations when I suggested it.

Rather than creating a "private package" which has the potential to mislead users why don't we have an extra_package_deps or package_deps stanza for dune-project.

It might also be worth considering having something context specific too, and that would be done from dune-workspace obviously.

[rgrinberg]

I don't think private packages are misleading and they have other uses.

Creating additional stanzas in the dune project file isn't great because it requires more work for conflicts and just about any other thing that can be attached to packages.

[Alizter]

I'm confused about the suggestion with private packages then. Where would you declare them?

[rgrinberg]

it would be the exact same thing as a normal package, except that it would have (private) set inside the dune-project file.

For such a package, there would be no installation rules.

[Alizter]

How do we handle packages that depend on a private package? Will we need a similar setup like we have for private libraries and executables?

[rgrinberg]

For packages, we don't need separate private name and public name namespaces. We can just say that a public package cannot depend on a private package.

[Alizter]

Does this mean private packages can depend on other private packages? I feel like this is not a useful behaviour and I would rather have no package being able to depend on private packages.