Mailman 3 July 2013 - Distutils-SIG

SSL problem with PyPI?
by Vinay Sajip 31 Jul '13

31 Jul '13

I've just started getting PyPI failures because the SSL certificate being presented by pypi.python.org is only valid for addvocate.com. Can anyone shed some light on this? Regards, Vinay Sajip

2 2

PEP 426 installation hooks and conventions
by Vinay Sajip 30 Jul '13

30 Jul '13

I'm looking at PEP 426 specifications for installation hooks and wondering whether we need to tighten up the specification a little. My concern stems from the fact that hook code needs to be installed along with other code - at least, the code for preuninstall hooks needs to be in the installed code. As it's "only" hook code, the naming of modules which contain it may not be done as carefully as the substantive modules and packages in a distribution. However, if multiple distributions were to put their hooks in a "hooks.py" module, which might seem the simplest thing to do, that could lead to problems: if these hook modules get written to site- packages, the hooks.py from a later installed distribution would override that from an earlier installed distribution. Possible solutions: 1. Constrain the specification so that each distribution must put hook code in a subpackage of one of their main packages. This will affect any distribution that consists only of modules and which has no packages, as the authors will have to create a package just for the hook code. 2. Constrain the specification so that hook code is segregated to a single module, perhaps specified by a "hook_module" key in the "install_hooks" dict, which is written to the .dist-info directory. An installer could add the .dist-info to sys.path before resolving/importing. The code in the hooks module could invoke any code it needed from the main body of code in the distribution. Is my concern a valid one? If so, can I please have comments/suggestions about how to address it? Regards, Vinay Sajip

2 1

Ubuntu says Virtualenv, Pip and Setuptools "untrusted"
by Erik Bernoth 30 Jul '13

30 Jul '13

Hi everybody, did you know that Ubuntu 13.10 (or maybe Debian?) declares those packages as untrusted and asks you twice, if you really want to install them? Is there anything that can be done about that? Best Erik

3 2

Shebang lines, /usr/bin/python, and PEP394
by Toshio Kuratomi 27 Jul '13

27 Jul '13

