Bug #308
closed
Added by Guilhem Saurel about 3 years ago.
Updated about 3 years ago.
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 ?
/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.
- 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_}
Also available in: Atom
PDF