compliance_tool: Restore entry point and SDK dep#593
Merged
s-heppner merged 2 commits intoJul 14, 2026
Conversation
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 eclipse-basyx#592).
s-heppner
force-pushed
the
Fix/compliance-tool-script
branch
from
b20eb7e to
cb98e79
Compare
|
For now we have #592 unsolved, so this LGTM. Maybe we should still consider updating the |
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 eclipse-basyx#592).
Member
Author
|
Good idea, I've updated the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously,
compliance_tool/pyproject.tomlwas missing the[project.scripts]console entry point, so theaas-compliance-checkcommand documented in the README did not exist and onlypython -m aas_compliance_tool.cliworked. 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:mainconsole script and replaces the direct reference with a normalbasyx-python-sdk>=1.0.0version constraint, matching the originalsetup.py. Local development still resolves against the sibling./sdktree when it is installed first (see #592).Switching to the loose
>=1.0.0constraint broke the compliance-tool CI jobs, however: they checked out shallow (no tags), sosetuptools_scmbuilt the local sdk as0.1.dev1. That does not satisfy>=1.0.0, sopip install .[dev]uninstalled the local sdk and pulledbasyx-python-sdkfrom PyPI instead, and the tests failed against a release that predates the local refactors. Both compliance tool jobs now check out withfetch-depth: 0so the local sdk builds as a>=1.0.0dev version and pip keeps it (see #592).