Fix Python deprecation warnings during build

[tallpsmith]

Summary

Eliminates Python deprecation warnings that appear during the build process by modernizing the Python packaging approach.

Changes

• Replace deprecated setup.py install with pip install in the build system
• Remove deprecated codecs.open() import from setup.py
• Add python3-pip to QA package manifest for all supported platforms (CI build dependency)

Why These Changes Are Safe

codecs.open() removal:
The codecs.open() import was added in 2016 when PCP supported Python 2, where the built-in open() function lacked an encoding parameter. In Python 3 (the only version PCP now supports), the built-in open() natively supports encoding and is the recommended approach. Both functions behave identically for UTF-8 files.

pip install migration:
The setup.py install command has been deprecated by setuptools in favor of standards-based tools like pip. The new approach uses pip install with equivalent flags to achieve the same installation behavior.

python3-pip in manifest:
The pip module is now required for the build process but wasn't installed in most CI environments. Added python3-pip entries to qa/admin/other-packages/manifest for all package managers (dpkg, rpm, emerge, etc.) to ensure pip is available during builds. Verified availability on all supported platforms: Ubuntu 18.04+, Debian 11+, CentOS Stream 8+, Fedora 42+, and others.

Testing

• ✅ Build completes successfully with no deprecation warnings
• ✅ All Python extensions compile correctly
• ✅ No functional changes to the installation process

Fixes #2306

[tallpsmith]

ok, this is working on the Mac because we include python3-pip as a dependency. To fix this we'd need to add that as a dependency to all operating systems. This probably needs discussion @natoscott .

[kmcdonell]

@tallpsmith ...
We need a bit more Build-Depends glue, but that can be added later.
More critically the build out of the fix-python-setup-warning branch of your git tree is not working for Debian. It is failing here ...

=== python ===
export nothing=''; /usr/bin/python3 -m pip install --no-build-isolation --root="${DIST_ROOT:-/}" --prefix=/usr .
Processing /home/kenj/src/pcp-psmith/build/deb/pcp-7.1.0/src/python
  Preparing metadata (setup.py): started
  Preparing metadata (setup.py): finished with status 'done'
Building wheels for collected packages: pcp
  Building wheel for pcp (setup.py): started
  Building wheel for pcp (setup.py): finished with status 'done'
  Created wheel for pcp: filename=pcp-7.0-cp312-cp312-linux_x86_64.whl size=224158 sha256=1975f2bcfd74e786c6038e0a14067177847635e5c3e41f45932add0a1c9c57f5
  Stored in directory: /tmp/pip-ephem-wheel-cache-0dlslsj_/wheels/3a/a4/60/fe3f1b7f899ff1730d6c91c3e1cd9436e2791f93c7f4b6f316 
Successfully built pcp
Installing collected packages: pcp
  Attempting uninstall: pcp
    Found existing installation: pcp 7.0
    Uninstalling pcp-7.0:
ERROR: Could not install packages due to an OSError: [Errno 13] Permission denied: 'pmi.py'
Consider using the `--user` option or check the permissions.

Now this does not look even close to right to me from about the "Attempting uninstall: pcp" line.
I'm afraid I have no knowledge of Python packaging, and plan to keep it that way until I fall off the perch.

[kmcdonell]

@tallpsmith No --record for /usr/bin/python3 -m pip install on Ubuntu.

[tallpsmith]

Yeah @kmcdonell this is looking hairier than Hairy Maclary right now as I dig in. I also have to solve the "how do I run the CI podman setup locally" so that I can easily iterate locally, however I ran into a container architecture mismatch with Apple Silicon that might be another rabbit hole.

I may end up resorting to an Option Claude Code suggested earlier - simply suppress the warnings! :)

[natoscott]

@tallpsmith @kmcdonell see related changes in #2412 - also not yet complete, but very likely we have alot of overlap ... hopefully orthogonal parts of the problem are solved in each.

[tallpsmith]

@tallpsmith @kmcdonell see related changes in #2412 - also not yet complete, but very likely we have alot of overlap ... hopefully orthogonal parts of the problem are solved in each.

Ok, that's good news, maybe your work will supersede this one (I kinda gave up to focus on some other things anyway). Happy to withdraw this (I'll mark it as draft anyway).