Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Adopt a proper cross-package dependency strategy for the monorepo (evaluate `uv` workspaces)

Open
  • Is something wrong?
#592 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
32/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Quiet
Tech stack
docker, python
Domain
build-system, devops, release

Research direction

Start by comparing sdk/pyproject.toml, compliance_tool/pyproject.toml, server/pyproject.toml, the server Dockerfiles, and the release workflows. Evaluate the setuptools convention against uv workspaces, including the compatible lockstep constraint and issue #605. Done means local installs use ./sdk while published packages resolve the compatible PyPI dependency, with all three packages and release workflows aligned.

Written by the indexing model from the issue text.

Description

bug general

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 #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.

When touching this, also fix #605 in the same pass.

Dominant language
Python
Stars
102
Forks
53
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from eclipse-basyx/basyx-python-sdk

All issues in eclipse-basyx/basyx-python-sdk

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.