Summary
Both scitex==2.29.0 and scitex==2.29.1 declare an exact pin on
scitex-config==0.3.3, but scitex-config 0.3.3 was never published
to PyPI (or was yanked). The PyPI history for scitex-config is
0.3.0 → 0.3.1 → 0.3.2 → 0.3.4 — 0.3.3 is missing.
The same versions also exact-pin scitex-app==0.2.7 (this one does
exist; the issue is that the ==0.3.3 pin alone makes the whole
umbrella unresolvable, which cascades).
scitex==2.28.13 (and earlier 2.28.x) used sane >= pins
(scitex-app>=0.2.5, scitex-config>=0.3.0), so this looks like a
regression introduced in the 2.29 line.
Impact
Any downstream that adds scitex>=2.29 (or scitex with no upper
bound that pip resolves to 2.29.x) gets:
ERROR: ResolutionImpossible
scitex 2.29.1 depends on scitex-config==0.3.3
Additionally, some packages in these conflicts have no matching
distributions available for your environment:
scitex-config
This blocked the scitex-hub v0.18.0 release pipeline today (the
v0.18.0 tag is the scitex-cloud → scitex-hub rename; the runtime
Django settings do import scitex as stx, so scitex is a hard
runtime dep). Workaround in scitex-hub: pin scitex>=2.28.13,<2.29
until 2.29 is fixed.
Reproduction
python -m venv /tmp/v && /tmp/v/bin/pip install 'scitex==2.29.1'
# -> ERROR: Could not find a version that satisfies the requirement
# scitex-config==0.3.3 (from scitex) (from versions: 0.3.0, 0.3.1,
# 0.3.2, 0.3.4)
Proposed fix
Either (in order of preference):
- Release
scitex==2.29.2 that restores >= pins for the sub-package
deps (e.g. scitex-config>=0.3.0, scitex-app>=0.2.5). This is what
2.28.13 already does; the 2.29 release seems to have inadvertently
over-pinned during a templated bump.
- Publish
scitex-config==0.3.3 to fill the gap so the existing
==0.3.3 pin resolves. Less ideal because the exact-pin pattern is
the underlying brittleness.
- Yank
scitex 2.29.0 and 2.29.1 from PyPI so pip falls back to
2.28.13. Cleanest if no one is depending on the 2.29.x feature
surface yet.
I'd lean (1).
Cross-ref
🤖 Filed via proj-scitex-hub agent
Summary
Both
scitex==2.29.0andscitex==2.29.1declare an exact pin onscitex-config==0.3.3, butscitex-config 0.3.3was never publishedto PyPI (or was yanked). The PyPI history for
scitex-configis0.3.0→0.3.1→0.3.2→0.3.4—0.3.3is missing.The same versions also exact-pin
scitex-app==0.2.7(this one doesexist; the issue is that the
==0.3.3pin alone makes the wholeumbrella unresolvable, which cascades).
scitex==2.28.13(and earlier 2.28.x) used sane>=pins(
scitex-app>=0.2.5,scitex-config>=0.3.0), so this looks like aregression introduced in the 2.29 line.
Impact
Any downstream that adds
scitex>=2.29(orscitexwith no upperbound that pip resolves to 2.29.x) gets:
This blocked the
scitex-hub v0.18.0release pipeline today (thev0.18.0 tag is the
scitex-cloud → scitex-hubrename; the runtimeDjango settings do
import scitex as stx, soscitexis a hardruntime dep). Workaround in scitex-hub: pin
scitex>=2.28.13,<2.29until 2.29 is fixed.
Reproduction
Proposed fix
Either (in order of preference):
scitex==2.29.2that restores>=pins for the sub-packagedeps (e.g.
scitex-config>=0.3.0,scitex-app>=0.2.5). This is what2.28.13 already does; the 2.29 release seems to have inadvertently
over-pinned during a templated bump.
scitex-config==0.3.3to fill the gap so the existing==0.3.3pin resolves. Less ideal because the exact-pin pattern isthe underlying brittleness.
scitex 2.29.0and2.29.1from PyPI so pip falls back to2.28.13. Cleanest if no one is depending on the 2.29.x featuresurface yet.
I'd lean (1).
Cross-ref
🤖 Filed via proj-scitex-hub agent