Re: [PATCH 1/2] scripts: add --registry option to container tool

[Guillaume Tucker <gtucker@gtucker.io>]

Hi Nathan,

On 05/11/2026 5:29 am, Nathan Chancellor wrote:
>> Add a --registry / -R command line argument to the container tool to
>> specify an altnerative image registry and support it in the TOML
>> configuration file accordingly.
>>
>> This uses a mechanism based on regular expressions to parse the
>> container registry and image names and construct the final one based
>> on a set of priority rules.  A registry can be included directly in an
>> image name; an empty string means a local image.  It can then be
>> overridden by explicitly specifying a registry name via the CLI option
>> or the TOML file, with the CLI option taking precedence as always.
>>
>> Signed-off-by: Guillaume Tucker <gtucker@gtucker.io>
> 
> Hi Guillaume,
> 
> I don't have any real strong opinions on the patch itself (although
> Sashiko seems to have its usual complaints about validation and such)
> but I am not sure the commit message or documentation make it very clear
> why it is useful to support this. In theory, the registry can be added
> to the image parameter, is that not sufficient?

Thanks for taking a look.  Yes, after taking a step back I tend to
agree with this too.  In fact it seems like doing the work for this
series helped prove it was generally a bad idea in the end.  It's
over-complicating things and causes some code bloat for very little
useful features.  There are corner use cases where it makes things a
bit easier e.g. when building a modified container image locally or
on an alternative registry, but handling the full image path isn't
such a big deal.

Validating the image name is also not strictly required IMHO as the
underlying tools e.g. Podman or Docker will report any problems
anyway.  I'll see if we can still have just the regex validation in
place without the extra CLI options, maybe send an RFC but if that's
also bloating the code then I would probably just drop this series
altogether.

As a collateral benefit, I basically ended up with a small Python
package to parse container image names so I might tidy that up and
submit it to PyPI :)  Or upstream it in an OCI toolbox or something.
I haven't found any ready-to-use one, all the container runtimes have
their own independent implementation.

Looking ahead, the next item on my list is to improve out-of-tree
build support with the tool so I'll start tackling that soon.  And
the related topic of hosting reference images in a kernel.org
registry[1] is also making some progress after some discussions at
Kernel Recipes and Plumbers too.  We've reached a consensus with
several key maintainers so we now need to find a way to land this.

Best wishes,
Guillaume

[1] 
https://lore.kernel.org/all/01a87de4-8de5-4ff0-941b-2e5932a3a19c@gtucker.io/