Comments (5)
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.
Related Issues (20)
- Using dkml-base-compiler instead of ocaml-base-compiler HOT 1
- opam monorepo ignores upper bounds HOT 13
- opam monorepo lock fails if repos specified HOT 4
- `opam monorepo lock` fails to parse git repos HOT 6
- The repository "archive-mirrors" is not respected in a `pull`, thus downloads are always from the Internet. HOT 2
- Solver can select ocaml-base-compiler and ocaml-variant at the same time HOT 4
- What's the reasoning behind filtering packages that do not have a dev-repo field? HOT 3
- solver does not work when latest version of a package is not compatible with requested ocaml version HOT 1
- base-bytes.base+dune doesn't work on 4.12 HOT 1
- pull overwrites everything HOT 4
- Warnings about unknown variables being printed HOT 3
- --ocaml-version does not support pre-releases of the compiler HOT 5
- opam-monorepo: [ERROR] Solving opam-provided dependencies could not find a solution HOT 2
- Handle dune files in vendored packages
- Consider dune version HOT 12
- The `<package> Doesn't build with dune` error is omitted from the output of `opam monorepo lock` in some cases
- Adopt the OCaml Code of Conduct HOT 1
- `opam monorepo install` command? HOT 4
- opam monorepo lock not applying global opam vars? HOT 3
- opam-repository behave differently ? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from opam-monorepo.