Related to #3909.

At the moment when building a package in release mode (dune build -p <package>) dune is allowed to build its dependencies that live in directories marked as vendored_dirs even if they belong to a different package. This behaviour fits well when one uses vendoring to bundle dependencies of an executable they are releasing.

It happens that some might want to use vendoring for other purposes than bundling dependencies. For example if they want to work with their dependencies embedded to avoid depending on opam for development. They might also want to modify some of their dependencies during development and wait for the changes to be upstreamed before the release. In both cases they would use local vendored copies for development but would still rely on opam to manage those dependencies once they release.

In those cases, the vendored dependencies are declared as dependencies in the opam files, meaning that when installing them, the default build command dune build -p <package> might fail because of a conflict between an opam installed dependency and its local vendored copy.

I worked on a minimal example of this behaviour in this repository: https://github.com/samoht/vendors-test
All the steps necessary to reproduce are detailed in the README.

Ultimately when trying to install one of the packages you get the following error:

Error: Conflict between the following libraries:
- "c" in _build/default/vendors/c
- "c" in .../_opam/lib/c
  -> required by library "b" in .../_opam/lib/b

There are ways around this problem at the moment, for example to remove the vendored directories from the release tarball or to remove it as part of the build instructions in the opam file.

My main concern here is that the default behaviour of dune might be a bit counter intuitive and results in failures that in some cases might not be visible straight away.

I'm not sure what the vendoring behaviour should be in this case with the new design but we should at least document this and the existing workarounds.