Python packaging via python #2
Open
Conversation
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
- Bumped CMake version (needed by scikit_build_core) - This commit centralizes python options and add more - shlibdeps does not work well with not installed library (bad for local builds) - python targets have now components such they can be explicitely selected - pyproject.toml added so python (scikit_build_core) can invoke cmake and create a wheel - BUILD_BY_PYTHON option added since scikit sets the path as given by the python environment
Needed to define a correct semantic version for the .so naming
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
With this PR the old behavior should be untouched. The version bump of CMake is necessary for scikit to work with.
Most changes are behind new options where the default already give the default behavior.
The origin is now also changed to an additional hard coded path assuming /opt/xbot/lib will be anyway the path for xbot related libraries. This allows the python libraries being somewhere (far away from $ORIGIN) to still have access to the cpp implementations.
Probably the most biggest change is the outsourcing of the version to a plain file to allow the python way to access the same version (only one place to change). Could be even replaced by git tags for both, cmake and python.
Python installation runs via pyproject.toml which has per default the CMake option BUILD_BY_PYTHON defining different install directories (w.r.t. to python environment, i.e. USER_SITE or VENV). Even via python you can set CMake options:
SKBUILD_CMAKE_ARGS="-DXBOT2_IFC_BUILD_ROS=off;-DXBOT2_IFC_BUILD_COLLISION=off" python -m build -wUnfortunately, I am also not so happy with this solution.
pipwon't work. Neither by installing directly (pip install .) nor by installing a generated sdist (pip install SOME_NAME.tar.gz). The reason is mostly ROS deploying the python environment in PYTHONPATH by sourcing ROS. Pip creates a quite heavily isolated build and thus also overwrites PYTHONPATH with its own temporary build directory. This makes any ROS dependency unaccessible.Nevertheless, I make this PR. This can still be installed via
pipby a wheel which can be created withpython -m build -w. Unfortunately, that wheel will be quite system-dependent. For a potential rosless version (seems to be more difficult thanks to srdfdom) this could be even more interesting.