From cb98e79ce7d7fa8f86d30b5326835db009fda88d Mon Sep 17 00:00:00 2001 From: s-heppner Date: Tue, 14 Jul 2026 14:21:58 +0200 Subject: [PATCH 1/2] compliance_tool: Fix packaging and CI SDK install Previously, `compliance_tool/pyproject.toml` was missing the `[project.scripts]` console entry point, so the `aas-compliance-check` command documented in the README did not exist and only `python -m aas_compliance_tool.cli` worked. It also declared its SDK dependency as a direct reference (`basyx-python-sdk @ file:../sdk`), which bakes a local path into the built wheel and is rejected by PyPI on upload, so the package could not be published. This restores the `aas-compliance-check = aas_compliance_tool.cli:main` console script and replaces the direct reference with a normal `basyx-python-sdk>=1.0.0` version constraint, matching the original `setup.py`. Switching to the loose `>=1.0.0` constraint broke the compliance-tool CI jobs, however: they checked out shallow (no tags), so `setuptools_scm` built the local sdk as `0.1.dev1`. That does not satisfy `>=1.0.0`, so `pip install .[dev]` uninstalled the local sdk and pulled `basyx-python-sdk` from PyPI instead, and the tests failed against a release that predates the local refactors. Both compliance tool jobs now check out with `fetch-depth: 0` so the local sdk builds as a `>=1.0.0` dev version and pip keeps it (see #592). --- .github/workflows/ci.yml | 14 ++++++++++++-- compliance_tool/pyproject.toml | 5 ++++- 2 files changed, 16 insertions(+), 3 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 5330806f..a5e2c254 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -215,12 +215,17 @@ jobs: steps: - uses: actions/checkout@v4 + with: + # TODO(#592): revisit when the sdk<->compliance_tool version pinning is fixed. + # Need tags so setuptools_scm builds the local sdk as >=1.0.0, else the loose + # `basyx-python-sdk>=1.0.0` pin lets pip replace it with the PyPI release. + fetch-depth: 0 - name: Set up Python ${{ matrix.python-version }} uses: actions/setup-python@v5 with: python-version: ${{ matrix.python-version }} - name: Install Python dependencies - # install the local sdk in editable mode so it does not get overwritten + # install the local sdk first so its version satisfies the >=1.0.0 pin and pip keeps it instead of PyPI run: | python -m pip install --upgrade pip python -m pip install ../sdk @@ -242,12 +247,17 @@ jobs: working-directory: ./compliance_tool steps: - uses: actions/checkout@v4 + with: + # TODO(#592): revisit when the sdk<->compliance_tool version pinning is fixed. + # Need tags so setuptools_scm builds the local sdk as >=1.0.0, else the loose + # `basyx-python-sdk>=1.0.0` pin lets pip replace it with the PyPI release. + fetch-depth: 0 - name: Set up Python ${{ env.X_PYTHON_MIN_VERSION }} uses: actions/setup-python@v5 with: python-version: ${{ env.X_PYTHON_MIN_VERSION }} - name: Install Python dependencies - # install the local sdk in editable mode so it does not get overwritten + # install the local sdk first so its version satisfies the >=1.0.0 pin and pip keeps it instead of PyPI run: | python -m pip install --upgrade pip python -m pip install ../sdk diff --git a/compliance_tool/pyproject.toml b/compliance_tool/pyproject.toml index 6ae3cd27..64f8adf8 100644 --- a/compliance_tool/pyproject.toml +++ b/compliance_tool/pyproject.toml @@ -38,7 +38,7 @@ requires-python = ">=3.10" dependencies = [ "pyecma376-2>=0.2.4", "jsonschema>=4.21.1", - "basyx-python-sdk @ file:../sdk", + "basyx-python-sdk>=1.0.0", ] [project.optional-dependencies] @@ -52,6 +52,9 @@ dev = [ [project.urls] "Homepage" = "https://github.com/eclipse-basyx/basyx-python-sdk" +[project.scripts] +aas-compliance-check = "aas_compliance_tool.cli:main" + [tool.setuptools] packages = { find = { include = ["aas_compliance_tool*"], exclude = ["test*"] } } From 3775e19bed149fdfbe4070265918a5f587553790 Mon Sep 17 00:00:00 2001 From: s-heppner Date: Tue, 14 Jul 2026 20:03:38 +0200 Subject: [PATCH 2/2] compliance_tool: Document SDK version caveat in README MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Previously, the README described what the compliance tool checks but not how the installed `basyx-python-sdk` determines which metamodel version is actually verified. Because the SDK dependency is declared loosely (`basyx-python-sdk>=1.0.0`), `pip` keeps an already-installed, older SDK instead of upgrading it, so the tool can silently check against an older metamodel than the README advertises, with no error to signal the mismatch. This adds an `Installation` section that splits the default PyPI install (`pip install basyx-compliance-tool`) from the developer install against the sibling `./sdk` source tree, and documents — in the developer flow, where it is most relevant — that the SDK version must be matched explicitly until the pinning is tightened (see #592). --- compliance_tool/README.md | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/compliance_tool/README.md b/compliance_tool/README.md index 185e157a..be49156a 100644 --- a/compliance_tool/README.md +++ b/compliance_tool/README.md @@ -10,6 +10,38 @@ Shell elements * check if the data in a given xml, json or aasx file is the same as the example data * check if two given xml, json or aasx files contain the same Asset Administration Shell elements in any order +## Installation + +### Default installation +Install the latest release from PyPI: + +```bash +pip install basyx-compliance-tool +``` + +### Developer installation +When working from a checkout of this repository, install the sibling SDK from the source tree *first*, then the +compliance tool: + +```bash +pip install ./sdk +pip install ./compliance_tool +``` + +Installing the local SDK first is what lets the tool check against your in-development metamodel: `pip` keeps the +already-installed local SDK instead of pulling a release from PyPI. + +> [!IMPORTANT] +> The compliance checks are only as current as the installed `basyx-python-sdk` — the tool reports compliance against +> whatever metamodel version that SDK implements, not against the version named in this README. Because the dependency +> is currently declared loosely (`basyx-python-sdk>=1.0.0`), `pip` will **not** replace an SDK that is already installed +> and satisfies that constraint, even if it is older than the one you intend to test against. This happens silently, with +> no error. To be sure you are checking against the intended metamodel, install or upgrade the SDK explicitly, e.g. the +> local source tree with `pip install ./sdk` or a specific release with `pip install --upgrade "basyx-python-sdk==2.1.0"`. +> +> This manual version matching is a temporary workaround; see #592. + +## Usage Invoking should work with either `python -m aas_compliance_tool.cli` or (when installed correctly and PATH is set correctly) with `aas-compliance-check` on the command line.