complete dependency list per repository cloned about opam-monorepo HOT 5 CLOSED

This should be fixed once we have the (vendor ...) dune stanza, see ocaml/dune#2260, ocaml/dune#2259 and ocaml/dune#1016.

from opam-monorepo.

Totally agree this needs fixing. I think the changes I planned for the representation of the duniverse content should make it easier to track multi-opam repos there.

What would you think about some tweaks in the dune configuration, profile, files or whatever that would make it possible to build only the public target of your project so that it only builds the subset of the duniverse that is required by those targets.

As an example, if you depend on cstruct but not cstruct-async and run dune build from the root of your project it doesn't try to build the latter. We probably want a similar solution for dune-runtest as well.

The best way to do this would be to tell dune somehow that we don't want to build public targets in the duniverse/ folder by default. I don't think it's currently possible to do that in dune without adding a rule or passing explicit targets to the dune build invocation and that would be fragile but it still feels like an easier problem to solve upstream in dune rather than cloning the whole repo and stripping it from the extra packages which would also make it harder to track the status of a duniverse.

I also guess in some cases you are interested in building the entire duniverse but in those you'd need to include all of the dependencies in there so it's a bit of a different problem.

from opam-monorepo.

I do think we need some better control over what we exclude. I'm just not sure what the best way to express it is :-)

It sounds like our intention here is that: for all the .opam files in a duniverse, some are "installable" and some are pure dependencies. Right now dune considers all .opam files installable but we specifically do not want that behaviour for vendored sources. So if we could mark vendored packages as private, they would get picked up as dependencies only and not built by default.

That sounds ideal to put in as a dune rfc issue targetted at dune 1.11 ... it would mean a huge leap in duniverse usability.

from opam-monorepo.

I also guess in some cases you are interested in building the entire duniverse but in those you'd need to include all of the dependencies in there so it's a bit of a different problem.

If there was a dune-project (public) option in the (packages) stanza, then we could let this be an option for duniverse init. By default duniverse would clone only the root packages as public, but a "CI mode" could make it so everything is public by setting it appropriately in dune-project

from opam-monorepo.

This is now fixed, thanks to (vendor)!

from opam-monorepo.