[RFC] relax parsing of dune-package files

[ghost]

Currently, the following scenario is annoying:

1. install the development version of dune
2. install a bunch of things with opam
3. reinstall the latest released version of dune

The dune installed in step 3 cannot read dune-package installed by dune in step 1. This mean that we have to reinstall all the packages installed in step 2.

I propose to improve this scenario as follow: when dune v.x read a dune-package file with (lang dune v.y) and y > x, then dune can still read the file but will silently ignore any field it doesn't understand. For this to work well, we must be conservative in the encoding of dune-package between minor versions. i.e., we can add new fields but we cannot rename them.

[kit-ty-kate]

Apart from the interaction with opam, this issue also affects dune itself when using the --workspace option.
For instance, with the following dune-workspace.dev:

(lang dune 1.0)

(context (opam (switch 4.11)))
(context (opam (switch 4.12)))

Calling dune with the following command:

$ dune build @install @runtest --workspace dune-workspace.dev

Results in the following error:

File "/home/kit_ty_kate/.opam/4.12/lib/stdlib-shims/dune-package", line 1, characters 11-14:
1 | (lang dune 2.8)
               ^^^
Error: Version 2.8 of the dune language is not supported.
Supported versions of this extension in version 2.8 of the dune language:
- 1.0 to 1.12
- 2.0 to 2.7

The issue is that the version of dune used during the first call is not the latest one and fails if some development version is used or simply if the current version of dune used is not the highest across of all the opam switches used.

[c-cube]

Having dune as a{build} dep would be indeed pretty great.

[rgrinberg]

I remember talking about this with Jeremie in private and I'm pleased to say that I convinced him that this was a bad idea. Let's keep dune-package as an implementation detail and leave all the optimization to dune's cache.