Mathieu Lirzin <m...@gnu.org> skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mathieu Lirzin <m...@gnu.org> skribis:
>>
>>> +++ b/guix/build/utils.scm
>>>
>>> (define (package-name->name+version name)
>>> - "Given NAME, a package name like \"foo-0.9.1b\", return two values:
>>> -\"foo\" and \"0.9.1b\". When the version part is unavailable, NAME and
>>> -#f are returned. The first hyphen followed by a digit is considered to
>>> -introduce the version part."
>>> + "Given NAME, a package name like \"foo@0.9.1b\", return two values:
>>> \"foo\"
>>> +and \"0.9.1b\". When the version part is unavailable, NAME and #f are
>>> +returned. Both parts must not contain any '@'."
>>
>> I think this one should remain unchanged, first because it triggers a
>> full rebuild ;-), and second because it has uses in
>> {emacs,gnu}-build-system that expect exactly these semantics.
>
> Actually It seems not used in gnu-build-system, instead there is this:
>
> ;; XXX: We'd rather use `package-name->name+version' or similar.
> (string-drop (if dash
> (substring base 0 dash)
> base)
> (+ 1 (string-index base #\-)))))
It’s almost used, then. ;-)
>> So I think we have to simply provide a different version of that in
>> (guix utils) or so.
>>
>> Also, I think that at least for some time, the new
>> ‘package-name->name+version’ (maybe we could call it
>> ‘package-specification->name+version’ for consistency) should fall back
>> to the old method when:
>>
>> 1. The spec has no @ sign, and
>>
>> 2. The specified package name was not found.
>>
>> It could print a warning when the old method has been used *and* a
>> matching package was found, explaining that this is deprecated syntax.
>
> OK. I will give a try.
Awesome!
>>> +(define* (package-full-name package #:optional (separator "@"))
>>> + "Return a string which is the concatenation of PACKAGE name, SEPARATOR,
>>> and
>>> +PACKAGE version. SEPARATOR is a optional argument defaulting to \"@\".
>>> +PACKAGE must be a <package> record."
>>> + (string-append (package-name package) separator (package-version
>>> package)))
>>
>> I wonder what will break by changing the default to ‘@’. :-)
>>
>> ‘package-full-name’ is used in a bunch of different places, including
>> user interfaces and for anchors in the generated HTML pages (is ‘@’
>> allowed in HTML anchor names?).
>
> According to <https://www.w3.org/TR/html401/types.html#type-name>, using
> ‘@’ in ids is not compatible with HTML4. But according to
> <https://www.w3.org/TR/2014/REC-html5-20141028/dom.html#the-id-attribute>
> and from what I have successfully tested in Icecat 38.5.2, it works in
> HTML5.
OK, thanks for researching it. I guess we can conservatively keep using
hyphens for anchors.
Ludo’.
