-
Notifications
You must be signed in to change notification settings - Fork 397
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Dune_lang.Package_name.Opam_compatible.t
for package names in package management code.
#9371
Comments
Wouldn't this be better solved by adding more validation to |
I agree that would be better but is there a risk that someone is depending on the current behaviour? I guess we could add the additional checks with a version check. @emillon I see you added |
I think I wanted to leverage |
It could break people's projects, but given that the old behavior is useless anyway and no packages can be submitted to opam without a valid name, I don't see any issue with doing it. How about we just export the type equality between our own |
When |
Public names are always validated, and if they are invalid, then they would be rejected by findlib anyway when building something against those packages once they are installed. Btw, there's no reason to use packages or public names unless the project has components that will get published to opam. So it seems highly unlikely that such packages exist. Anyway, running an experiment to confirm or deny such suspicions seems like a good next step. |
Seems like it could be hard to find such projects since they won't be on opam. Unifying the types ( |
It would mean that we'd need to juggle 3 different package name types without any (obvious) benefit. What's the difference between |
The only technical reason we can't expose a type equality between |
Okay, feel free to send a PR. That shouldn't be too ugly indeed. |
This refactors package-management code to use `Dune_lang.Package_name.Opam_compatible.t` for all package names. Previously we were checking for opam compatibility in some package management operations but not others leading to inconsistent behaviour. This removes the inconsistency by making it impossible to represent an opam incompatible package name in package management code. Note that there's still an inconsistency in the treatment of package names in the rest of dune but we can't remove that currently as people may depend on it. There's a discussion of this problem at: ocaml#9371 Signed-off-by: Stephen Sherratt <stephen@sherra.tt>
This refactors package-management code to use `Dune_lang.Package_name.Opam_compatible.t` for all package names. Previously we were checking for opam compatibility in some package management operations but not others leading to inconsistent behaviour. This removes the inconsistency by making it impossible to represent an opam incompatible package name in package management code. Note that there's still an inconsistency in the treatment of package names in the rest of dune but we can't remove that currently as people may depend on it. There's a discussion of this problem at: ocaml#9371 Signed-off-by: Stephen Sherratt <stephen@sherra.tt>
This refactors package-management code to use `Dune_lang.Package_name.Opam_compatible.t` for all package names. Previously we were checking for opam compatibility in some package management operations but not others leading to inconsistent behaviour. This removes the inconsistency by making it impossible to represent an opam incompatible package name in package management code. Note that there's still an inconsistency in the treatment of package names in the rest of dune but we can't remove that currently as people may depend on it. There's a discussion of this problem at: ocaml#9371 Signed-off-by: Stephen Sherratt <stephen@sherra.tt>
This refactors package-management code to use `Dune_lang.Package_name.Opam_compatible.t` for all package names. Previously we were checking for opam compatibility in some package management operations but not others leading to inconsistent behaviour. This removes the inconsistency by making it impossible to represent an opam incompatible package name in package management code. Note that there's still an inconsistency in the treatment of package names in the rest of dune but we can't remove that currently as people may depend on it. There's a discussion of this problem at: ocaml#9371 Signed-off-by: Stephen Sherratt <stephen@sherra.tt>
Rather than using |
It's possible to use invalid opam package names for dune package names in general (e.g.
foo.0.1
). When interoperating with opam we enforce opam's package naming rules but this is done inconsistently in our package management code as not all operations need to call into opam. It would be a more consistent user experience if all package management related operations require that package names be compatible with opam. The typeDune_lang.Package_name.Opam_compatible.t
requires that the name be opam-compatible when values are constructed, so I think this is the type we should use to represent package names rather than theDune_lang.Package_name.t
type we currently use which doesn't require opam-compatibility.The text was updated successfully, but these errors were encountered: