Robotics Systems Types

Issue¶

There is a bug which leads to python processes silently using old/not the newest RST version. To reproduce one has to

1. Install RST (eg. rst0.13.3)

• This installs RST but uses custom CMake magic to create the egg file, copy it into the lib folder and also write a rst$VERSION.pth file. This does not include crating/updating the easy-install.pth in the according lib folder as used by setuptools.

2. Install a downstream python project with setuptools (used setuptools version 18.8.1) that reqires RST in the same prefix

• Setuptools by default checks the easy-install.pth file and updates it accordingly if RST is present and writes down the version number (rst0.13.3)

3. Make changes to RST and re-install it (will lead to rst0.13.4)

• Same process as above.

4. Update the downstream python project

• Setuptools will only check the easy-install.pth and realise that the version number written there (rst0.13.3) is within your provided range (eg. rst>=0.13) and therefore make the installation use this (the old) RST lib instead of the newer and installed version (rst0.13.4)

Possible fix¶

When using the toolkit, one might add this post build hook:

export PYTHONPATH=${toolkit.dir}/lib/python2.7/site-packages:$PYTHONPATH

# dirty hack due to bug in cmake and/or setuptools
chmod -R u+rwx ${toolkit.dir}/lib/python2.7/site-packages/*  

cd \\$WORKSPACE/build/python/stable
python2.7 setup.py install --prefix=${toolkit.dir}

cd \\$WORKSPACE/build/python/sandbox
python2.7 setup.py install --prefix=${toolkit.dir}

cd \\$WORKSPACE/build/python/deprecated
python2.7 setup.py install --prefix=${toolkit.dir}

This will install over the custom CMake install procedure and update the correct pth file. I would not say that this is a clean way.

How to actually fix this¶

Separating the languages so that individual install procedures can be done?