Hi!

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>>
>>>> Instead of just naming them by their pack type, add information from the
>>>> package(s) they contain to make it easier to differentiate them.
>>>>
>>>> * guix/scripts/pack.scm (define-with-source): New macro.
>>>> (manifest->friendly-name): Extract procedure from ...
>>>> (docker-image): ... here, now defined via the above macro.  Adjust REPOSITORY
>>>> argument value accordingly.
>>>> (guix-pack): Derive NAME using MANIFEST->FRIENDLY-NAME.
>>>
>>> [...]
>>>
>>>> -            (define tag
>>>> -              ;; Compute a meaningful "repository" name, which will show up in
>>>> -              ;; the output of "docker images".
>>>> -              (let ((manifest (profile-manifest #$profile)))
>>>> -                (let loop ((names (map manifest-entry-name
>>>> -                                       (manifest-entries manifest))))
>>>> -                  (define str (string-join names "-"))
>>>> -                  (if (< (string-length str) 40)
>>>> -                      str
>>>> -                      (match names
>>>> -                        ((_) str)
>>>> -                        ((names ... _) (loop names))))))) ;drop one entry
>>>
>>> I think this should not be factorized because the requirements are very
>>> Docker-dependent.  Once factorized, it becomes easy to overlook this.
>>
>> Hmm, I'm not a docker format expert, but my quick reading about it
>> turned no restrictions about what a docker image label should look like?
>> So perhaps it is not specially Docker-dependent.
>
> It’s a hack specifically written with Docker repository names in mind,
> and the 40-or-so character limit, for instance.

The actual name length requirement for a Docker repository name seems to
be that it must be between 2 and 255 characters [0]; the attached patch
ensure that this is respected.

> To me it’s a case where factorization isn’t beneficial.  Even if there’s
> a similar procedure used in a different context, it’s still a different
> context with different constraints.  My 2¢!

It seems to me that with the attached patch we get to share what used to
be a Docker-specific abstraction without any added risk (have our cake
and it eat to!).

What do you think?

Thanks,

Maxim