Using opam to upgrade dune to a new version will trigger rebuilding of all opam packages that depend on dune. This is, of course, the expected behavior. Since lots of ocaml projects use dune for building, and dune gets frequent updates, much rebuilding is now common with opam upgrades.
However, as I understand things, it’s usually unnecessary to recompile an opam package in response to an upgrade in dune. There seems to be a feature in opam that allows marking a dependency as a build-dependency with no runtime components, that would avoid this kind of unnecessary recompilation; but not many projects seem to be taking advantage of this feature of opam package definition files.
So, two questions:
Is it possible for me to manually instruct opam to upgrade a particular package without attempting to upgrade its dependencies?
Should I send a bunch of pull-requests to opam projects that depend on dune, but don’t have it marked as a build-only dependency? Or are there good reasons that many people have not set up their package definition files that way?
In short, a dune downgrade can break builds. Because of this, dune as an explicitly marked build dependency has been removed from all or most of opam-repository. The PR doing most of the work is here along with links to discussions around why this change was made.
Ah, thanks. This was the context I’d failed to find before posting.
glad to hear that everyone’s already aware, I’m sure things will get nicer eventually.
A dune upgrade may also break builds if dune based packages are not rebuilt. Its just that the breakage is usually more subtle. For example, some subsystem that one expected to work does not. Remember the driver or inline test upgrade fiasco for example.
We realize that such recompilations are annoying to our users and are working on an artifact’s cache to make upgrades orders of magnitude faster. In the meantime, I suggest to keep switches small and project focused. This will make them upgrading them much faster (and not only because of dune!)
A dune upgrade may also break builds if dune based packages are not rebuilt.
This applies to only “build-related” packages, e.g. some PPX tools, right?
Because, aside from the dune-package issue, I’d think build products for a typical ocaml project (i.e. a project that does not deal with some aspect of ocaml compilation) would neither affect nor be affected by changing the dune version. Is there some other relevant metadata that gets generated that dune isn’t backwards-compatible with?
So far, yes but there’s really no reason why that will stay the case. Dune does not guarantee that the OCaml rules are build compatible between different versions of dune, only that it understands the metadata the user wrote to describe the rules. If we’d introduce some flag or new compilation scheme that would apply to all versions of the dune language, the guarantee that we give is that your projects will recompile with the new version and not that it will produce the same artifact.
