dune
dune copied to clipboard
Don't allow package names that aren't valid opam package names
Dune's Package_name.t
type can represent names which are invalid for opam packgaes (e.g. names containing a '.'). We should prevent such Package_name.t
s from being constructed so that all dune packages are are also valid opam packages.
Such change sneaked into release 3.13.0
(commit 21f904250f8bc27abbeafadf70682aceb198b1e3), without being mentioned in the NEWS file. As a result dune.configurator
can not be used anymore.
Are you referring to this change: https://github.com/ocaml/dune/pull/9472
Can you give some details about dune.configurator
not being supported. This is news to me. Also what do you mean by dune.configruator
as distinct from dune-configurator
?
A dune-project
file, which has (package (depends (dune.configurator) ) )
works with 3.12, but fails with 3.13.
My workaround/fix: olafhering/ocaml-ocurl@55e7bd94ece067d9e13dd494813f6c8cb1a10591
Ah I see. The 3.13.0 release does include https://github.com/ocaml/dune/pull/9472 as described here, which checks for opam-compatible package names inside a package's depends
field. Packages in your workspace may still be named with an opam-incompatible name. The present issue is to disallow opam-incompatible package names everywhere.
Note that the main reason for listing dependencies in dune-project is to allow dune to generate opam files. if you're using dune to generate opam files, the dependency on dune.configurator
in dune-project would result in a dependency on dune.configurator
in your opam file which would have resulted in errors from opam when reading the file as dune.configurator
is not a valid opam package name.
A
dune-project
file, which has(package (depends (dune.configurator) ) )
works with 3.12, but fails with 3.13. My workaround/fix: olafhering/ocaml-ocurl@55e7bd9
Note that dune.configurator
never existed as a package. So our change indeed found a bug in your metadata. Hopefully it wasn't too disruptive.