[ros-users] $PYTHONPATH in launch files
kwc at willowgarage.com
Fri May 28 20:18:51 UTC 2010
On Fri, May 28, 2010 at 12:19 PM, Armin Hornung
<HornungA at informatik.uni-freiburg.de> wrote:
>> 1. roslaunch automatically will include roslib/src on your
>> PYTHONPATH in the remote launch
> After Advait's example I had assumed that roslaunch resets the
> PYTHONPATH, and then reads the manual override, which would have
> resulted in the override needing to include the ROS path every time.
Advait's example is correct -- if you do an override, it has to be
complete. This seems to be the correct solution in this case, because
it's not really an override if you can't block out what roslaunch is
doing. I mainly meant that if your python libraries are completely
encompassed within the ROS package system, setting roslib/src
shouldn't be an issue anymore.
>> 2. 3rdparty Python dependencies need to be system installed (via
>> rosdep) or made into ROS packages, just like any other dependency, in
>> order to be portable. If you follow this model, then there should be
>> no need to set PYTHONPATH manually.
> It's a third party library that is usually installed somewhere in a
> user's home. I assume that adding the directory of its python interface
> to the PYTHONPATH is the standard procedure. Of course there could also
> be wrapping ROS package / manifest, but then a user would also have to
> copy that into the library's dir and add it to the ROS_PACKAGE_PATH.
It will be good to understand this use case better. Most Python
libraries nowadays use the site-packages approach instead of requiring
changing your PYTHONPATH; of course that requires root access usually.
But as for the wrapping with ROS, we have several examples of
downloading and building a Python package directly into your tree. The
Box Turtle version of ROS installed paramiko and pycrypto in this
manner. It's not much work to do this, and it's much less work than
manually setting up each machine (and user on that machine)
individually with libraries.
>> 3. In the odd event that another location needs to be added to the
>> PYTHONPATH, roslaunch supports an $(env FOO) syntax to parameterize
>> this particular setting. This behavior is encouraged as it exposes the
>> fact that any user of that launch file has to manually perform
>> additional setup on each machine the launch file is used. You can
>> also use $(env PYTHONPATH) to push your current PYTHONPATH to the
>> remote machine, assuming you are using NFS or identical layouts.
> Ah, that makes a lot of sense. I wasn't aware of that option, thinking
> that the local PYTHONPATH would be stripped by roslaunch while in the
> context of a launch file. That should definitely be mentioned or
> stressed more in the wiki, because intuitively it does not look like
> it's doing anything! For the record, adding:
> <env name="PYTHONPATH" value="$(env PYTHONPATH)" />
> to the launch file makes the nodes in it behave like they were started
> from the command line, which is what I was looking for.
Indeed, I agree about the confusion with respect to what each does. It
goes to the fact that <env> sets an environment variable and $(env)
reads your current environment.
> That only leaves one (slightly related) issue: The PYTHONPATH set up in
> "setup.sh" when included e.g. in .bashrc. Is there a reason why that
> should be completely reset to ROS' PYTHONPATH, and not appended like the
> PATH environment variable?
It probably could be changed. I'm not sure why it is set in that manner.
More information about the ros-users