One package per directory mode

[NathanReb]

At the dune retreat we mentioned a mode where we wouldn't allow mixing different packages in a given folder.

This seems like a very good idea as it would both encourage users to better structure their project by isolating different packages but also solve some issues we currently have where some artifacts or tests are unattached (see #3015 for instance) without having to explicitly set (package ...) fields everywhere.

Before jumping into the actual implementation I think it would be good to define exactly what we want from this feature.

The easiest thing to do would be to enable it in the dune-project and eventually to add a (dir ...) field to package stanzas in there. From there, each artifact or test in that folder would be implicitly considered as part of the package. You would get an error if you explicitly declared a test or artifact that belongs to a different package.

What are the other features we want from that mode?

[NathanReb]

CC @diml @rgrinberg

[rgrinberg]

The easiest thing to do would be to enable it in the dune-project and eventually to add a (dir ...) field to package stanzas in there.

If it's not too hard to support, I don't see anything wrong with having more than one directory per package, so dirs would be more appropriate. The invariant that we'd like to maintain is that every directory is "owned" by one package.

What are the other features we want from that mode?

I believe the most important thing to implement is a new --only-packakge mode. This should now work on the file tree level rather than the stanza level.

[rgrinberg]

Note that the introduction of #3655 complicates the implementation of this proposal.

#3655 introduces a redirection mechanism for private libraries that belong to a package once they are shadowed by --only-packages. I've briefly discussed this with @jeremiedimino and I see two ways to address this:

• We can introduce separate scopes for packages. This way, packages in the same project will not see private libraries in the same project scope.

• We can move the redirection mechanism to dune-package files. This will require dune to look up the set of visible private libs by resolving the packages in the current project that are installed. This is the approach I'd prefer.