Skip to content

setup.cfg: let python-tag mirror python_requires - #37

Closed
vfazio wants to merge 1 commit into
jaraco:masterfrom
vfazio:bdist-py36
Closed

vfazio wants to merge 1 commit into
jaraco:masterfrom
vfazio:bdist-py36

Conversation

@vfazio

@vfazio vfazio commented Feb 4, 2020

Copy link
Copy Markdown
Contributor

In order to generate a wheel in accordance with PEP 425 to restrict the
minimum required version of Python (3.6), the python-tag bdist_wheel
option needs to be specified so the wheel gets tagged properly.

Before:
zipp-x.x.x-py3-none-any.whl
After:
zipp-x.x.x-py36-none-any.whl

Signed-off-by: Vincent Fazio vfazio@xes-inc.com

closes #36

In order to generate a wheel in accordance with PEP 425 to restrict the
minimum required version of Python (3.6), the `python-tag` bdist_wheel
option needs to be specified so the wheel gets tagged properly.

Before:
	zipp-x.x.x-py3-none-any.whl
After:
	zipp-x.x.x-py36-none-any.whl

Signed-off-by: Vincent Fazio <vfazio@xes-inc.com>
@jaraco

jaraco commented Feb 7, 2020

Copy link
Copy Markdown
Owner

I don't think this recommendation is correct. My quick reading of PEP 425 tells me that py36 means "works on Python 3.6 only". In particular, the FAQ mentions using py3 to mean latest available Python 3. And the specification for the tag seems to imply that the generic versions py2 and py3 are preferable for pure-python implementations, such as this is.

The main place where the required python version is declared in the package metadata (Requires-Python) and not in the build name.

To accept something like this, I'll need much more information, and in particular a demonstration that this change is correct and does what's intended. If you can do that, I'd rather see the change submitted upstream at jaraco/skeleton.

@vfazio

vfazio commented Feb 7, 2020

Copy link
Copy Markdown
Contributor Author

That's not actually how it works. It's a ranked system... if the interpreter supports that version syntax, it will be allowed to install

a wheel marked py37 will not install in a python 3.6 environment. a wheel marked py35 will.

(venv) vfazio@vfazio1 /tmp/tmp.qxSzsOdsMw/zipp $ python -V
Python 3.6.9

(venv) vfazio@vfazio1 /tmp/tmp.qxSzsOdsMw/zipp $ pip install dist/
zipp-0.0.0-py3-none-any.whl     zipp-0.0.0-py37-none-any.whl
zipp-0.0.0-py35-none-any.whl    zipp-0.0.0.linux-x86_64.tar.gz
zipp-0.0.0-py36-none-any.whl    

(venv) vfazio@vfazio1 /tmp/tmp.qxSzsOdsMw/zipp $ pip install dist/zipp-0.0.0-py37-none-any.whl 
ERROR: zipp-0.0.0-py37-none-any.whl is not a supported wheel on this platform.

(venv) vfazio@vfazio1 /tmp/tmp.qxSzsOdsMw/zipp $ pip install dist/zipp-0.0.0-py36-none-any.whl 
Looking in indexes: https://pypi.xes-mad.com/upstream, https://pypi.xes-mad.com
Processing ./dist/zipp-0.0.0-py36-none-any.whl
Installing collected packages: zipp
Successfully installed zipp-0.0.0

<uninstall>

(venv) vfazio@vfazio1 /tmp/tmp.qxSzsOdsMw/zipp $ pip install dist/zipp-0.0.0-py35-none-any.whl 
Looking in indexes: https://pypi.xes-mad.com/upstream, https://pypi.xes-mad.com
Processing ./dist/zipp-0.0.0-py35-none-any.whl
Installing collected packages: zipp
Successfully installed zipp-0.0.0

<uninstall>

(venv) vfazio@vfazio1 /tmp/tmp.qxSzsOdsMw/zipp $ pip install dist/zipp-0.0.0-py3-none-any.whl 
Looking in indexes: https://pypi.xes-mad.com/upstream, https://pypi.xes-mad.com
Processing ./dist/zipp-0.0.0-py3-none-any.whl
Installing collected packages: zipp
Successfully installed zipp-0.0.0

specifying py3 says you support all python 3 minor versions. that is not the case for this package based on the requirements

@vfazio

vfazio commented Feb 7, 2020

Copy link
Copy Markdown
Contributor Author

Note that this is documented here:

https://www.python.org/dev/peps/pep-0425/#id14

though it doesn't directly describe the situation that a tag for a higher version is rejected. since the version of tuples supported is based on the version of python running, the greatest version allowed will be py{major}{minor} as it has no concept of py{major}{minor+1}. This explains why a py37 or py38 tag cannot install in a Python 3.6.x environment

@jaraco

jaraco commented Feb 7, 2020

Copy link
Copy Markdown
Owner

Yes, I see that.

It is recommended that installers try to choose the most feature complete built distribution available (the one most specific to the installation environment) by default before falling back to pure Python versions published for older Python releases.

It's annoying that the build tools are leaving it to the user to manually declare these values. I'll file an issue with the wheel project to possibly default to a python tag that reflects the python_requires directive and I'll port this commit to the jaraco/skeleton project so it can affect all the projects.

@jaraco

jaraco commented Feb 7, 2020

Copy link
Copy Markdown
Owner

I've rebased your commit onto jaraco/skeleton@0b681b0, which should be merged in here shortly.

jaraco added a commit that referenced this pull request Jan 30, 2021
* Replace pep517.build with build

Resolves #30

* Prefer simple usage

Co-authored-by: Jason R. Coombs <jaraco@jaraco.com>
jaraco added a commit that referenced this pull request Jan 30, 2021
* Use `extend-ignore` in flake8 config

This option allows to add extra ignored rules to the default list
instead of replacing it.

The default exclusions are: E121, E123, E126, E226, E24, E704,
W503 and W504.

Fixes #28.

Refs:
* https://github.com/pypa/setuptools/pull/2486/files#r541943356
* https://flake8.pycqa.org/en/latest/user/options.html#cmdoption-flake8-extend-ignore
*
https://flake8.pycqa.org/en/latest/user/options.html#cmdoption-flake8-ignore

* Enable complexity limit. Fixes jaraco/skeleton#34.

* Replace pep517.build with build (#37)

* Replace pep517.build with build

Resolves #30

* Prefer simple usage

Co-authored-by: Jason R. Coombs <jaraco@jaraco.com>

* Use license_files instead of license_file in meta (#35)

Singular `license_file` is deprecated since wheel v0.32.0.

Refs:
* https://wheel.readthedocs.io/en/stable/news.html
* https://wheel.readthedocs.io/en/stable/user_guide.html#including-license-files-in-the-generated-wheel-file

Co-authored-by: Jason R. Coombs <jaraco@jaraco.com>
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.

incorrect interpreter specified in wheel

2 participants