Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Moved the metadata into PEP 621-compliant pyproject.toml. #174

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

KOLANICH
Copy link

No description provided.

… package building with Python 2 and old versions of Python 3 which are unsupported by `setuptools` that has `PEP 621` implemented.
@coveralls
Copy link

Coverage Status

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

@JohannesBuchner
Copy link
Owner

Please explain the PR.

@KOLANICH
Copy link
Author

  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
Copy link
Owner

JohannesBuchner commented Sep 15, 2022

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

@JohannesBuchner
Copy link
Owner

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

@JohannesBuchner
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

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.

@JohannesBuchner
Copy link
Owner

Hi @KOLANICH, sorry for the picking this up again so late. In the meantime, python 2 support has been dropped in imagehash. Considering this, could you please update the PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants