[sonic-package-manager]: Unpin docker-image-py and use lowercase 'azure/sonic' in registry test

[lunyue-ms]

What I did

docker-image-py was pulled in unpinned (docker-image-py>=0.1.10). When 0.2.0 was released (2026-06-29) it changed Reference.split_docker_domain() to treat an uppercase first path component as a registry domain (Docker Hub repository names must be lowercase). This broke tests/sonic_package_manager/test_registry.py::test_get_registry_for, which resolved the reference Azure/sonic.

The key point is that Azure/sonic is not a valid Docker Hub reference in the first place — Docker Hub namespaces must be lowercase (Azure/... is rejected as an invalid namespace). So instead of pinning docker-image-py to ==0.1.13 (#4660) or reimplementing split_docker_domain(), this change simply fixes the test to use the valid lowercase reference azure/sonic and drops the pin (>=0.1.10), so registry resolution and the test are correct regardless of the installed docker-image-py version and the build can adopt 0.2.0. It pairs with sonic-net/sonic-buildimage#28144, which stops installing python3-regex via apt so 0.2.0's regex>=2026.6.28 installs cleanly.

How I did it

• setup.py: docker-image-py==0.1.13 → docker-image-py>=0.1.10 (drop the pin added in [setup]: Pin docker-image-py to 0.1.13 #4660).
• tests/sonic_package_manager/test_registry.py: resolver.get_registry_for('Azure/sonic') → resolver.get_registry_for('azure/sonic').

How to verify it

Run the package-manager registry test with docker-image-py 0.2.0 installed:

pytest tests/sonic_package_manager/test_registry.py::test_get_registry_for

It passes (CI green) — azure/sonic resolves to the DockerHubRegistry singleton regardless of the docker-image-py version.

Previous command output (if the output of a command-line utility has changed)

N/A - no user-facing command output changes.

New command output (if the output of a command-line utility has changed)

N/A - no user-facing command output changes.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This PR updates sonic-package-manager to be resilient to docker-image-py 0.2.0’s change in Reference.split_docker_domain() by introducing a local split_docker_domain() implementation (restoring the pre-0.2.0 heuristic) and routing registry operations through it, ensuring mixed-case repository paths (e.g., Azure/...) aren’t misinterpreted as registry domains.

Changes:

• Add a local split_docker_domain() helper in sonic_package_manager/registry.py and use it in RegistryResolver and registry API calls.
• Extend unit tests to validate Docker Hub resolution for additional repository inputs and validate the split behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
sonic_package_manager/registry.py	Adds a local domain-splitting helper and switches registry resolution and API calls to use it.
tests/sonic_package_manager/test_registry.py	Adds/extends tests for Docker Hub resolution and split behavior (including uppercase repo path preservation).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[roeebar-arista]

sonic-buildimage has docker-image-py pinned to 0.1.13. Any reason why sonic-utilities is different, and pull changes asynchronously?

[lunyue-ms]

@stepanblyschak, could you please review this change? It adapts the registry domain split to be compatible with docker-image-py v0.2.0. Since you originally authored this logic, your review would be much appreciated. Thanks!

[lunyue-ms]

sonic-buildimage has docker-image-py pinned to 0.1.13. Any reason why sonic-utilities is different, and pull changes asynchronously?

@roeebar-arista , sorry for missed your comments before adding stepanblyschak. buildimage pins 0.1.13 for the image build, but sonic-utilities' own CI installs deps from PyPI via pip install ".[testing]" (unpinned docker-image-py>=0.1.10), so it floated to 0.2.0 and broke test_get_registry_for. Looks like recent pr-checkers for sonic-utility were failed after 6-29 for the same reason. Should we pin the version to 0.1.13 (#4660) or do some adaption work in this PR?

[roeebar-arista]

I think it is generally better to pin package versions and upgrade them in a controlled way, rather than having sonic-utilities break when async package updates happen.

As a quick fix, maybe we should pin docker-image-py to 0.1.13 and upgrade to 0.2 later, if and when it is needed. I see you already submitted #4660.

[lunyue-ms]

Got it. Then let's pin the docker-image-py to 0.1.13 as a quick fix.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

Cherry-pick PR to 202511: #4674

[saiarcot895]

For later reference:

If a image name starts with an uppercase character, it's used as the registry domain. If it starts with a lowercase character, the default registry is used, with a namespace of the first part of the image name.

admin@vlab-03:~$ docker push Azure/docker-dhcp-relay
Using default tag: latest
The push refers to repository [Azure/docker-dhcp-relay]
Get "https://Azure/v2/": context deadline exceeded
admin@vlab-03:~$ docker tag docker-dhcp-relay:latest azure/docker-dhcp-relay:latest
admin@vlab-03:~$ docker push azure/docker-dhcp-relay
Using default tag: latest
The push refers to repository [docker.io/azure/docker-dhcp-relay]

[mssonicbld]

Cherry-pick PR to msft-202608: Azure/sonic-utilities.msft#394