What happened
conformance declares a hard SDK version in pyproject.toml line 14 (currently
0.4.4, and #96 proposes 0.4.5):
but lines 31 to 33 redirect that dependency at the sibling checkout:
[tool.uv.sources]
ucp-sdk = { path = "../python-sdk/", editable = true }
and .github/workflows/conformance-tests.yml lines 51 to 55 check that sibling
out with no ref, so it resolves to whatever python-sdk main happens to be:
- name: Check out SDK repo
uses: actions/checkout@... # v5
with:
repository: Universal-Commerce-Protocol/python-sdk
path: python-sdk
The declared pin therefore never takes effect in CI. Measured 2026-09-03 on
conformance fdbdafd: the conformance environment resolves ucp-sdk 0.5.0, while
the repo declares 0.4.4.
The workflow already contains a step named "Validate published SDK dependency"
that runs uv sync with --no-sources, which validates the declared version from
PyPI. So the repository checks the pin it declares and then runs against
something else.
This is adjacent to #96, which updates that declared version. #96 improves the
step that validates the published package; the suite itself still runs against
the sibling checkout, so the two can disagree no matter which version is
declared. Pinning the checkout is what makes them agree.
Why it matters
Every python-sdk release changes what this suite runs against, with no change
here. The scheduled Conformance Tests run has failed every night since
2026-08-26. python-sdk 0.5.0 moved several modules from schemas/shopping to
schemas/common/types, and integration_test_utils.py line 35 imports one of the
moved paths, so the suite now fails at import time.
What I expected
CI runs against the SDK version the repository declares, and a new SDK release
cannot change the result of this suite until someone updates the pin
deliberately.
Scope note
This is one of three independent causes of the current nightly failure and it
does not fix that run on its own. The samples server also cannot start under
0.5.0, and separately the checkout fixture builds a ShippingDestination where
the request union expects ShippingDestinationCreateRequest, which reproduces
with the whole trio pinned to 0.4.6 and is unrelated to any version. Those two
are tracked in samples. This issue is only about the unpinned checkout.
What happened
conformance declares a hard SDK version in pyproject.toml line 14 (currently
0.4.4, and #96 proposes 0.4.5):
but lines 31 to 33 redirect that dependency at the sibling checkout:
and .github/workflows/conformance-tests.yml lines 51 to 55 check that sibling
out with no ref, so it resolves to whatever python-sdk main happens to be:
The declared pin therefore never takes effect in CI. Measured 2026-09-03 on
conformance fdbdafd: the conformance environment resolves ucp-sdk 0.5.0, while
the repo declares 0.4.4.
The workflow already contains a step named "Validate published SDK dependency"
that runs uv sync with --no-sources, which validates the declared version from
PyPI. So the repository checks the pin it declares and then runs against
something else.
This is adjacent to #96, which updates that declared version. #96 improves the
step that validates the published package; the suite itself still runs against
the sibling checkout, so the two can disagree no matter which version is
declared. Pinning the checkout is what makes them agree.
Why it matters
Every python-sdk release changes what this suite runs against, with no change
here. The scheduled Conformance Tests run has failed every night since
2026-08-26. python-sdk 0.5.0 moved several modules from schemas/shopping to
schemas/common/types, and integration_test_utils.py line 35 imports one of the
moved paths, so the suite now fails at import time.
What I expected
CI runs against the SDK version the repository declares, and a new SDK release
cannot change the result of this suite until someone updates the pin
deliberately.
Scope note
This is one of three independent causes of the current nightly failure and it
does not fix that run on its own. The samples server also cannot start under
0.5.0, and separately the checkout fixture builds a ShippingDestination where
the request union expects ShippingDestinationCreateRequest, which reproduces
with the whole trio pinned to 0.4.6 and is unrelated to any version. Those two
are tracked in samples. This issue is only about the unpinned checkout.