You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the three packages in this monorepo (sdk, compliance_tool, server) each handle their inter-package dependency on basyx-python-sdk differently, and none of them enforce the compatibility the monorepo is supposed to guarantee:
compliance_tool/pyproject.toml declares a plain version constraint (basyx-python-sdk>=1.0.0). This publishes cleanly to PyPI, but the pin is deliberately loose. For local development it relies on the convention that ./sdk is installed first (so the already-installed sibling satisfies the constraint), and nothing actually ties it to the compatible SDK state.
server/pyproject.toml does not declare basyx-python-sdk as a dependency at all; its Dockerfiles install it manually (RUN pip install ../../sdk then RUN pip install ..), so the DockerHub publish works but the package itself is not self-describing. Already tracked as Introduce SDK as dependency for server #459.
I've encountered this underlying tension quite often now. The whole point of the monorepo is that the three packages have mutually compatible states, so a local install should use the sibling ./sdk tree, while a published install should pull the compatible version from PyPI. There are two ways to resolve this:
Stay on setuptools, keep a normal version constraint, and formalize the install-ordering convention (install ./sdk editable first so it satisfies the constraint). This is low-churn and already roughly how things work, but nothing enforces the ordering, and expressing a correct lockstep pin is awkward with setuptools_scm-derived versions.
Migrate to uv workspaces. [project.dependencies] keeps a normal constraint (basyx-python-sdk), and [tool.uv.sources] with { workspace = true } points at the local sibling for development. That source is dev-only metadata that uv strips from the published wheel, so local resolves to ./sdk and the published artifact carries only the PyPI constraint — the behavior we keep reaching for, enforced by the tool rather than by convention.
We should decide between these and, if we go with uv, migrate the packaging/dependency management for all three packages and their release workflows, settling on the correct lockstep version constraint between them. This would subsume the server-specific fix in #459.
Currently, the three packages in this monorepo (
sdk,compliance_tool,server) each handle their inter-package dependency onbasyx-python-sdkdifferently, and none of them enforce the compatibility the monorepo is supposed to guarantee:compliance_tool/pyproject.tomldeclares a plain version constraint (basyx-python-sdk>=1.0.0). This publishes cleanly to PyPI, but the pin is deliberately loose. For local development it relies on the convention that./sdkis installed first (so the already-installed sibling satisfies the constraint), and nothing actually ties it to the compatible SDK state.server/pyproject.tomldoes not declarebasyx-python-sdkas a dependency at all; its Dockerfiles install it manually (RUN pip install ../../sdkthenRUN pip install ..), so the DockerHub publish works but the package itself is not self-describing. Already tracked as Introduce SDK as dependency for server #459.I've encountered this underlying tension quite often now. The whole point of the monorepo is that the three packages have mutually compatible states, so a local install should use the sibling
./sdktree, while a published install should pull the compatible version from PyPI. There are two ways to resolve this:./sdkeditable first so it satisfies the constraint). This is low-churn and already roughly how things work, but nothing enforces the ordering, and expressing a correct lockstep pin is awkward withsetuptools_scm-derived versions.uvworkspaces.[project.dependencies]keeps a normal constraint (basyx-python-sdk), and[tool.uv.sources]with{ workspace = true }points at the local sibling for development. That source is dev-only metadata thatuvstrips from the published wheel, so local resolves to./sdkand the published artifact carries only the PyPI constraint — the behavior we keep reaching for, enforced by the tool rather than by convention.We should decide between these and, if we go with
uv, migrate the packaging/dependency management for all three packages and their release workflows, settling on the correct lockstep version constraint between them. This would subsume the server-specific fix in #459.