Mailman 3 January 2014 - Distutils-SIG

File names with spaces
by Maciej (Matchek) Bliziński 08 Jan '14

08 Jan '14

Hello setuptools developers, I'm attempting to package the newest setuptools version (1.1.6) on Solaris 9 and 10. One of the limitations of the Solaris package manager (the old one, pkgadd/pkgrm), is that it is unable to handle file names with spaces. Would you mind renaming "script template.py" to something like "script_template.py"? Maciej

2 3

Virtualenv 1.11.1rc1 Available for Testing
by Donald Stufft 07 Jan '14

07 Jan '14

virtualenv 1.11.1rc1 has been released, which solves a serious issue with the ``—system-site-packages`` flag. In order to test this copy of virtualenv: $ curl -L -O https://github.com/pypa/virtualenv/archive/1.11.1rc1.tar.gz $ echo "e517f28a31792f00699b369932a9b66a 1.11.1rc1.tar.gz" | md5sum -c 1.11.1rc1.tar.gz: OK $ tar zxf 1.11.1rc1.tar.gz $ python virtualenv-1.11.1rc1/virtualenv.py myVE $ myVE/bin/pip install SomePackage ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

1 0

errors trying to get setuptools 2.0.2
by Malik Rumi 06 Jan '14

06 Jan '14

Here is what I did and the response: c:\> c:\>ez_setup.py Downloading https://pypi.python.org/packages/source/s/setuptools/setuptools-2.0. 2.tar.gz Exception calling "DownloadFile" with "2" argument(s): "An exception occurred during a WebClient request." At line:1 char:1 + (new-object System.Net.WebClient).DownloadFile('https://pypi.python.org/packages ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~ ~~~ + CategoryInfo : NotSpecified: (:) [], MethodInvocationException + FullyQualifiedErrorId : WebException Traceback (most recent call last): File "C:\Python27\Scripts\ez_setup.py", line 361, in <module> sys.exit(main()) File "C:\Python27\Scripts\ez_setup.py", line 357, in main downloader_factory=options.downloader_factory) File "C:\Python27\Scripts\ez_setup.py", line 282, in download_setuptools downloader(url, saveto) File "C:\Python27\Scripts\ez_setup.py", line 169, in download_file_powershell _clean_check(cmd, target) File "C:\Python27\Scripts\ez_setup.py", line 152, in _clean_check subprocess.check_call(cmd) File "C:\Python27\lib\subprocess.py", line 511, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['powershell', '-Command', "(new-object System.Net.WebClient).DownloadFile ('https://pypi.python.org/packages/source/s/se tuptools/setuptools-2.0.2.tar.gz', 'c:\\\\setuptools-2.0.2.tar.gz')"]' returned non-zero exit status 1 c:\> The parts in red were in red in my terminal window. I am on windows 8.1 and I am brand new. Less than a week ago, I installed Distribute because someone on Django Google Groups recommended it to me, along with virtualenv and pip. Then today - well, last night since it was a few hours ago - I found out Distribute is deprecated. So I am trying to follow the uninstall instructions but this is what I got. Just for kicks I ran it again just now - same result. Please help. I took time off from work Thursday and Friday to get all this set up have been at this all weekend only to be stumped again. And no, I do not have Django up and running yet. Thank you.

2 1

Packaging today...
by Steve Spicklemire 06 Jan '14

06 Jan '14

Hi Distutils folks, I'm kind of a lurker here, due primarily to the fact that I'm too swamped with various other things to materially contribute to the effort, but I've been lurking for some time hoping to learn enough to avoid troubling anyone with pesky questions. In that respect I've apparently failed, because here comes the question! Background: I'm helping out with a python package: vpython <http://vpython.org> and I'm also teaching an intro scientific computing class this spring. I'm mostly a Mac/Linux user, but my students are often windows users. I would love to permit my students to use enthought/canopy and/or continuum analytics (C.A.) along with vpython. At the moment we're creating binary releases of vpython for windows and mac and posting them on sourceforge <https://sourceforge.net/projects/vpythonwx/>. Bruce has been building the windows binary using VC (no setup.py) in a way that's compatible with python.org python for windows. I've been building the mac version using a setup.py script I cobbled together that works on MacOSX and Linux. I've noticed that the anaconda system that C.A. installs uses MinGW on windows to build extensions. I'd love to figure out how to build vpython under this system so that my windows users could use them together transparently. (BTW is this the same 'anaconda' that has been discussed on this list recently, or is that something different?) I'm pretty sure I could work out how to build vpython with continuum analytics on the mac (which means building boost + wxPython using the C.A. python). Questions: Is there any way, *today*, to incorporate dependencies on external libraries (e.g., boost) in setup.py? (I've noticed the recent conversion about binary dependencies, but from the discussion it seemed to be mostly about the future...) Where should I go to get the 'latest' advise/documentation on distribution for a package that I want to distribute today (rather than pestering you folks)? thanks! -steve Steve Spicklemire University of Indianapolis Dept. of Physics and Earth Space Sciences spicklemire(a)uindy.edu (317) 788-3313

