Tornado depends on backports.ssl_match_hostname on python 2, but this is no
longer needed with (cpython) 2.7.9. We have a PR to make this dependency
conditional on the minor version of python (
https://github.com/tornadoweb/tornado/pull/1276/files). We could also make
the test something like `hasattr(ssl, 'SSLContext')`, which would be more
compatible with pypy and other implementations, but the fundamental issues
remain. Is it a good idea to distribute packages that will install
different dependencies on different minor versions of python? Is it even
possible with binary distributions? I'm thinking it's probably best to just
live with the unused extra dependency (until we can completely drop support
for python versions without modern ssl libraries), but I wanted to check
and see if there is a clean way to deal with this.
Are there any plans to move from easy_install/eggs to pip/wheels in buildout?
I have an impression that buildout project has stagnated which is
unfortunate taking into consideration how much python packaging has
It seems that according to the
it is more or less settled that the setuptools/pip/wheel is the way to
One of the problems though is that there is plenty of packages on Pypi
that are not there yet.
Is there any plan to create some incentives for package maintainers to
provide WHEEL files together with source archives?
May be Pypi could say that starting from such date it recommends to
supply the wheel with the source and then starting from such date it
will require it?
There is probably no better way to make the things move faster like
the central repository committing to the certain way of doing things.
Is that possible?
Same thing could be done with python3 - ask people to provide py3
versions along with py2, and then start requiring the packages to be
python3 or universal.
Any opinions? Does anybody know if there is already such initiative?
I just noticed that pip does not support SNI (on Python 2.7.8). This is a bit problematic for us since we use a private index on a server using SNI, and right pip always aborts with a certificate error. I found a year old ticket that seems related (https://github.com/pypa/pip/issues/1511 <https://github.com/pypa/pip/issues/1511> ) which suggested installing pyOpenSSL, pyasn1 and ndg-httpsclient as a workaround. This did not work for me either: I got a link error during installation.
I am wondering: with Python 2.7.9 about to be released with a backport of Python 3’s ssl module, can pip start supporting SNI without any external dependencies? That would be a huge help for people who need to use SNI.
We've discussed the idea of changing the wheel file naming scheme to
deal with Linux previously, but never put together a concrete
The closest we've got is the idea of allowing the platform tag to be
customised in pip and perhaps bdist_wheel, and while that's good from
an "enabling experimentation" perspective, it may be overkill if the
primary goal is just to better support handling of Linux distros.
For starters, here's the current definition of the platform tag in PEP 425:
The platform tag is simply distutils.util.get_platform() with all
hyphens - and periods . replaced with underscore _ .
Here's my proposed change:
The default platform tag is distutils.util.get_platform() with all
hyphens - and periods . replaced with underscore _ . If
/etc/os-release [N] exists on the system, then the values in the 'ID'
and 'VERSION_ID' fields are read, all hyphens - and periods . replaced
with underscore _ , and the results appended to the default tag after
a separating underscore."
The [N] reference would then be a reference to
the definition of the format of os-release. (Note that while the
format originated with systemd, plenty of distros have also started
providing it regardless of which init system they use)
Now, this slightly overspecifies on the *consumer* side. A binary
wheel that works on "rhel_7_0" for example, should almost certainly
work on "rhel_7_1". However, that can be addressed on the tooling side
(e.g. permitting the specification of "additional compatible
platforms" when invoking pip), rather than needing to be in the
This also won't help with older Linux distros that don't offer
/etc/os-release, but I'm OK with that - those can just continue to
show up as "linux_x86_64", and PyPI can continue to disallow those
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
On Mon, Dec 1, 2014 at 8:55 AM, Piotr Dobrogost
> Are there any plans to move from easy_install/eggs to pip/wheels in buildout?
Buildout doesn't really use easy_install. It uses
setuptools. Originally, I tried to use easy_install directly (and do
in some special cases where I shouldn't), but I needed a real API,
which is why I moved down to setuptools. My hope is that some new API
will emerge to replace setuptools.
> I have an impression that buildout project has stagnated
I prefer to say it's stable. :)
A great sign is that other folks on the project have driven recent work.
> which is
> unfortunate taking into consideration how much python packaging has
> changed recently.
Buildout as it, is is entirely dependent on setuptools to add wheel
support, at least until a new API emerges.
AFAIK, pip doesn't provide an API for use by other tools. I'd be very
happy to find out I'm wrong.
I hope there's room for more than one command-line tool for working
with packages in the ecosystem. It would be crazy for each tool to
implement the low-level packaging machinery separately. We need a
library to replace setuptools that pip uses and that other tools can
The Warehouse is ignoring the feature of PyPI which sets particular
versions of a package visible or not visible. It makes all versions
This is a problem when, for example, a package has been uploaded but
should not be shown by default.
An example is the ‘python-daemon’ package. At PyPI, the latest visible
version is 1.5.5, as requested by the package maintainer. That is
reflected as the default version shown at
<URL:https://pypi.python.org/pypi/python-daemon/>. Also, when viewing
other versions, the “Latest version” link appears, and correctly shows
that the latest version is 1.5.5.
But at Warehouse, the settings for which versions should be hidden are
ignored by the application, and a different version is shown by default
<URL:https://warehouse.python.org/project/python-daemon/>. That page
should show version 1.5.5, as selected by the package maintainer in the
\ “He who allows oppression, shares the crime.” —Erasmus Darwin, |
`\ grandfather of Charles Darwin |