Over on python-dev we're talking about Linux Distributions switching from python2 to python3, what steps they need to take and in what order. One of the things that's come up [1]_ is that a very early step in the process is making sure that shebang lines use /usr/bin/python2 or /usr/bin/python3 as noted in PEP394 [2]_. Faced with the prospect of patching a whole bunch of scripts in the distribution, I'm wondering what distutils, distlib, setuptools, etc do with shebang lines. * Do they rewrite shebang lines? * If so, do they use #!/usr/bin/python2 or do they use #!/usr/bin/python ? * If the latter, is there hope that we could change that to match with PEP-394's recommendations? (setuptools seems to be moving relatively quickly these days so that seems reasonably easy.... distutils is tied to the release schedule of core python-2.7.x although if the change is accepted into the CPython tree we might consider backporting it to the current distribution package early. .. [1]_: http://mail.python.org/pipermail/python-dev/2013-July/127565.html .. [2]_: http://www.python.org/dev/peps/pep-0394/#recommendation Thanks, Toshio

8 11

pip - installation of the latest stable version of package
by Piotr Dobrogost 25 Jul '13

25 Jul '13

Hi! Does pip support installation of the latest _stable_ version of package (for all versions which adhere to PEP386)? Related - "Do not upload dev releases at PyPI" by Tarek Ziadé<http://ziade.org/2011/02/15/do-not-upload-dev-releases-at-pypi/>at http://ziade.org/2011/02/15/do-not-upload-dev-releases-at-pypi/<http://ziade.org/2011/02/15/do-not-upload-dev-releases-at-pypi/> Regards, Piotr Dobrogost <http://ziade.org/2011/02/15/do-not-upload-dev-releases-at-pypi/>

4 3

get-pip.py user installation issue
by Alex Burke 23 Jul '13

23 Jul '13

Hey, I was recently trying to do an all user installation of the packaging tools and (though I know this may change), was unable to use get-pip.py to install pip user locally as per PEP 370. Currently, instead of doing the ideal: # install pip $ curl https://raw.github.com/pypa/pip/master/contrib/get-pip.py | python - --user I instead had to download the pip tarball, unpack it, and use setup.py to manually pass in --user as follows: # install pip $ curl -O https://pypi.python.org/packages/source/p/pip/pip-1.3.1.tar.gz $ tar xvfz pip-1.3.1.tar.gz $ cd pip-1.3.1 $ python setup.py install --user I think this happens because there is no code to pass down command line options into the pip bootstrap() called on de-serialisation. By contract this is possible to install setuptools locally: # install stuptools curl https://bitbucket.org/pypa/setuptools/raw/0.7.8/ez_setup.py | python - --user Am I right in thinking this is a problem? If so, but in case patching this is a non starter as it will be replaced by a bootstrap script installing a wheel, perhaps that may need to respect the --user argument? Thanks, Alex J Burke.

2 2

[issue156] SSL errors when using https proxy
by Chris Jones 23 Jul '13

23 Jul '13

New submission from Chris Jones: >From an image building script from diskimage-builder (part of OpenStack): + echo 'http_proxy: http://10.0.88.68:3128/' http_proxy: http://10.0.88.68:3128/ + echo 'https_proxy: http://10.0.88.68:3128/' https_proxy: http://10.0.88.68:3128/ + bash root@stonker:/# easy_install os-apply-config Searching for os-apply-config Reading https://pypi.python.org/simple/os-apply-config/ Download error on https://pypi.python.org/simple/os-apply-config/: [Errno 1] _ssl.c:504: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol -- Some packages may not be found! Couldn't find index page for 'os-apply-config' (maybe misspelled?) Scanning index of all packages (this may take a while) Reading https://pypi.python.org/simple/ Download error on https://pypi.python.org/simple/: [Errno 1] _ssl.c:504: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol -- Some packages may not be found! No local packages or download links found for os-apply-config error: Could not find suitable distribution for Requirement.parse('os-apply-config') root@stonker:/# (the proxy URL is a very close to stock squid3 configuration on another machine on my LAN, which is used elsewhere in the building script to download OS images, etc, so is not believed to be the issue). Reading through the setuptools code, I wondered if this is because the VerifyingHTTPSHandler inserted into the urllib2 opener chain, is trying to do direct socket connections. At the point it does that, I inserted a call to has_proxy() on the Request object and it returned False, which confused me as I would expect ProxyHandler to still be in the opener chain. ---------- messages: 741 nosy: cmsj priority: bug status: unread title: SSL errors when using https proxy _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue156> _______________________________________________

1 0

Q about best practices now (or near future)
by Brett Cannon 23 Jul '13

23 Jul '13

I'm going to be pushing an update to one of my projects to PyPI this week and so I figured I could use this opportunity to help with patches to the User Guide's packaging tutorial. But to do that I wanted to ask what the current best practices are. * Are we even close to suggesting wheels for source distributions? * Are we promoting (weakly, strongly?) the signing of distributions yet? * Are we saying "use setuptools" for everyone, or still only if you need it (asking since there is a stub about installing setuptools but the simple example doesn't have a direct need for it ATM, but could use find_packages() and such)?

13 126

Wheels and console script entry point wrappers (Was: Replacing pip.exe with a Python script)
by Paul Moore 22 Jul '13

22 Jul '13

On 16 July 2013 13:42, Ronald Oussoren <ronaldoussoren(a)mac.com> wrote: > > On the other hand, I'm missing something, as I don't see how the > *current* exe wrappers avoid meaning that there need to be separate 32-bit > and 64-bit versions of pip... > > Couldn't you just ship both variants of the exe wrappers in a single > distribution and then use the correct one for the current installation? > That's what I'm doing in py2app. That's OK for source-style installs (which is what setuptools does, and what pip mostly cares about right now). But for bundling with Python it needs to be considered (although it's just getting the right one in the right installer). But for wheels it's a pain, because instead of having just a single pip wheel, we need 32-bit and 64-bit wheels solely for the wrappers. That sucks. Hard. (And it's not just for pip, nose will have the same problem, as will many other projects that use exe wrappers). And the bdist_wheel command currently doesn't recognise this *at all*. So wheels using wrappers are potentially broken. I think the correct solution is to explicitly have declarative support for "console script entry point" metadata in PEP 426, as well as having tools like bdist_wheel and distil do some explicit backward compatibility hacking to remove legacy-style exe wrappers. The wheel install code should then explicitly install appropriate wrappers for the target platform (which may be exe wrappers similar to the current ones, but moving forward may be some other mechanism if one is found). This is complex enough that I'm now concerned that we need reference "wheel install" code in the stdlib, just so that people don't make up their own on the basis that "wheel is simple to install manually" and screw it up. Also so that we only have one style of command line script wrapper to deal with going forward, not a multitude of mostly-compatible solutions. Nick: See the above point re PEP 426 - do you agree that this needs addressing in Metadata 2.0? Paul PS There is still the proviso that I haven't tested my assumption that the separate 32 and 64 bit wrappers are *needed* (setuptools and distlib use them, so I think it's a valid assumption, but I need to test). I will try to get time to check that ASAP.

9 33

entry points PEP
by Daniel Holth 20 Jul '13

20 Jul '13

Abstract This PEP proposes a way to represent the setuptools “entry points” feature in standard Python metadata. Entry points are a useful mechanism for advertising or discovering plugins or other exported functionality without having to depend on the module namespace. Since the feature is used by many existing Python distributions and not everyone wants to use setuptools, it is useful to have a way to represent the functionality that is not tied to setuptools itself. The proposed feature defines an extension field for the standard Python distribution metadata and some basic semantics for its use. Overview Entry points are represented as an extension in the metadata: { … “extensions”: { “entry_points” : { … } } } The extension contains the data in a dictionary format similar to that accepted by setuptools’ setup(entry_points={}) keyword argument. It is a dictionary of “group” : [ “key=module.name:attrs.attrs [extra, extra2, ...]”, ]. “group” is the name of this class of entry points. Values in common use include “console_scripts” and “sqlalchemy.dialects”. During discovery, clients usually iterate over all the entry points in a particular group. “key” is the name of a particular entry point in the group. It must be locally unique within this distribution’s group. “module.name” is the Python module that defines the entry point. Client code would import the module to use the entry point. “:attrs.attrs” are the optional attributes of the module that define the entry point (the module itself can be the entry point). Client code uses normal attribute access on the imported module to use the entry point. “[extra, extra2, ...]” are any optional features of the distribution (declared with “extras”) that must be installed to use the declared entry point. This is not common. Complete example { … “extensions”: { “entry_points” : { { “sqlalchemy.dialects” : [ “mysql = sqlalchemy_mysql:base.dialect”] } } } } Use Client code reads every distribution’s metadata file on sys.path, filtering for the entry point group name desired, and, if applicable, the individual entry point name. Once the desired entry point has been found, a utility function imports the necessary module and attribute to return an object which can be inspected or called. distlib and setuptools’ pkg_resources provide APIs for this functionality.

9 25