opam file generation: normalise resulting opam file #2290
Comments
|
Let's just hard-code the right order. I suppose it's not changing very often. |
avsm
added a commit
to avsm/dune
that referenced
this issue
Jul 8, 2019
The logic for the field order used by `opam lint --normalise` is in opam-file and not opam-file-format. This is too much to vendor, so this commit hardcodes the field order based on the opam-file logic. It won't change very often upstream so this shouldn't impose too much of a maintenance overhead. Closes ocaml#2290 Signed-off-by: Anil Madhavapeddy <[email protected]>
avsm
added a commit
to avsm/dune
that referenced
this issue
Jul 9, 2019
The logic for the field order used by `opam lint --normalise` is in opam-file and not opam-file-format. This is too much to vendor, so this commit hardcodes the field order based on the opam-file logic. It won't change very often upstream so this shouldn't impose too much of a maintenance overhead. Closes ocaml#2290 Signed-off-by: Anil Madhavapeddy <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When generating opam files via dune-project, there's a big diff between the default order of opam fields generated by dune and those normalised by
opam lint <file> --normaliseThis is a minor hassle since the submitted version in dune-release could be run through
opam lintbefore generating the release archive. But if it's easy with the existing opam libraries vendored in dune, it would be nice to have the generated order match the opam linted field order.The text was updated successfully, but these errors were encountered: