Use Dune_lang.Package_name.Opam_compatible.t for package names in package management code.

[gridbugs]

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 type Dune_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 the Dune_lang.Package_name.t type we currently use which doesn't require opam-compatibility.

[Alizter]

Related:

• Writing foo.1.2.3 as a package dependency should give a nice error and a hint #9270

[Alizter]

Wouldn't this be better solved by adding more validation to Package_name.t? I'm not aware that we intended it to differ from opam's restrictions.

[gridbugs]

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 Package_name.Opam_compatible quite recently. Is there a reason you added the new type rather than adding checks to the existing one?

[emillon]

I think I wanted to leverage StringLike to get better error messages and hints, but yes at the moment I don't think that the separate type is used.

[rgrinberg]

I agree that would be better but is there a risk that someone is depending on the current behaviour?

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 Package_name.t and opam's? All this wrapping and unwrapping we currently have is really not buying us much in my opinion. We can still have our own proper validation on top. There's no contradiction here.

[emillon]

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.

When (generate_opam_files) is set, I agree but there's all the projects which use (package) and public names but without opam files. These can become broken.

[rgrinberg]

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.

[gridbugs]

Seems like it could be hard to find such projects since they won't be on opam. Unifying the types (Package_name.t and Package_name.Opam_compatible.t) and deprecating opam-incompatible package names can wait until 4.0 in my opinion. In the meantime, to get consistent treatment of package names within dune's package management features (as described in the original comment) is there any harm in switching to Dune_lang.Package_name.Opam_compatible.t within our package-management code?

[rgrinberg]

It would mean that we'd need to juggle 3 different package name types without any (obvious) benefit. What's the difference between Package_name.Opam_compatible.t and OpamPackage.Name.t?

[gridbugs]

The only technical reason we can't expose a type equality between Package_name.Opam_compatible.t is that (I assume) we don't want the dune_lang library to depend on opam. I'm not proposing to use Package_name.t alongside Package_name.Opam_compatible.t in our package-management code. I'm proposing to replace the former with the latter. We'd still just be juggling 2 package name types in that code.

[rgrinberg]

Okay, feel free to send a PR. That shouldn't be too ugly indeed.

[gridbugs]

Rather than using Package_name.Opam_compatible.t in package management code we'll instead validate that Package_name.ts are opam-compatible in dune 4.0. That work is tracked by this issue: #9731