Distutils-SIG December 2014

distutils-sig@python.org

43 participants
47 discussions

Varying dependencies by python minor version (2.7.9)

by Ben Darnell

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

6 years, 9 months

Are there any plans to move to pip/wheels in buildout?

by Piotr Dobrogost

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

6 years, 9 months

Pypi to enforce wheel, python3 - is it possible?

by Evgeny Sazhin

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 years, 9 months

SNI support in pip

by Wichert Akkerman

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.

6 years, 9 months

Proposal: using /etc/os-release in the "platform tag" definition for wheel files

by Nick Coghlan

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

6 years, 9 months

Standard packaging API? (was Re: Are there any plans to move to pip/wheels in buildout?)

by Jim Fulton

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

6 years, 9 months

Package's declared latest version ignored by Warehouse

by Ben Finney

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

6 years, 9 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG December 2014