Modernize Python packaging without touching deps

[rhaist]

Hi @kk7ds — sorry if this is inappropriate for a drive-by PR, and feel free to close it if the answer is simply "no" — but I'd like to suggest a cleanup of the top-level packaging files. I've marked it as a draft since I know the binary build infrastructure lives outside this repo and I can't test against it.

This consolidates setup.py, setup.cfg, requirements.txt, test-requirements.txt, .mypy.ini and pylintrc into a single pyproject.toml — without changing any dependency or pin:

• The wxPython pins move verbatim (same platform markers, same Phoenix#2225 reference, same "keep in sync with binary builds" comment) to the [wx] extra
• The test dependencies (including the pytest pin) move to a [test] extra; the tox envs use extras = test instead of -rtest-requirements.txt
• pywin32 moves into the main dependencies — it was in requirements.txt but missing from setup.py, so this closes a small gap
• setup.cfg goes away entirely: it only held a bdist_rpm section still describing rpttool ("A frequency tool for Icom D-STAR Repeaters")
• pylintrc goes away: nothing references it (style checks are flake8/mypy via tox)

Verified locally:

• tox -e unit: 481 passed, 12 skipped
• tox -e style: byte-identical mypy results with the old .mypy.ini and the new [tool.mypy] section
• sdist contains the same data files as before (stock configs, locales, icons, MANIFEST.in unchanged apart from the requirements line)
• pip install -e . exposes the same three console scripts
• CI needs no changes — all jobs go through tox
• flake.nix (pip install -e .) and snapcraft (python plugin) both work with pyproject-based builds

The one thing this does change for developers: the wiki's pip install -r requirements.txt step becomes pip install -e '.[wx,test]'. Happy to adjust anything, split this up, or drop parts of it — and if the timing is bad or you'd rather keep the current layout, no hard feelings.

One thing that definitely needs your input: if the build system stamps setup.py's version=0 at build time, that step would need to target version = "0" in pyproject.toml instead.

[kk7ds]

I appreciate it, but I really really just want to own the binary build process. 99% of chirp users are consuming the binary builds and I really need to prioritize that stuff. It'll need to be updated at some point I know, but it has to be done in lockstep with the binary builds. You can leave this open and I can aim to get the other half of the build process working with it at some point, but no promises on timeline.

[rhaist]

@kk7ds I totally understand. This is mainly a feasibility study from my end to see if this modernization can be done while honoring the dependency constraints. I can leave this PR draft open for your reference. Let me know if you need changes or input from me on it when you start working on the topic. Happy to help.

[McNeight]

I understand where Dan is coming from, and I understand that you were going for a "light touch" for consolidating these files, but I'd like to understand something.

Why wasn't tox.ini also incorporated into pyproject.toml? It seems to be an important part of unit and driver testing. At a minimum, I would think the tox package would be added to the project.optional-dependencies.test section?

Thanks for doing this.

[rhaist]

@McNeight Two reasons I left tox.ini alone:

1. The tox.ini also carries the [flake8] configuration, and flake8 has no pyproject.toml support at all — so a migration would still leave config split across two files. tox itself only gained native TOML config in 4.21 (late 2024), so moving it would also impose a fairly new tox version floor on developers for no functional gain.

2. Scope: this PR is deliberately limited to replacing setup.py/setup.cfg, which is forced by setuptools deprecations. tox.ini keeps working indefinitely, so there was nothing to fix there — and given Dan's comment above, keeping the diff minimal seemed right.

On adding tox to project.optional-dependencies.test: tox is the tool that creates the test environment and installs .[test] into it, so listing it inside that extra would be circular. Like pip itself, it belongs in the developer's outer environment rather than in the project's dependencies.

[kk7ds]

Yeah the python community has sort of decided for us that everything should be put into pyproject.toml, which is not universally loved (I certainly don't like it). Been a lot of "deciding for us" lately on a lot of topics :(