Moved the metadata into `PEP 621`-compliant `pyproject.toml`.

[KOLANICH]

[coveralls]

Coverage decreased (-2.4%) to 87.762% when pulling 91819510e154a989649535a16777a8066bea8cae on KOLANICH-libs:pyproject.toml into 8c774c00824f07797fa9cc21f4b5ab9c7bf8f6b6 on JohannesBuchner:master.

[JohannesBuchner]

Please explain the PR.

[KOLANICH]

1. The first commit moves the data from Turing-complete setup.py into a declarative setup.cfg supported by setuptools since 2016. But the actual support of setup.py-less packages has appeared later with PEP 517 being implemented in setuptools. pyproject.toml added in that commit implements PEP 517 and allows to build a package using python3 -m build. No execution of Turing-complete code happens, which is a security benefit. Also declarative config can be parsed by other tools.
2. setup.cfg was a messy dialect of ini that can be properly parsed using setuptools or an own reinventions of a wheel. Unlike setup.cfg pyproject.toml is a proper TOML that can be parsed and serialized by any lib for dealing with TOML. Since PEP 517 got implemented analogues to setuptools have been created. Each initially used an own format of metadata stored in pyproject.toml. In order to decrease amount of mess PEP 621 has been created, that defines the format multiple build backends have implemented reading, so with it it is easier to switch a build backend. This year setuptools got support of PEP 621, so I have migrated the metadata to it.
3. Also pip enables PEP 660 only when PEP 621 is used. When PEP 660 is used the issue with editable installs on Debian-based distros when setuptools is used is worked around.

[JohannesBuchner]

I am surprised this works also for the old pythons (2.7, 3.5), at least according to the CI.

[JohannesBuchner]

Maybe then the flake8 config should also move there to remove that file.

[JohannesBuchner]

The previous CI tested the pip install . command a user may use after downloading the git repo. I think this should still be tested, perhaps in addition to the wheel build&install? What do you think?

[KOLANICH]

The previous CI tested the pip install . command a user may use after downloading the git repo. I think this should still be tested, perhaps in addition to the wheel build&install? What do you think?

It won't work.setuptools has dropped support of old Python versions. Since now users of old python versions cannot install the sdists of imagehash (because under the hood pip install . still builds a wheel, and since now they cannot build a wheel (well, if they backport setuptools to old versions, they can, but who will do it, if it is easier to just upgrade python (well, not easier, python has dropped Windows XP long ago, so python has to be backported too (I have heard that there were unofficial builds of cpython by third parties supporting XP, but I have never used them and don't even remember where I can download them), also 3.9 has dropped Windows 7 (which is not an issue for the purpose of this PR, since PEP621-compatible setuptools requires only 3.7, but still has to be mentioned, if were are talking about version compatibility), fortunately it is worked around well by https://github.com/nalexandru/api-ms-win-core-path-HACK ) ?) ), only prebuilt wheels.

[JohannesBuchner]

Then I am not sure how this PR can be merged and a single python 2.7-3.10 install from source instruction provided.

[KOLANICH]

The first commit within it is compatible to both 2.7 and 3.4. Only the second one drops the possibility to build the packages on 3.5.