1 0

Buildout index URL override
by Christian Ullrich 05 Jan '14

05 Jan '14

Hello all, does buildout ever take its default index URL from the distutils configuration, i.e. [py]distutils.cfg? Given that it uses easy_install for most installation tasks, that could make sense, and I'm not sure whether it is actually supposed to happen already, but does not happen on my systems for some reason. Thanks for any info you can give me. -- Christian

2 1

Can pypi python 3 packages be sorted please?
by Mark Lawrence 04 Jan '14

04 Jan '14

So can they be sorted in the same way as the normal index? To my eye the unsorted list looks horrible. OTOH it's too much hassle or this is covered by the Warehouse project I won't lose any sleep over it. Also for pypi issues https://mail.python.org/mailman/listinfo/pydotorg-www points you to https://mail.python.org/mailman/listinfo/catalog-sig where it states it's retired and points you here. How do we get this changed? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

2 3

PyPI classifier for standard library modules/backports?
by Nick Coghlan 03 Jan '14

03 Jan '14

I started putting together a list of standard library modules that are also available on PyPI for the https://wiki.python.org/moin/Python2orPython3 wiki page. Dariusz Suchojad suggested it might be easier if there was a suitable classifier to mark such modules rather than trying to keep a list on the wiki up to date by hand. Perhaps something like "Progamming Language :: Python :: Standard Library"? Thoughts? Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

3 6

Major update to the metadata 2.0 draft PEPs
by Nick Coghlan 01 Jan '14

01 Jan '14

I've just published the first draft of the metadata 2.0 spec that moves all of the fields that aren't part of the core metadata or potentially needed for dependency resolution out to a separate "standard metadata extensions" PEP. I think this makes PEP 426 itself substantially less overwhelming, and also provides convenient names to refer to the various other subsets of the metadata. The new PEP defining the standard extensions is PEP 459. Metadata 2.0: http://www.python.org/dev/peps/pep-0426/ Versioning: http://www.python.org/dev/peps/pep-0440/ Standard Extensions: http://www.python.org/dev/peps/pep-0459/ You can see the full deltas for PEP 426 and PEP 440 here: http://hg.python.org/peps/rev/d18629859154 Or slightly more incremental deltas in the BitBucket repo: https://bitbucket.org/pypa/pypi-metadata-formats/overview With this update, I believe PEP 440 is extremely close to acceptance, as I have tried to resolve a number of problems Donald noted while working on Warehouse, as well as the perennial problem of how to deal with versioning of packages where Linux distro vendors (or other system integrators) have applied additional patches. The PEP 440 changes: - added the "integrator suffix" (essentially an extra release segment, separated from the upstream version number by "-"). It is effectively ignored by most of the matching operators, but sorts as a higher version than the version with no suffix. - allowed date based versions for most purposes, but still reject them for the "~=" compatible version operator. The implied comparison operator for date based versions is ">=". - clarified that zeroes and leading zeroes are permitted and that they should be sorted like numbers - based on discussions with some of the Red Hat security folks, I tweaked the direct URL references to *always* require a hash in the URL, even when using HTTPS or SSH. PEP 426 and PEP 459 are further away from finalisation, but we're definitely getting closer to something I'm happy with. The PEP 426 changes: - many of the fields are gone, having moved to PEP 459 extensions - this also allowed the notion of "essential dependency metadata" (with it's own separate filename) to go away - the extension format changed to require a submapping - extensions are now versioned (with an implied 1.0 if not specified) - as with direct URLs in PEP 440, source URLs are now required to contain a hash PEP 459 overview: - standard extensions using the "python.*" namespace - the details, project, exports and commands extensions just lift several fields out of PEP 426 - the integrator extension is new, and matches the project extension structure. It allows redistributors like a Linux distro or a Python vendor to add their own info without overwriting the upstream project metadata - the new metadata_hooks extension replaces the install hooks design in earlier drafts of PEP 426. In this new scheme, Twisted, for example, would define an appropriate export group hook in order to be told about any new extensions that exported Twisted plugins and take appropriate action In this revised metadata model, distributions *will* trigger their own postinstall metadata hooks, but won't trigger their postuninstall hooks. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

3 5

migration path for entry_points?
by Marcus Smith 01 Jan '14

01 Jan '14

ok, so PEP459 has exports: http://www.python.org/dev/peps/pep-0459/#the-exports-extension and distlib seems to be implementing them. and "exports" seem to be entry points 2.0. so theoretically, when PEP426/PEP459 becomes live.... what does that mean for setuptools-based projects? (I understand that we might not have a clear idea now, but just trying to narrow down the possibilities) 1) the setuptools "entry_points" keyword (and pkg_resources api) gets re-implemented to understand PEP459 exports? or 2) "entry_points" keeps the old implementation, and possibly tools are written to handle the old and new metadata? or 3) "entry_points" are stranded, and consumers have to rewrite setup.py files to use some new keyword that understands PEP459 or 4) something altogether different... as for why I'm asking, pip itself is considering command extensions, so it's a direct practical matter for us. Marcus

4 6