Mailman 3 June 2013 - Distutils-SIG

Permission Denied errors on Windows 7 with buildout 1.7.1
by Chris Withers 10 Jun '13

10 Jun '13

Hi All, I'm seeing this exception when running a particular buildout on Windows: C:\Jenkins\workspace\checker-buildout\aeb5917b>bin\buildout Develop: 'C:\\Jenkins\\workspace\\checker-buildout\\aeb5917b\\.' Installing py. Generated script 'C:\\Jenkins\\workspace\\checker-buildout\\aeb5917b\\bin\\checker'. Generated script 'C:\\Jenkins\\workspace\\checker-buildout\\aeb5917b\\bin\\tox'. Generated script 'C:\\Jenkins\\workspace\\checker-buildout\\aeb5917b\\bin\\tox-quickstart'. While: Installing py. An internal error occurred due to a bug in either zc.buildout or in a recipe being used: Traceback (most recent call last): File "c:\users\jenkins\.buildout\eggs\zc.buildout-1.7.1-py2.7.egg\zc\buildout\buildout.py", line 1866, in main getattr(buildout, command)(args) File "c:\users\jenkins\.buildout\eggs\zc.buildout-1.7.1-py2.7.egg\zc\buildout\buildout.py", line 625, in install installed_files = self[part]._call(recipe.install) File "c:\users\jenkins\.buildout\eggs\zc.buildout-1.7.1-py2.7.egg\zc\buildout\buildout.py", line 1345, in _call return f() File "c:\users\jenkins\.buildout\eggs\zc.recipe.egg-1.3.2-py2.7.egg\zc\recipe\egg\egg.py", line 173, in install return self._install(reqs, ws, scripts) File "c:\users\jenkins\.buildout\eggs\zc.recipe.egg-1.3.2-py2.7.egg\zc\recipe\egg\egg.py", line 195, in _install relative_paths=self._relative_paths File "c:\users\jenkins\.buildout\eggs\zc.buildout-1.7.1-py2.7.egg\zc\buildout\easy_install.py", line 1223, in scripts initialization, executable, arguments) File "c:\users\jenkins\.buildout\eggs\zc.buildout-1.7.1-py2.7.egg\zc\buildout\easy_install.py", line 1350, in _generate_scripts module_name, attrs, arguments, block_site=block_site)) File "c:\users\jenkins\.buildout\eggs\zc.buildout-1.7.1-py2.7.egg\zc\buildout\easy_install.py", line 1498, in _script return _write_script(dest, contents, 'script') File "c:\users\jenkins\.buildout\eggs\zc.buildout-1.7.1-py2.7.egg\zc\buildout\easy_install.py", line 1463, in _write_script open(exe, 'wb').write(new_data) IOError: [Errno 13] Permission denied: 'C:\\Jenkins\\workspace\\checker-buildout\\aeb5917b\\bin\\buildout.exe' This happens every time, on Python 2.5, 2.6 and 2.7. I've tried blowing the workspace away, makes no difference: http://jenkins.simplistix.co.uk/job/checker-buildout/114/PYTHON=2.7,label=w… http://jenkins.simplistix.co.uk/job/checker-buildout/114/PYTHON=2.6,label=w… http://jenkins.simplistix.co.uk/job/checker-buildout/114/PYTHON=2.5,label=w… Any idea what's going on here and how I can fix it? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

2 3

buildout 2 not compatible with python2.5?
by Chris Withers 10 Jun '13

10 Jun '13

Hi All, Am I right in thinking that buildout 2 isn't compatible with Python 2.5? http://jenkins.simplistix.co.uk/job/checker-buildout/119/ eg: Building a Distribute egg in /tmp/tmpqeG0PG /tmp/tmpqeG0PG/distribute-0.6.45-py2.5.egg File "build/bdist.linux-i686/egg/zc/buildout/easy_install.py", line 133 current_umask = os.umask(0o022) ^ SyntaxError: invalid syntax ...which is a shame, as it seemed to be doing a bit better at fixing the Windows problems I was having... cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

1 0

wxPython and wx
by Yuval Greenfield 07 Jun '13

07 Jun '13

I wanted to install wx and tried to "sudo pip install wx". Sadly this https://pypi.python.org/pypi/wx module described as "my first python module, like php file_get_contents" shadowed the wxpython I eventually installed with "sudo apt-get install python-wxgtk2.8". Can we remove that package from pypi? Preferably with the author's consent. Yuval

3 4

Draft PEP for JSON based metadata published
by Nick Coghlan 06 Jun '13

06 Jun '13

After preliminary reviews by Donald and Daniel, I have now pushed the first complete draft of the JSON-based metadata 2.0 proposal to python.org PEP 426 (metadata 2.0): http://www.python.org/dev/peps/pep-0426/ PEP 440 (versioning): http://www.python.org/dev/peps/pep-0440/ With the rationale and commentary, they're over 3000 lines between them, so I'm not attaching them here. The rationale for many of the changes is at the end of each PEP, along with some comments on features that I have either rejected or deliberately chosen to defer to the next revision of the metadata (at the earliest). Those with BitBucket accounts may also comment inline on the drafts here: PEP 426: https://bitbucket.org/ncoghlan/misc/src/05d3586464b10d6a04a35409468269d7c89… PEP 440: https://bitbucket.org/ncoghlan/misc/src/05d3586464b10d6a04a35409468269d7c89… Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

6 31

option #1 plus download_url scraping
by Barry Warsaw 05 Jun '13

05 Jun '13

Like many of you, I got Donald's message about the changes to URLs for Cheeseshop packages. My question is about the three options; I think I want a middle ground, but I'm interested to see why you will discourage me from that <wink>. IIUC, option #1 is fine for packages hosted on PyPI. But what if our packages are *also* hosted elsewhere, say for redundancy purposes, and that external location needs to be scraped? Specifically, say I have a download_url in my setup.py. I *want* that url to be essentially a wildcard or index page because I don't want to have to change setup.py every time I make a release (unless of course `setup.py sdist` did it for me). I also can't add this url to the "Additional File URLs" page for my package because again I'd have to change it every time I do a release. So the middle ground I think I want is: option #1 plus scraping from download_url, but only download_url. Am I a horrible person for wanting this? Is there a better way. Cheers, -Barry

8 17

problems with sdist upload since CDN update
by kiorky 05 Jun '13

05 Jun '13

I got some random releasing (1 on 5 or 6 tries) problems since last pypi update. For example, with collective.ckeditor (3.6.10 tag on github), the sdist upload will randomly not upload the file without reporting any error on console: https://github.com/collective/collective.ckeditor/tree/3.6.10 -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF Pensez à l’environnement. N’imprimez ce courriel que si vous en avez vraiment besoin.

3 9

Re: [Distutils] Binary Wheels and "universal" builds on OS-X
by Chris Barker - NOAA Federal 05 Jun '13

05 Jun '13

On Mon, Jun 3, 2013 at 3:47 PM, Daniel Holth <dholth(a)gmail.com> wrote: > That would make sense. Can you come up with code to detect that a > newly compiled extension is universal, and that a Python is? It looks like distutils.util.get_platform() now does the right thing for knowing what the currently running pyton is (see Ronald's message) For determining the status of a newly compiled extension, I usually simple run the "file" command line utility on it: $ file python python: Mach-O universal binary with 2 architectures python (for architecture ppc): Mach-O executable ppc python (for architecture i386): Mach-O executable i386 (works for *.so, too...) that could easily be parsed out, but we would still want to know the deployment target, which maybe you could get by parsing otool output: $ otool -L python python (architecture ppc): /Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 47.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10) python (architecture i386): /Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10) (compatibility version of libSystem???) But I imagine there is a cleaner way -- Ronald?? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

3 4

Setuptools 0.7 final available for download
by Jason R. Coombs 04 Jun '13

04 Jun '13

I'm pleased to announce the official release of Setuptools 0.7, now available for download from the project page <https://bitbucket.org/pypa/setuptools> . Nothing has changed from the 0.7b4 pre-release. This is the version that will be uploaded to PyPI after we work out the technique to deploy to PyPI without interfering with the setuptools 0.6 releases. For convenience, I've also added experimental .msi installers for Windows for Python 3.3 and Python 2.7. Work may continue on these in the future, but as the documentation states, the recommended installation procedure is to use ez_setup.py. To install this latest release, follow the canonical install instructions (using ez_setup.py), but direct the script to use bitbucket instead of PyPI: python ./ez_setup.py --download-base=https://bitbucket.org/pypa/setuptools/downloads/ I'll send another announcement when the official release has been uploaded to PyPI and the ez_setup.py script can be used directly.

11 17

Binary Wheels and "universal" builds on OS-X
by Chris Barker - NOAA Federal 04 Jun '13

04 Jun '13

HI Folks, A few of us over on the pythonmac list have been hashing out how best to support binary packages on OS-X. The binary wheel option seems very promising. However, there is one Mac-specific issue that does not seem to be addressed: On OS-X, binaries can be "universal" -- what this means is that they have more than one binary architecture embedded in a single file; the system selects the right one at run time. Both executables and dynamic libraries can be universal. In theory, an universal binary can currently contain up to 4 architectures: 32+64 bit PPC and 32+64bit x86 In practice, 64 bit PPC was never broadly used, and 32bit PPC is fading fast. Nevertheless, both 32 and 64 Intel systems are pretty common, and who knows what there may be in the future (you never know with Apple...) The binary builds of Python served up on the python.org web site have supported universal builds for years -- currently there are two options: 32bit PPC+x86 or 32+64bit x86. It's not a single build, as it turns out it's hard to support both up to date x86_64 and PPC with the same compiler. In these builds, the configuration is set up so that distutils will build universal extensions that match the architectures included in the builds. This makes it pretty easy to build binary packages, and/or full app distributions (py2app) that are universal as well. setuptools' easy_install supports binary eggs, but always choked on universal builds -- it didn't know how to identify what matched the system. It would be really nice if future tools could identify and install the correct binary wheels for universal builds. I've taken a look at PEP 427, and see this: platform tag E.g. 'linux_x86_64', 'any'. That looks to me like there is a built-in assumption that a wheel is either specific to a single architecture, or any -- so no way to specify that it may have multiple architectures. So I propose that platform tag allow a list of some sort: ['macosx-10_6_i386', 'macosx_10_6-x86_64'] or, I suppose to keep it simple, a single string: 'macosx_10_6_i386+macosx_10_6_x86_64' or 'macosx_10_6_i386+x86_64' If so, then a binary wheel could be built (and discovered) that supported multiple architectures. Then how would an installer ( pip? ) identify the right one? This is a bit tricky. PEP 425 states: "The platform tag is simply distutils.util.get_platform() with all hyphens - and periods . replaced with underscore" On my system right now, I have 32bitPPC + 32bit i386 universal python, running on an intel system: In [2]: distutils.util.get_platform() Out[2]: 'macosx-10.3-i386' So we may want to patch get_platform() to support universal builds - or add anther function or something -- you may sometimes what to know what you are running right now, and other times want to know how the current python is built. (note that while distutils can build universal binaries, it's not very smart about it -- all is does is grab the compiler and linker flags from the Makefile, which include multiple "-arch" flags. Even if there is an easy way to query the system, that leaves the question of what to do. If a user wants to intall a package into a universal python, will the installer only accept a binary wheel with all the supported architectures? or one with only the currently running one? Anyway, it would be nice to be able to get this stuff to "just work" with universal binaries on the Mac. Thoughts, ideas? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

4 9

Preemptive Apology for Volume of Mail
by Donald Stufft 04 Jun '13

04 Jun '13

Just want to apologize to anyone who recently received a lot of mail from me. I realized shortly after I queued all the emails that they should have been grouped by user and not by package. So, I'm sorry. I really am and I feel bad about the amount of mail some of you have received from me. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

10 22