[Distutils] platform_python_implementation not implemented.

MinRK benjaminrk at gmail.com
Thu Sep 10 15:11:17 CEST 2015


I’m working on specifying dependencies for a project (IPython) that are
dependent on the Python implementation - we want to depend on a package on
CPython, but not on PyPy. I see from PEPs 345
<https://www.python.org/dev/peps/pep-0345/> and 426
<https://www.python.org/dev/peps/pep-0426/#environment-markers> and 496
<https://www.python.org/dev/peps/pep-0496/> that this should be available
as platform_python_version environment marker, but when I try to use this
in setup.py, it fails, claiming this is an invalid marker (setuptools
18.3.1). I discovered that pkg_resources has its own implementation of
environment markers
which isn’t consistent with any PEPs describing them. pip uses markerlib,
which does seem to implement PEP 345 correctly. The relevant difference in
this case is that pkg_resources misspells platform_python_implementation as
python_implementation, but it is not the only one. Due to the inconsistent
implementations, I don’t think there’s a way to use this environment marker
anywhere. It seems like the whole concept of environment markers is
experimental, and it would be premature to adopt them for any packages in
production. Is this the case?

I found that when I run pip install ., the pkg_resources version is used,
and it will balk at the correct platform_python_version as invalid.
However, when I build a wheel and try to install it with pip install
ipython-...whl, the pip version is used, and it balks at pkg_resources
incorrect python_implementation. This conflict makes it impossible to use
the marker, as far as I can tell. Has anyone been able to use the python
implementation environment marker?

I have a PR
to setuptools to fix what seems to be some inconsistency with the PEPs
while preserving the misspelling for backward-compatibility, but it’s not
clear which metadata/env marker PEPs setuptools and/or pip are meant to
support at this point. It’s also unclear why pkg_resources has its own
implementation, instead of all participants using the shared _markerlib,
which would at least avoid inconsistency.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150910/cb5d8dab/attachment.html>

More information about the Distutils-SIG mailing list