Switch to pyproject.toml

[schaefi]

setup.py is marked obsolete for a long time and with this commit pyproject.toml is introduced and used for the development environment setup.

To be more clear, calling setup.py as a tool is deprecated:

• https://packaging.python.org/en/latest/discussions/setup-py-deprecated/#what-commands-should-be-used-instead

The changes here refactors kiwi to no longer call setup.py in any way

[schaefi]

@Conan-Kudo I'm pro switching to poetry. I just opened this PR to show a bit of my experiments with moving away from setup.py and the issues I had and still have with it

[schaefi]

Related to #2370

[schaefi]

Added more cleanup tasks:

• Makefile is free from setup.py usage now. For building the sdist tarball for the package build we now use python -m build which of course requires the python build module to be present on the host. pip install build
• The upload to pypi happens now as a wheel and no longer sdist, this is done by tox calling python -m build for the release target which defaults to wheel

[schaefi]

setup.py now only holds settings that cannot (or I did not understand how to add them) be used in pyproject.toml. These settings are mainly scripts and entry-points and the license. See the dynamic section

dynamic = [
    "license",
    "entry-points",
    "scripts"
]

ideas welcome

[schaefi]

setup.py is currently only actively called in the .spec file for installing

python3 setup.py install --prefix=%{_prefix} --root=%{buildroot} %{?is_deb:--install-layout=deb}

If we want to change this it would mean:

• switch to wheel and call python installer the-wheel
• This creates a dependency to the installer module which I'm not sure exists for all distros
• We could delete the requirement for setuptools consequently
• Our source tarball would be a wheel instead of a tarball. This causes the problem that we add other data e.g the man pages to the source tarball and I don't know how to modify a wheel

[schaefi]

@Conan-Kudo I made some progress here, if you have a free minute would be nice if you can take a look at the changeset.

[schaefi]

@Conan-Kudo I finished my changes regarding setup.py. I think it is in a review-able state now. My main concern is the change on the .spec file level. I'm not sure if BuildRequires: python%{python3_pkgversion}-installer resolves correctly on all distros we support. Thus I still have the no merge label active

[Conan-Kudo]

We cannot merge this until we drop support for old distributions as stated in #2369. Because otherwise this will be broken for half of our supported platforms.

[schaefi]

We cannot merge this until we drop support for old distributions as stated in #2369. Because otherwise this will be broken for half of our supported platforms.

I thought with the last commit there should be a safe fallback for these cases, no ?

[Conan-Kudo]

You ripped all the data out of setup.py, so now we need something to process pyproject.toml to build properly.

[Conan-Kudo]

You could try moving the data into a setup.cfg file and tell pyproject.toml that we use setuptools to build. I think that's backward compatible.

[schaefi]

You ripped all the data out of setup.py, so now we need something to process pyproject.toml to build properly.

I might be missing all details but to my understanding only the direct call of setup.py as a command is obsolete. Meaning setuptools and the use of pyproject.toml in combination with setup.py is still a supported combination. With the current changeset I tried building for a distro that has build and installer python modules available and I also tried building against SLE15 which is py3.6 and there are not out of the box build and installer modules available. The spec tries to create the wheel and fails and as fallback continues with "setup.py install" as we had it before and that worked without any issues. Thus I wonder where the changes here breaks the backward compatibility. I admit that I haven't looked into all details and after effects.

I will close this PR and re-open it against the kiwi-10 branch. I think there we definitely need to move away from setup.py