Add support for x-maintenance-intent in dune-project #11274
Conversation
art-w
force-pushed
the
opam-maintenance-intent
branch
from
8612074 to
a3a9074
Compare
There was a problem hiding this comment.
Thanks for the contribution! 👍
You need to update the tests to reflect your changes. I would split this in two PRs: the part that updates the code and the part that updates Dune itself (in case it breaks for the former).
Also, could you add an entry into the changes directory?
art-w
force-pushed
the
opam-maintenance-intent
branch
from
a3a9074 to
2917028
Compare
Signed-off-by: ArthurW <[email protected]>
art-w
force-pushed
the
opam-maintenance-intent
branch
from
2917028 to
6314d7b
Compare
art-w
force-pushed
the
opam-maintenance-intent
branch
from
6314d7b to
d1a4775
Compare
|
Thanks for the quick review! I've added tests, an entry in |
art-w
force-pushed
the
opam-maintenance-intent
branch
from
d1a4775 to
7b81397
Compare
test/blackbox-tests/test-cases/dune-project-meta/basic-generate.t
Outdated
Show resolved
Hide resolved
Signed-off-by: ArthurW <[email protected]>
Signed-off-by: ArthurW <[email protected]>
art-w
force-pushed
the
opam-maintenance-intent
branch
from
7b81397 to
be0a9b6
Compare
That sounds like a useful thing to do. Is there a need to validate this field at all? |
Signed-off-by: ArthurW <[email protected]>
art-w
force-pushed
the
opam-maintenance-intent
branch
from
34d5210 to
5353bb8
Compare
There was a problem hiding this comment.
Nice feature, however due to how we handle compatibility an upgrade from Dune 3.17 to 3.18 should not trigger user visible changes (that is only allowed via dune-lang), so my suggestion is to gate the generation to dune-lang 3.18+. That will also remove lots of test changes, since these wouldn't change anymore.
| @@ -228,6 +228,10 @@ let opam_fields project (package : Package.t) = | |||
| in | |||
| let list_fields = | |||
| [ "maintainer", Package_info.maintainers info | |||
| ; ( "x-maintenance-intent" | |||
| , match Package_info.maintenance_intent info with | |||
| | None -> Some [ "(latest)" ] | |||
There was a problem hiding this comment.
While this is probably reasonable, I think this should be only generated if dune-lang is >= 3.18, otherwise upgrading to 3.18 will unconditionally rewrite people's OPAM files.
| @@ -4,22 +4,23 @@ Simple test | |||
| The `dune build` should generate the opam file | |||
|
|
|||
| $ cat >dune-project <<EOF | |||
| > (lang dune 1.10) | |||
| > (lang dune 3.18) | |||
There was a problem hiding this comment.
I don't think this is a good change, we should still retain tests that check that 1.10 era projects are supported. It's better to add an additional test for the maintenance intent (and that will also cause less changes in the cram tests).
| @@ -191,6 +191,7 @@ the doc dependencies: | |||
| ] | |||
| ["dune" "install" "-p" name "--create-install-files" name] | |||
| ] | |||
| x-maintenance-intent: ["(latest)"] | |||
There was a problem hiding this comment.
When gating on dune-lang 3.18+ these should go away.
With progress being made on the opam packages archiving policy, a lot of published packages are going to add an
x-maintenance-intent: ["..."]to their opam files. When using dune to generate the opam files, adding this new field requires an extra.opam.templatefile. Right now the custom opam templates escape hatch are fairly exceptional (~60 published projects uses them), so it would be nice for all the others to stay on the happy path if possible.In this PR, the opam
x-maintenance-intent: [...]is only generated if the user specified(maintenance_intent ...)in their dune-project. Perhaps it should produce["(latest)"]by default?See #11272 (cc @hannesm)