dune should ignore upper bounds on dune

[Alizter]

Maintainers of opam repositories have their own reasons for including upper bounds on the dune package. See here for an example:

• Upper bounds on the "dune" package prevent dune package management from solving dependencies opam-repository-archive#30

This practice is not partaken often in the main opam repository. And is not something we generally recommend.

At the moment it has the affect of preventing dune pkg from working with these packages at all. This is silly, because an upper bound doesn't give dune or the user any reasonable action to take other than a straight rejection.

If a user is using dune pkg they should be able to attempt to build with whatever packages they like and not have upper bounds for dune itself dictated by package maintainers, which are often not applicable to dune pkg but a restriction for the needs of opam.

On the dune pkg side we can improve the user experience by simply ignoring these upper bounds and allowing users to find solutions with said packages. It is very rare for dune to be entirely incompatible with an older dune lang, and by which time there use is likely to have other problems than us allowing a solution.

[shonfeder]

How about we ignore any package-level information about the dune executable when using dune pkg? The relevant lower bound will be from the obligatory dune lang declarations. When using dune as an integrated package manager and build system, is there any reason at all to consider the package constraints on dune in opam files?

[Alizter]

@shonfeder Lower bounds typically stem from the dune lang version anyway, and so would cause issue later on in the locking and build process. Catching it during the lock gives the user an earlier indicator that they should be upgrading their version of dune. An upper bound is different in that asking a user to downgrade isn't productive.

[rgrinberg]

This is silly, because an upper bound doesn't give dune or the user any reasonable action to take other than a straight rejection.

Yes they can. They can pick a version that does not have this upper bound. They can also pick a different version of dune.

But even if we ignore that, the problem itself is no way specific to dune. Constraints on any other package can lead to the same sort of problems pointed out here.

Finally, If a workaround for this issue is truly necessary, a much simpler approach is to teach dune to lie about its version when solving. Ignoring constraints in ad-hoc ways should be the absolute last resort.

[shonfeder]

It seems to me that there's a pretty clear distinction between (a) dune used as an integrated package manager and build system (e.g., via the binary distribution) and (b) it used as just a build system via opam (or esy)? In the case of (b) I agree the bounds make just as much as sense as they do for any other package.

But in the case of (a) it's hard for me to imagine why an upper bound wold make sense. Imagine a package declaring in advance that it could not be used with opam 3, or cargo 1, or npm x.y. Why would a package do that and how could it know? Do we actually want the current version of the package manager to be part of the constraint solving problem, such that someone would consider downgrading their dune installation to get access to some package?

Given my current understanding, when used for package management, dune should assume it can install any opam package. I can see an argument for why we should take upper bounds into consideration when dune is building, as there may be incompatible build behavior. A neat thing dune could do in that in case is install a compatible secondary version of dune as a tool to build the affected package. That is probably over complicated and not worth the effort, but the fact that it makes sense indicates, to me, that as a package manager dune should not consider itself constrained by upper bounds on itself in opam files.