Mailman 3 October 2013 - Distutils-SIG

A portable version of pip
by Paul Moore 21 Oct '13

21 Oct '13

With all of the current interest in bundling pip with the Python distribution, I had a sudden thought. Vinay has developed a package called pyzzer (https://pypi.python.org/pypi/pyzzer) that bundles up Python modules into runnable single-file executables. Using a command pyzzer -m pip:main -l t64 -o pipsa.exe -s "#!python" -r <path-to-pip>\pip you can build a single-file executable version of pip that can install wheels (it can't install sdists until setuptools is installed, because installing sdists depends on having setuptools at install time). The -s "#!python" is not needed on Unix as the default is "#!/usr/bin/env python". Also the -l t64 is a Windows requirement to get an exe - you can produce a cross-platform pyz archive without it (see the pyzzer docs for details). This requires the latest development version of pip (which contains a fix for running pip from an uninstalled zipfile) and the following patch to pip\__init__.py: Change: from pip import cmdoptions to: import pip.cmdoptions cmdoptions = pip.cmdoptions This fixes a recursive-import issue - I'll update pip "real soon now" (TM) for this. This is just an experiment at the moment - I've done minimal testing but it seems to work as I'd expect. It may be worth thinking about, though - either as an alternative to bundling (a bit late, I know) or as a way of providing pip for earlier versions of Python. Hope this is of interest. Paul

2 4

post install hook
by Thomas Güttler 21 Oct '13

21 Oct '13

Hi, I can live without a post-install hook. But I think the documentation of setuptools should contain information about this. https://bitbucket.org/pypa/setuptools/issue/92/docs-post-install-hook

2 1

Warehouse - Simple API
by Donald Stufft 20 Oct '13

20 Oct '13

I've recently deployed the current Warehouse code. So far the simple API has been implemented and it would be great if people could point their installers to it and report back to me if they run into any problems. The current PyPI simple api is not documented at all so I've had to reverse engineer it going from what I know, pip, etc. Ideally if i've missed anything it will be found out with testing from y'all. You can try the warehouse code by setting your installers to use the url https://preview-pypi.python.org/simple/ . This url *will* be removed eventually so do not depend on it. It is backed by the same database as PyPI so all of the same packages should exist and be installable. It is not powered by the CDN at the moment. I welcome any reports of problems either by response to this thread, privately to me, or on the issue tracker at Github [1] [1] https://github.com/dstufft/warehouse/issues ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

2 3

URL Structure of Packages URLs
by Donald Stufft 18 Oct '13

18 Oct '13

I was wondering if anyone was aware of anything that relies on the current structure of package urls, namely: /packages/source|any|etc/D/Django-1.0.tar.gz? I would like to change this but before I work up a concrete plan for people to comment on and discuss I'm trying to figure out what, if anything, depends on that current structure. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

7 10

distil 0.1.2 released
by Vinay Sajip 18 Oct '13

18 Oct '13

I've released version 0.1.2 of distil, downloadable from [1]. It's based on distlib 0.1.3, which brings support for PEP 426. The other changes are as follows: * Fixed a bug in pre-release handling which occurred when there were *only* pre-releases available. * Added support to convert "bdist_wininst" installers to wheels. This is done by using "distil package", specifying only the wheel format and giving the path to the installer in place of the source directory. * Added --wheel-version option to package command to allow specifying a wheel version when building wheels. * Fixed bugs in uninstallation code which occurred only for some installations. * Fixed a bug in package data installation where data in packages not explicitly named in package-data was missed. * Updated "distil link" to show existing links when invoked with no arguments. * When building wheels, native executable launchers are not included, and scripts are not generated from exports. * Added support for PEP 426 installation hooks. * Added --target argument to "distil install" to allow partial installation to arbitrary directories. * Added --prereleases argument to "distil install", "distil test", and "distil download" to support inclusion of pre-releases when locating distributions and performing dependency resolution. * Numerous documentation updates. Your feedback will be gratefully received! Regards, Vinay Sajip [1] https://bitbucket.org/vinay.sajip/docs-distil/downloads/distil.py

1 0

Deprecate and Block requires/provides
by Donald Stufft 17 Oct '13

17 Oct '13

As many are aware distutils has the "requires" field and such. These fields are designed to list something you *import* not something you install from PyPI. I believe these fields to be generally useless, supported by the fact distutils2 deprecated them, and outright user hostile. Users do not tend to realize that these aren't PyPI distributions and attempt to use them for that case. This generally "works" in that it will show up on PyPI but it will fail as soon as a distribution contains a character like -. So what I would like to do is "remove" these fields. This would consist of modifying PyPI to return an error code if they are included and hiding the existing data in the UX. It might at a future time also consist of removing the data from the DB all together. What do people think? ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

9 34

PEP 453 - virtualenv change to Scripts/bin directory
by Paul Moore 15 Oct '13

15 Oct '13

As part of PEP 453, there is a proposal to change the layout of python environments on Windows by renaming the "Scripts" directory to "bin" (to match other platforms). The PEP is targeted at Python 3.4 (core and venv module) but for consistency virtualenv should also change to match (only for virtualenvs based on Python 3.4+, obviously). This change could potentially affect tools that build on virtualenv (tox, virtualenv-wrapper, for example). Coping with the change should be relatively easy - where code currently uses "Scripts" on Windows, they can simply check to see which of "Scripts" and "bin" exists and use that. Could anyone who has code like this please check if this change will cause them problems and let us know? Thanks, Paul

3 9

zc.buildout bootstrap.py v1 died / python-distribute.org down
by Adam GROSZER 15 Oct '13

15 Oct '13

Hi, python-distribute.org seems to be down, that breaks zc.buildout v1 bootstrap.py when used with "-d" to use distribute. -- Best regards, Adam GROSZER -- Quote of the day: "Some days you're the dog, and some days you're the hydrant."

6 11

develop install: how to update entry point file
by Thomas Güttler 14 Oct '13

14 Oct '13

Hi, what needs to be done, to get an update of the entry_point file, if you have installed a package as "develop". Example: pip install -e ...#egg=mylib git update # new code contains new entry point ... entrypoint not available. Thomas

2 1

dependency_links format changed?
by Thatcher Peskens 14 Oct '13

14 Oct '13

Hi all, I've been looking for information on this topic, but cannot really find anything about it.. It looks like setuptools has changed something that breaks a bunch of my installs (last deployed months ago) that were working before. I have some dependencies on a python package A* which is not available in PyPi, which itself has dependencies not available on PyPi. A has a setup.py containing: install_requires=[ 'django-inline-edit', ] and dependency_links = [ 'http://github.com/gabrielgrant/django-inline-edit/tarball/master#egg=django…', ] Now... This doesn't work anymore, where it used to work before. I have found that if I specify the install_requires with an explicit version e.g. django-inline-edit==dev AND the dependency_link with #egg=django-inline-edit-dev it does work. My previous experience shows that it was working without the explicit version before, and what I find on the internet also seem to suggest it should work. Has this been changed on purpose, or should it be reported as a bug? Thanks in advance, Thatcher *A -> https://github.com/gabrielgrant/django-easy-pages

2 1