So stepping back to the original question On Thu, Sep 10, 2015 at 11:11 PM, MinRK <benjami...@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@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
