Open mwoehlke opened 3 weeks ago
When you say package name do you mean the canonical name (e.g., my.library
) do you mean package filename? I am also unaware of any filesystem that does not currently allow the @
sign, build systems like meson do use it last I checked for hash info (e.g., target@some-hash).
When you say package name do you mean the canonical name (e.g.,
my.library
) [or] do you mean package filename?
Both? The only allowed difference between the package name and the CPS file name is that the latter can be lower-cased relative to the canonical spelling of the package name. (Possibly this could be relaxed a bit, in case of extremely restrictive file systems, but right now I'm not aware of any need to do so. Also, technically, things get weird on case-insensitive file systems since I believe FOO.cps
will be found if looking for Foo
, but I consider that UB. Practically speaking, having names that differ only by case won't end well.)
I am also unaware of any filesystem that does not currently allow the
@
sign
...which is fortunate because CPS file names may contain @
. It's not allowed in package names, however, as it is reserved for the configuration specifier.
Would "hash information" show up in consumer-visible names? I would think "no"...
Note: There exist .pc
files that use all of _
, -
, .
and +
. There also exist CMake packages that use -
. One additional rationale for supporting additional characters is so that existing packages can "recycle" the name they already use. (This might be especially relevant if primarily-CPS ecosystems need to be able to express dependencies on things that only ship .pc
files.)
Would "hash information" show up in consumer-visible names? I would think "no"...
It shows up for docker images and other OCI based artifacts that allow pinning to a particular hash/instance (separate from the version).
Right now, the specification says that "package [...] names may consist of ASCII letters, numbers, hyphens (-), and underscores (_), and may not contain forward-stroke (/) or at-sign (@)." This is both too restrictive and too liberal; we should probably also explicitly exclude all characters not allowed in FAT file names (
<
,>
,:
,"
,\
,|
,?
,*
), and we should add+
and.
to the set of officially blessed characters, as these are used in existing package names. (As a bonus, this also makes the naming schema nearly identical to what CMake considers acceptable target names.)