Update entries to use system packages over PyPI ones to prevent shadowing

[BlueberryCatt]

A bunch of Python packages that were previously available only on PyPI have been added as native system libraries in major Linux distributions (e.g., Ubuntu and Debian). According to the contributing guidelines, system packages should be preferred over PyPI ones. This practice helps prevent conflicts that arise when PyPI-installed packages shadow system libraries. In addition, packages built by the ROS buildfarm are prohibited from depending on pip-only keys.

A similar case was discussed in #19058, where PyPI packages were replaced with system libraries once the latter became available.

The following table summarizes several entries that still install packages from PyPI even though equivalent system libraries now exist in Ubuntu and Debian (more exists for other distributions). For each entry, one example package is shown, preferring Ubuntu when available.

Click to show/hide table of entries that now have corresponding system packages

Entry Key	Example Platform	New System Package
python3-flake8-black	Ubuntu Noble	python3-flake8-black
python3-mongomock	Debian Bookworm	python3-mongomock
python3-xmlschema	Ubuntu Noble	python3-xmlschema
python3-fpdf2-pip	Ubuntu Noble	python3-fpdf
python3-anytree-pip	Debian Trixie	python3-anytree
python3-lingua-franca-pip	Ubuntu Noble	python3-lingua-franca
python3-marshmallow-dataclass-pip	Ubuntu Noble	python3-marshmallow-dataclass
python3-openai-pip	Ubuntu Noble	python3-openai
python3-sense-hat-pip	Ubuntu Noble	python3-sense-hat
python3-aio-pika-pip	Ubuntu Noble	python3-aio-pika
python3-ansible-runner-pip	Ubuntu Noble	python3-ansible-runner
python3-backoff-pip	Ubuntu Noble	python3-backoff
python3-fasteners-pip	Ubuntu Noble	python3-fasteners
python3-mapbox-earcut-pip	Ubuntu Noble	python3-mapbox-earcut
python3-padaos-pip	Ubuntu Noble	python3-padaos
python3-spidev-pip	Ubuntu Noble	python3-spidev

Proposed Action:
Update the corresponding entries to prefer system libraries over PyPI packages wherever possible.

[tfoote]

This is mostly resolved in #48659 however I'm going to leave this open as I would like to ask for a slightly different resolution than that. I'm too late for the review on that. But the way that this is implemented means that it will have to be updated every time that there's a new released platform. It's much better practice to have the wildcard be the latest version that's expected in future releases rather than being a catchall backwards compatibilty.

If we use

'*': latest-name
'b': old-name
'c': old-name
'd': old-name

which will work for e, f, and g assuming they stick to the latest name

Versus

'*': old-name
'e': latest-name

This approach is more compact at the moment, however it will require a new separate pull request once each to add f and g.

And it's really hard to clean up wildcards that are supporting older distributions. Whereas if we use the earlier syntax, it's trivial to prune 'b' when it's sufficiently EOL. As mentioned here: #ROS General > Massive software-driven rosdep update?

[BlueberryCatt]

Thanks for your explanation! Actually i chose the latter one because i'm not sure what platforms are currrently targeted from the perspective of rosdistro. Seems that currently Debian Trixie is in use, but not seems to be taken into consideration in rosdistro now. From the config.yaml, the platforms in consideration seems as below:

  ubuntu:
  - focal
  - jammy
  - noble
  ...
  debian:
  - bookworm