[setup]: Pin docker-image-py to 0.1.13#4660
Conversation
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Pull request overview
This PR pins docker-image-py to <0.2.0 in sonic-utilities’ Python packaging requirements to prevent a recently released upstream version from breaking sonic-package-manager behavior and the SONiC image build process.
Changes:
- Restrict
docker-image-pydependency from>=0.1.10to>=0.1.10,<0.2.0to avoid upstream behavior/dependency changes introduced in0.2.0.
| 'click-log>=0.3.2', | ||
| 'docker>=4.4.4', | ||
| 'docker-image-py>=0.1.10', | ||
| 'docker-image-py>=0.1.10,<0.2.0', |
There was a problem hiding this comment.
Why not docker-image-py==0.1.13? That is how it is pinned in sonic-buildimage, and we don't know what other versions of docker-image-py might be released.
There was a problem hiding this comment.
It seems that there is no version between 0.1.13 and 0.2.0. Yes, docker-image-py==0.1.13 will be more accurate to pin the version.
docker-image-py 0.2.0 (released 2026-06-29) breaks sonic-utilities in two ways:
1. Its split_docker_domain() now treats an uppercase first path segment as a
registry domain, so get_registry_for('Azure/sonic') no longer resolves to
Docker Hub. This fails tests/sonic_package_manager/test_registry.py
::test_get_registry_for and would also break real package resolution for the
Azure/* repositories used by sonic-package-manager.
2. It bumps its dependency to regex>=2026.6.28, which forces pip to upgrade the
apt-installed regex inside the build container; that package has no RECORD
file and cannot be uninstalled (error: uninstall-no-record-file), breaking
the sonic_utilities wheel install and therefore the whole SONiC image build.
Pin to ==0.1.13 to restore the previous behavior. 0.1.13 keeps
regex>=2019.4.14 (satisfied by the existing regex) and the old domain splitting.
This matches the exact version already pinned in the SONiC reproducible-build
locks (files/build/versions/**/versions-py3).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Signed-off-by: Lun Yue <17232861+lunyue-ms@users.noreply.github.com>
640dd6b to
87aa13f
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@yijingyan2 Can you please also add this to 202511? |
|
@vaibhavhd @vmittal-msft could you help take a look and see if the cherry-pick job be triggered for this PR please? |
|
#4655 fixed the unit test issue when using 0.2.0 docker-image-py. It also needs to be added for 202511 |
…re/sonic' in registry test (#4674) #### 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 #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. Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com>
docker-image-py 0.2.0 (released 2026-06-29) breaks sonic-utilities in two ways:
1. Its split_docker_domain() now treats an uppercase first path segment as a
registry domain, so get_registry_for('Azure/sonic') no longer resolves to
Docker Hub. This fails tests/sonic_package_manager/test_registry.py
::test_get_registry_for and would also break real package resolution for the
Azure/* repositories used by sonic-package-manager.
2. It bumps its dependency to regex>=2026.6.28, which forces pip to upgrade the
apt-installed regex inside the build container; that package has no RECORD
file and cannot be uninstalled (error: uninstall-no-record-file), breaking
the sonic_utilities wheel install and therefore the whole SONiC image build.
Pin to ==0.1.13 to restore the previous behavior. 0.1.13 keeps
regex>=2019.4.14 (satisfied by the existing regex) and the old domain splitting.
This matches the exact version already pinned in the SONiC reproducible-build
locks (files/build/versions/**/versions-py3).
Signed-off-by: Lun Yue <17232861+lunyue-ms@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Signed-off-by: Yogapriya Mohankumar <ymohanku@cisco.com>
What I did
docker-image-pywas unpinned (>=0.1.10). The 0.2.0 release (2026-06-29) breakssonic-utilities: itssplit_docker_domain()mis-parsesAzure/sonic(failingtest_get_registry_forand corrupting registry paths), and it requiresregex>=2026.6.28, which breaks the wheel install against the aptregex(
uninstall-no-record-file). Pin to==0.1.13to keep the pre-0.2.0 behavior.Minimal alternative to #4655 (which makes the code 0.2.0-compatible instead) —
merge only one.
How I did it
setup.py:'docker-image-py>=0.1.10'->'docker-image-py==0.1.13'.How to verify it
passes; pip resolves
docker-image-pyto 0.1.13 (not 0.2.0).Previous command output (if the output of a command-line utility has changed)
N/A
New command output (if the output of a command-line utility has changed)
N/A