@dirk-thomas thanks for this detailed roadmap and high-level outline on how people need to contribute. Has anyone already built a table of Python3-compliant ROS packages?
I do think that the Python 2-3 migration challenge is just an extreme case of a more general characteristic of ROS package distribution and organization. While ROS-based systems are supposed to be loosely-coupled (i.e. all you need are matching message MD5 hashes), the way that ROS binaries are distributed creates *very tight* coupling through system dependencies. Namely, all released ROS packages must link against the same system library binary versions, even though this is only really necessary for packages that are linked at compile- or run-time.
Do you know if anyone in the community has developed a robust toolchain for running subsets of ROS packages in isolated environments? I've seen some examples with Python virtualenv, chroot, snaps, and Docker, but there's nothing that I know of others using in practice. This might east not only the Python 2-3 migration, but also running heterogeneous ROS/ros2 systems.
---
As an aside, I really have a hard time reading "OR" as anything but a logical disjunction...
---
[Visit Topic](
https://discourse.ros.org/t/planning-future-ros-1-distribution-s/6538/2) or reply to this email to respond.
If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates.
______________________________________________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
Unsubscribe: <
http://lists.ros.org/mailman//options/ros-users>
(text/plain)