migrate from setup.py to pyproject.toml

[deltragon]

Description

This PR switches configuration from setup.py to pyproject.toml.

This is somewhat of a prerequisite in the plan discussed in #589.
Most of the tools there (type checkers, nox/tox, ruff) expect to be configured with a pyproject.toml file.
This documentation also "strongly recommends" using a pyproject.toml file in some form.

In theory, it would be enough to just use the [build-backend] table, and keep the setup.py mostly as-is.
However, when a pyproject.toml file is detected, it also enables build isolation automatically.

Build isolation means that the way .mo files were generated needs to be changed (it is now a custom build step), and the data_files key is deprecated, so I decided to properly migrate everything to pyproject.toml.

The only thing this should have an impact on is building the release. I have tested locally, and using python -m build properly builds the .whl and .tar.gz as before, with identical contents apart from some metadata differences.

[deltragon]

Move reviews over from #641.

[nifadyev]

LGTM

[archisman-panigrahi]

I am not very familiar with this. Will Debian packaging/PPA still work if we migrate away from setup.py?

[deltragon]

@archisman-panigrahi
I followed the recommendation here and added pybuild-plugin-pyproject to the build dependencies.
With that, running debuild -b -uc -us on Debian 12 leaves me with a working .deb file there.
What is the workflow for building the PPA? If that uses Debian's tools, then it should also work there seamlessly.

[deltragon]

(If we want to automate this, we could try to use https://github.com/marketplace/actions/build-debian-packages? That should be able to ensure that the package builds successfully.)

[archisman-panigrahi]

I tried building it in Launchpad. While it builds for ubuntu 24.04 and 24.10 (both have python3.12), it does not build in 22.04 (python3.10), with the error

I: pybuild plugin_pyproject:107: Building wheel for python3.10 with "build" module
I: pybuild base:239: python3.10 -m build --skip-dependency-check --no-isolation --wheel --outdir /<<PKGBUILDDIR>>/.pybuild/cpython3_3.10 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pep517/in_process/_in_process.py", line 363, in <module>
    main()
  File "/usr/lib/python3/dist-packages/pep517/in_process/_in_process.py", line 345, in main
    json_out['return_val'] = hook(**hook_input['kwargs'])
  File "/usr/lib/python3/dist-packages/pep517/in_process/_in_process.py", line 261, in build_wheel
    return _build_backend().build_wheel(wheel_directory, config_settings,
  File "/usr/lib/python3/dist-packages/setuptools/build_meta.py", line 230, in build_wheel
    return self._build_with_temp_dir(['bdist_wheel'], '.whl',
  File "/usr/lib/python3/dist-packages/setuptools/build_meta.py", line 215, in _build_with_temp_dir
    self.run_setup()
  File "/usr/lib/python3/dist-packages/setuptools/build_meta.py", line 158, in run_setup
    exec(compile(code, __file__, 'exec'), locals())
  File "setup.py", line 7, in <module>
    from setuptools.command.build import build as OriginalBuildCommand
ModuleNotFoundError: No module named 'setuptools.command.build'
* Building wheel...

ERROR Backend subproccess exited when trying to invoke build_wheel
E: pybuild pybuild:369: build: plugin pyproject failed with: exit code=1: python3.10 -m build --skip-dependency-check --no-isolation --wheel --outdir /<<PKGBUILDDIR>>/.pybuild/cpython3_3.10 
dh_auto_build: error: pybuild --build -i python{version} -p 3.10 returned exit code 13
make: *** [debian/rules:3: build] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

We can decide to not support 22.04 anymore, but I don't see why it does not seem to work with python 3.10.

[archisman-panigrahi]

What is the workflow for building the PPA? If that uses Debian's tools, then it should also work there seamlessly.

Yes, it builds like any other debian package

[deltragon]

Hmm, the issue here doesn't seem to be Python 3.10, but the version of setuptools in 22.04 - according to this, setuptools needs to be at 65.2.0 or higher, but 22.04 only has 59.6.0.

That said, when I revert the last commit, it also builds correctly on Debian 12 (albeit with warnings that setup.py is deprecated).
I've pushed the revert, can you test again?

[archisman-panigrahi]

@deltragon I am ready to test everything this weekend. From what I understand, this PR (#639) and #615 don't have anything to do with the GTK4 transition.

#652, #655 and #576 are necessary for the GTK4 transition (#561). Is that correct?
Can I still test #652, #655 and #576 without merging the GTK4 PR?

If so, my plan is to merge this PR, then test #652, #655 and #576 one by one, and then go to #561. Is that a good plan?

[deltragon]

The order you quoted makes sense to me.
However, there's actually less interdependence - this PR and #576 are completely independent, and technically #652 and #655 are also independent of eachother (Although it makes sense to do #652 first, as without it some functionality is just outright broken.)
The only hard dependence is that #655 needs to be merged for #561 to be tested.

So yeah, the order I'd say is merge #652, then #655, and then you can test #561 properly.
This PR, #615, and #576 can be merged whenever.