Mailman 3 December 2014 - Distutils-SIG

Varying dependencies by python minor version (2.7.9)
by Ben Darnell 12 Dec '14

12 Dec '14

Hi distutils-sig, 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. Thanks, -Ben

2 1

Are there any plans to move to pip/wheels in buildout?
by Piotr Dobrogost 07 Dec '14

07 Dec '14

Hi, 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 changed recently. Regards, Piotr Dobrogost

10 20

Pypi to enforce wheel, python3 - is it possible?
by Evgeny Sazhin 07 Dec '14

07 Dec '14

Hello, It seems that according to the https://python-packaging-user-guide.readthedocs.org/en/latest/current.html it is more or less settled that the setuptools/pip/wheel is the way to go forward. 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? Thanks, Eugene

6 8

SNI support in pip
by Wichert Akkerman 02 Dec '14

02 Dec '14

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. Regards, Wichert.

4 3

Proposal: using /etc/os-release in the "platform tag" definition for wheel files
by Nick Coghlan 02 Dec '14

02 Dec '14

We've discussed the idea of changing the wheel file naming scheme to deal with Linux previously, but never put together a concrete proposal. 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 _ . * win32 * linux_i386 * linux_x86_64 ================= 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." Examples: * win32 * macosx_10_6_intel * linux_x86_64_fedora_20 * linux_x86_64_rhel_7_0 * linux_x86_64_debian_7_0 * linux_x86_64_ubuntu_14_04 ================= The [N] reference would then be a reference to http://www.freedesktop.org/software/systemd/man/os-release.html for 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 specification. 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 uploads. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

8 15

Standard packaging API? (was Re: Are there any plans to move to pip/wheels in buildout?)
by Jim Fulton 02 Dec '14

02 Dec '14

On Mon, Dec 1, 2014 at 8:55 AM, Piotr Dobrogost <p(a)lists-2014.dobrogost.net> wrote: > 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 use. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton

5 4

Package's declared latest version ignored by Warehouse
by Ben Finney 02 Dec '14

02 Dec '14

Howdy all, The Warehouse is ignoring the feature of PyPI which sets particular versions of a package visible or not visible. It makes all versions visible regardless. 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 PyPI database. -- \ “He who allows oppression, shares the crime.” —Erasmus Darwin, | `\ grandfather of Charles Darwin | _o__) | Ben Finney

3 5