Bug #308
closedUnexpected PYTHONPATH
Description
Hi,
I'm having some troubles with a rogue PYTHONPATH:
$ cd robotpkg/wip/py-hpp-rbprm-corba/
$ make show-var VARNAME=PYTHONPATH
$ make
[…]
$ make show-var VARNAME=PYTHONPATH
/opt/openrobots/lib/python3.6/site-packages/hpp
The "/opt/openrobots/lib/python3.6/site-packages" part isn't a big issue, but I don't understand where this "hpp" is coming from at all, and it causes tests to fail, as the "hpp.gepetto" python module is found when we try to import the "gepetto" module while running the unit tests…
Any idea ?
Updated by Anthony Mallet about 3 years ago
/opt/openrobots/lib/python3.6/site-packages/hpp
This path comes from simulation/py-hpp-environments/depend.mk, where
a init.py file is listed in the SYSTEM_SEARCH.
When mk/sysdep/python.mk is used, all init.py files in all
SYSTEM_SEARCH dependencies are used to compute a PYTHONPATH. The paths
are computed by taking the parent directory of the directory
containing the init.py. Thus, for/opt/openrobots/lib/python3.6/site-packages/hpp/environments/__init__.py,
it becomes what you see.
This is mostly for convenience, as many packages require their
dependencies at build / python-compile time. However, in this case,
It might not be the appropriate behaviour. Maybe it should add/opt/openrobots/lib/python3.6/site-packages instead. Or maybe
nothing. Any suggestion?
In any case, explicitly defining a non-empty PYTHONPATH.${_pkg_} for
a package pkg (py-hpp-environments in this case) will orverride the
default behaviour and add the defined value to PYTHONPATH.
Updated by Guilhem Saurel about 3 years ago
- Status changed from New to Closed
Understood, thanks !
I think this strategy is fine, but those packages installing submodules are outsiders. Sadly, all HPP and dynamic-graph are doing this. But this actually raise an issue only if we have one of these submodules that are named exactly as an existing module.
Then I'll just define the correct
PYTHONPATH.${_pkg_}