[Distutils] platform_python_implementation not implemented.

[James Polley]

So stepping back to the original question

On Thu, Sep 10, 2015 at 11:11 PM, 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?
>
Several OpenStack projects have started using markers to replace the
previous hack of having separate requirements.txt files for py2 and py3. I
don't think they've run into any issues, as long as the system interpreting
the markers isn't relying on something crazy like the system-installed
setuptools or pip, which can (on an LTS release) sometimes be very very old
indeed.

I'm not sure what that would mean for ipython's use-case. If you have a
chance to stipulate (or document how to install recent versions of
setuptools and pip you should be okay; if you need to support users on very
old versions of python/pip/setuptools you might have problems.

https://rbtcollins.wordpress.com/2015/07/12/bootstrapping-developer-environments-for-openstack/
has Rob Collin's suggestions on setting up a dev environment for OpenStack;
he side-steps the issue of getting setuptools and pip up-to-date by just
instruction the reader to install virtualenv from source and then use the
source-installed version of virtualenv to create an environment that all
further work can be done inside. Virtualenv bundles the latest pip and
setuptools, so this is a simple way to make sure the user has a recent
version of those tools, as well as a way to get away from any other
outdated packages the user might have in their environment

> 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?
>
Ouch.

> 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!

> 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/20150916/0a860297/attachment-0001.html>