looks like CI doesn't install dependencies based on package.xml data. @clalancette is it possible to get rospkg installed on CI machines ?

looks like CI doesn't install dependencies based on package.xml data. @clalancette is it possible to get rospkg installed on CI machines ?

Ah, I forgot about that. While I could certainly open a PR to https://github.com/ros2/ci to add rospkg to the list of pip packages to install, we would also have to update the documentation so that users would still be able to build and test from source. While we can certainly do this, I'm wondering if this is worth it. It seems we have 3 alternatives right now:

1. Install the rospkg pip package in CI and in the documentation. Then we can merge this PR.
2. Do nothing, and just let CentOS stay yellow on the buildfarm.
3. Go back to my previous PR, which just uses pure Python. It is a bit of duplication for code that is already there, but it isn't really super complicated.

I'd go for 3) personally, but I'd like to hear other opinions.

we would also have to update the documentation so that users would still be able to build and test from source

could the documentation use rosdep for that?

Does the fact that Red Hat announced discontinuation of CentOS impact the final decision?
If it results in no plans for official ROS support for CentOS in the near future I'd vote for 2).
Otherwise 1) or 3) with a preference for 1) as it seems that there is already more code than people can maintain and managing dependencies will benefit from being streamlined (but 3 is fine as well if this is the preferred option on OR's side)

Ditto @mikaelarguedas's thoughts. Preference for (2), not sure it makes sense to invest in a platform that is disappearing.

Does the fact that Red Hat announced discontinuation of CentOS impact the final decision?

I don't think so. As far as I know, CentOS is not discontinued; it is just changed. Also, there are several new distributions popping up to fill the place that CentOS occupied. So while CentOS as it is today may go away, I think that there will be some RHEL-compatible clone (or RHEL itself) that we target.

@clalancette thanks for clarifying. Is there a path forward for 1) (streamlining installing deps using rosdep) or do you believe we have to fall back to 3) (duplicate rospkg logic in this package) ?

Since the problem this PR is trying to avoid is actually caused by the use if importlib_resources over importlib.resources, which could absolutely be a problem on any other platform that doesn't have Python 3.9, wouldn't it be better to base this test off from that? You could avoid the rospkg dependency and do the detection using the same import logic that manifests the bug.

Also, RHEL 8 is also using Python < 3.9 and is therefore using the importlib_resources package as well.

Replaced by #258