[Distutils] platform_python_implementation not implemented.

[Daniel Holth]

That is too bad. markerlib was added to pkg_resources as _markerlib in
2012. It is used for .dist-info metadata as present in wheel. Then, only to
implement markers to setup.py or .egg-info style metadata, pkg_resources
gains its inline markers implementation in 2013, including its own
definitions of the key/values used in environment marker comparisons. Dots
switched to underscores in revision aa74cf234684 in the inline
implementation and in revision 1fc8a2d94f9f for setuptools' vendored
_markerlib.

At some point bdist_wheel gained the ability to use setup.py-defined
environment markers instead of reading them from a separate file,
eliminating a problem keeping two sets of dependencies synchronized (since
wheel needed markers, but existed before setup.py could accept environment
markers).

I would prefer to see _markerlib._VARS used everywhere, the inline
pkg_resources implementation deleted, markerlib improved if necessary, and
no backwards compatibility with unspecified environment marker variables.
My hunch is that no one needs the backwards compatibility.

On Thu, Sep 10, 2015 at 9:47 AM MinRK <benjaminrk at gmail.com> wrote:

> Hello,
>
> 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
> <https://bitbucket.org/pypa/setuptools/src/7a705b610abb1177ca169311c4ee261f3e4f0957/pkg_resources/__init__.py?at=18.3.1&fileviewer=file-view-default#__init__.py-1398>,
> 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
> <https://bitbucket.org/pypa/setuptools/pull-requests/147/make-environment-markers-pep-345-compliant/diff>
> 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.
>
> Thanks,
> -MinRK
> ​
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150910/6634d7ae/attachment.html>