In short, you'll have to build from source. Here are the instructions for building ROS 2 on Linux: https://index.ros.org/doc/ros2/Installation/Eloquent/Linux-Development-Setup/
I'm guessing Python 3.7 was installed from source, or a different apt repo? In general, whether or not this will work is undefined. The safe assumption is that it won't work. This is not limited to ROS or to Python. Debian packages depend on other Debian packages. Assuming you're on Ubuntu Bionic, the eloquent packages were built using python3 from the official Ubuntu Bionic apt repos, in which python3 is python 3.6.
While it should be expected not to work, in this case a technical reason it doesn't work is because rclpy builds a cpython extension. This is ABI compatible only with the same version of python used to build it (Python 3.6). There's more info about ABI compatibility of extension libraries in PEP 3149.
I can change the symlink to python3.6 and it works fine. I prefer to avoid that.
I'd strongly recommend against changing the system install of python via symlinks. Let your package manager handle that. rclpy is not the only package that will be broken. In general, once you stop using your package manager to install a package, you need to install every package that depends on it from source too.
I tried changing ROS_PYTHON_VERSION from "3" to "3.6" but that seems to have no effect.
ROS_PYTHON_VERSION is used to indicate the major version of python. Allowed values are 2 or 3. This is only useful for ROS 1, since ROS 2 only supports python 3. It was created to support conditional dependencies, see REP 149.
ros2 clearly depends on Python3.6. Is there a clean way of specifying this? Where should I have found it?
Debian packages list their dependencies. Running apt show ros-eloquent-rclpy will show that ros-eloquent-rclpy depends on libpython3.6.
Originally posted by sloretz with karma: 3061 on 2019-12-19
This answer was ACCEPTED on the original site
Post score: 2
Original comments
Comment by kylerlaird on 2019-12-19:
OK, so really there's a dependency on the version of the python3 package (must be 3.6.*).
I'm reverting to bionic.
Thank you!
--kyler
Comment by gvdhoorn on 2019-12-20:
@kylerlaird: please mark your question as answered by clicking the checkmark to the left of the answer.
Comment by gvdhoorn on 2019-12-20:\
so really there's a dependency on the version of the python3 package (must be 3.6.*)
to be more precise: the binary packages of ROS 2, released for Ubuntu Bionic, depend on the version of Python 3 that is shipped with Ubuntu Bionic. That happens to be v3.6.x in this case.
Reason I highlight this is that it's slightly different from what you wrote: the dependency is not explicitly on 3.6, but on whatever the default is for the platform supported for Eloquent.
As @sloretz wrote:
This is not limited to ROS or to Python. Debian packages depend on other Debian packages.
Comment by kylerlaird on 2019-12-20:
I think it's more precise to say that the binary packages of ROS2 have an undeclared dependency on python3 version 3.6.
Comment by gvdhoorn on 2019-12-20:
No, I don't believe that is correct.
The dependency is on the system provided Python, which happens to be 3.6 on Bionic. It could be another version on some other OS.
The specific versions of dependencies on the different supported OS are documented in REP 2000: ROS 2 Target Platforms.
Comment by kylerlaird on 2019-12-20:
The dependency is certainly 3.6 for the package I have; it's the only one for which compiled modules are included.
# dpkg -L ros-eloquent-rclpy |grep /lib/python | cut -d\/ -f6 |sort -u
python3.6
There is nothing precise about crossing your fingers and hoping for a version of a package to be provided by a distribution. Dependencies are specified using numbers. https://www.debian.org/doc/debian-pol...
ros-eloquent-rclpy even specifies a version for "libpython3.6 (>= 3.6.5)" (but misses "<< 3.7"). The dependency for "python3 (>= 3.6), python3 (<< 3.7)" is missing, however.
There is clearly a dependency here. I don't understand your reason for keeping it a secret from the package manager.
Comment by tfoote on 2019-12-20:
We can actually rely on the fact that packages released into the system by Debian/Ubuntu will be ABI compatible with whatever we built against once it's in a released distribution. This assumption holds true of all the system libraries we build against. When you're in an unstable, or prerelease system it's not necessarily true but otherwise that's the policy.
Jumping to 3.7 will basically guarantee a breakage of ABI, (see semantic version) but it's quite possible that just changing to another patch release in 3.6 will also break the ABI and as such your extra assertions will not hold. Furthermore it could even be the same 3.6.8 software but built with different compile flags and the ABI will not be compatible. Version checks are not enough.
tl;dr If you are breaking the policy and deploying replacement libraries that are not ABI compatible onto a system with binary distributions it is your responsibility to test and/or recompile any dependency of the ABI change to avoid breakage.
Comment by gvdhoorn on 2019-12-21:
@tfoote: capping the max version as @kylerlaird seems to suggest would be a good idea though, to make the dependency on a specific version explicit.
Comment by tfoote on 2019-12-30:
Although it would catch this specific issue, as it's outside of best practices adding these specific dependencies that are an artifact of the build process would actually significantly increase the cost for all users. Since we cannot know whether any specific change in the future will be ABI compatible, the only solution is to add an exact dependency on the package we built against. This has two major drawbacks the first is that for any given package it requires a rebuild of every package when any dependency changes. This is moderately expensive on the buildfarm, but it actually also significantly increases costs for the user as they must download and update almost every package every cycle. The other major drawback is that if the user wants to patch a package in an ABI compatible way for a backport, after doing so it will be detected as an incompatibility and cause all ROS packages to become uninstallable (because they now all have exact version dependencies)
Comment by tfoote on 2019-12-30:
We used to do this for all ROS packages we built but we had to stop due to the costs outlined above. We still force rebuilds of ROS packages considering that the ABI might have changed, but do not force users to update universally. And for stable packages we will add minimum versions of dependencies on them when ABI/API breaks occur on upstream packages to make sure people don't end up on incompatible versions by accident.
If you can break it using packages in the standard sources we should protect from that. There are so many things you can change on your system that would break the ABI compatibility we cannot control or prevent those things (say you switch out the compiler, or even just compiler arguments) any core library. If you're doing those things you need to be aware of what the side effects are. At that point you're a power user overriding the system and with that power comes the responsibility to know what you might break and to take steps to mitigate that on your system.
Comment by sloretz on 2019-12-30:\
ros-eloquent-rclpy even specifies a version for "libpython3.6 (>= 3.6.5)" (but misses "<< 3.7")
I don't think "<< 3.7" is necessary when depending on the Debian package libpython3.6. It has 3.6 in the name.
