Skip to content

Conversation

@nuclearsandwich
Copy link
Contributor

@nuclearsandwich nuclearsandwich commented Jun 30, 2025

Cleaning up bloom for a release and getting pelted with these deprecation warnings. Apparently pkg_resources will be removed in setuptools 81:

The pkg_resources package is slated for removal as early as 2025-11-30. Refrain from using this package or pin to Setuptools<81.


Different APIs that we use are only available as of certain stdlib versions so to fill in for Python < 3.10, we use the backport modules from pypi. These modules are also packaged in Debian / Ubuntu and the version combinations that we need are available in Jammy, Noble, Bookwork, and Trixie, however not Focal. Thus focal will need to be dropped from Bloom's supported distros before this can merge.

@nuclearsandwich nuclearsandwich force-pushed the nuclearsandwich/importlib branch from 49af39f to 00166b3 Compare July 2, 2025 17:37
The backport module does not implicitly shadow the standard library
modules. APIs that we're using in bloom were only introduced in
importlib_metadata 3.6 and 3.10 of the standard library.

Thus to use this API we need to check our python version and use the
backport module explicitly.
This requirement is met by jammy and noble but _not_ focal which
includes python 3.8 and importlib-metadata 1.5.

Therefore, to release this PR we'll need to drop support for focal.
The backport module for importlib_resources doesn't shadow the standard
library import.resources thus we need to import conditionally based on
the current Python / standard library version.
@nuclearsandwich nuclearsandwich requested a review from cottsay July 2, 2025 20:34
Copy link
Member

@cottsay cottsay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks.

I'll say that elsewhere we're using a try/except to attempt use of the standard library import and falling back to the standalone package rather than using conditionals based on the version, but I don't see a particular reason that this wouldn't work as well.

@nuclearsandwich
Copy link
Contributor Author

nuclearsandwich commented Jul 7, 2025

I'll say that elsewhere we're using a try/except to attempt use of the standard library import and falling back to the standalone package rather than using conditionals based on the version

In some cases, even when the stdlib library is available (e.g. 3.7+) the specific API functions that we're using were only added later. So library presence is not a sufficient condition to check and we can't rely on the import error alone. To use try-exceptw we'd have to catch the argument error down the line which is pretty nasty.

Rather than think about whether I could use try-import-except or had to check the stdlib version I just check the stdlib version everywhere.

Edit: specific context in 00166b3

@roehling
Copy link

I just cherry-picked this PR for Debian. FYI, you should probably drop setuptools from install_requires in setup.py as well, as it implies that setuptools/pkg_resources is needed at runtime and causes Debian's pybuild to emit a dependency on python3-pkg-resources. The proper key for build tool dependencies would be setup_requires, though I doubt you need to make the dependency explicit.

catkin_pkg_v=catkin_pkg.__version__,
# Until https://github.com/ros-infrastructure/rosdistro/issues/16
rosdistro_v=pkg_resources.require("rosdistro")[0].version,
rosdistro_v=importlib_metadata.metadata("rosdistro").version,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be importlib_metadata.metadata("rosdistro").get("version") btw

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants