Allow python3 site-package to be modified #72
Merged
Conversation
This file contains 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
|
Agreed for more consistency between sofa modules. For the python3, I see two historical reasons... the first one is that this is a side effect having named python3 the directory for python3 modules in sofa plugin to differentiate from python (aka python2) ones. The second one is that it probably also tooks its root from the fact that debian & ubuntu have their own convention with python3/dist-package in addition to pythonX.Y/diste-packages & .local/pythonX.Y/site-packages |
|
Ready to merge? |
|
Thank you @olivier-roussel. |
…ar or user define for consistency.
alxbilger
force-pushed
the
allow-reuse-edit-set-python-sp-path
branch
from
82ce819
to
568cae6
Compare
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.
For python 3, the CMakeLists sets the
SP3_PYTHON_PACKAGES_DIRECTORYcmake variable topython3/site-package. However, a more standard approach is to install to the site-package directory in the formpython<X.Y>/site-packagefor a Python version X.Y, as it is then automatically imported by default thanks to the site module (see https://docs.python.org/3/library/site.html#module-site ).Also, whereas it is possible to change the
SP3_PYTHON_PACKAGES_DIRECTORYcmake variable for SofaPython3 (e.g. to thepythonX.Y/site-packagevalue), it cannot be changed for this plugin, so thepython3/site-packagevalue is fixed. This leads to an inconsistent python packages installation ifSP3_PYTHON_PACKAGES_DIRECTORYhas been changed in SofaPython3 install.This PR would enable to automatically inherits by default the value of
SP3_PYTHON_PACKAGES_DIRECTORYthat is read from theSofaPython3Config.cmakeat thefind_package(SofaPython3)call, and which corresponds to theSP3_PYTHON_PACKAGES_DIRECTORYof the SofaPython3 python packages directory. If SofaPython3 is not found, thenSP3_PYTHON_PACKAGES_DIRECTORYwon't be set and still can be user defined at the cmake configure, or just kept unspecified and then it will fallback to its default value.Side question: Is there any particular reason to install by default into
python<X>/site-packageinstead ofpython<X.Y>/site-packagein general for the SOFA framework ? If no, may be we could migrate to this path, it could ease the python installation.