You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now opam publish creates a PR, which then gets reviewed by someone who them might reject it based on some mismatch in the standards required to be accepted into opam.
The suggestion here is that opam publish should reject these before the PR is even created, because it takes a while for the builds to finish and there could be quite an unnecessary delay getting new updates out with all of the back-and-forth (ie: bug fixes).
Specifically these have come up for me and would result in a rejected package during the PR review:
Having a version field in the .opam file.
Having the version constraints being too "tight" (ie: "core" {= "v0.12.0" & with-test}), I believe they all need to be >=.
Having test dependencies like utop, merlin, or ocamlformat. These get added as a convenience -- if someone's writing something that extends these then they would be actual dependencies.
I'm not sure if there are any other standards but I've ran into these ones so far. My suggestion is that opam publish should reject this outright and mention why without having it creating a PR and waiting for it to pass all the CI checks only for it to then have it be rejected at review.
The text was updated successfully, but these errors were encountered:
Yes! Ideally, opam-publish should prepare the most guideline compliant. We can most of theses checks in opam-publish itself.
Ping @kit-ty-kate for proper guidelines.
Right now
opam publish
creates a PR, which then gets reviewed by someone who them might reject it based on some mismatch in the standards required to be accepted into opam.The suggestion here is that
opam publish
should reject these before the PR is even created, because it takes a while for the builds to finish and there could be quite an unnecessary delay getting new updates out with all of the back-and-forth (ie: bug fixes).Specifically these have come up for me and would result in a rejected package during the PR review:
version
field in the.opam
file."core" {= "v0.12.0" & with-test}
), I believe they all need to be>=
.utop
,merlin
, orocamlformat
. These get added as a convenience -- if someone's writing something that extends these then they would be actual dependencies.I'm not sure if there are any other standards but I've ran into these ones so far. My suggestion is that
opam publish
should reject this outright and mention why without having it creating a PR and waiting for it to pass all the CI checks only for it to then have it be rejected at review.The text was updated successfully, but these errors were encountered: