Mailman 3 May 2008 - Distutils-SIG

[issue4] subversion 1.5 working copy causes problem in entries_finder: NameError: global name 'log' is not defined
by Jeff Kowalczyk May 8, 2008

May 8, 2008

New submission from Jeff Kowalczyk <jtk(a)yahoo.com>: When I upgraded to subversion-1.5, working copies using various combinations of virtualenv, zc.buildout, setuptools all stopped working with errors similar to the following: python: /opt/python24/python/bin/python virtualenv (svn trunk) activated working copy: svn://svn.zope.org/repos/main/z3c.formdemo/trunk virtualenv python bootstrap.py, .bin/buildout try to upgrade setuptools to dev copy per PJE mailing list post: (formdemo) /software/z3c/formdemo $ easy_install setuptools==dev06 Searching for setuptools==dev06 Reading http://pypi.python.org/simple/setuptools/ Best match: setuptools dev06 Downloading http://svn.python.org/projects/sandbox/branches/setuptools-0.6/#egg=setupto… Doing subversion checkout from http://svn.python.org/projects/sandbox/branches/setuptools-0.6/ to /tmp/easy_install-MKC07e/setuptools-0.6 Processing setuptools-0.6 Running setup.py -q bdist_egg --dist-dir /tmp/easy_install-MKC07e/setuptools-0.6/egg-dist-tmp-izAnB2 unrecognized .svn/entries format; skipping . Traceback (most recent call last): File "/software/z3c/formdemo/bin/easy_install", line 7, in ? sys.exit( File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 1671, in main with_ei_usage(lambda: File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 1659, in with_ei_usage return f() File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 1675, in <lambda> distclass=DistributionWithoutHelpCommands, **kw File "/opt/python24/./python/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/opt/python24/./python/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/opt/python24/./python/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 211, in run self.easy_install(spec, not self.no_deps) File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 446, in easy_install return self.install_item(spec, dist.location, tmpdir, deps) File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 476, in install_item dists = self.install_eggs(spec, download, tmpdir) File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 655, in install_eggs return self.build_and_install(setup_script, setup_base) File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 930, in build_and_install self.run_setup(setup_script, setup_base, args) File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 919, in run_setup run_setup(setup_script, args) File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/sandbox.py", line 26, in run_setup DirectorySandbox(setup_dir).run( File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/sandbox.py", line 63, in run return func() File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/sandbox.py", line 29, in <lambda> {'__file__':setup_script, '__name__':'__main__'} File "setup.py", line 94, in ? 'zope.traversing', File "/opt/python24/./python/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/opt/python24/./python/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/opt/python24/./python/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/bdist_egg.py", line 167, in run self.run_command("egg_info") File "/opt/python24/./python/lib/python2.4/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/opt/python24/./python/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/egg_info.py", line 171, in run self.find_sources() File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/egg_info.py", line 252, in find_sources mm.run() File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/egg_info.py", line 306, in run self.add_defaults() File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/egg_info.py", line 333, in add_defaults rcfiles = list(walk_revctrl()) File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/sdist.py", line 45, in walk_revctrl for item in ep.load()(dirname): File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/sdist.py", line 52, in _default_revctrl for path in finder(dirname,path): File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/sdist.py", line 98, in entries_finder log.warn("unrecognized .svn/entries format in %s", dirname) NameError: global name 'log' is not defined Apologies for the lack of additional detail here, I've reverted to subversion-1.4 and recreated all working copies. This was experienced on all working copies of various projects after upgrading to subversion-1.5, and was fully fixed when reverting to subversion-1.4. ---------- messages: 5 nosy: jfkw priority: bug status: unread title: subversion 1.5 working copy causes problem in entries_finder: NameError: global name 'log' is not defined _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue4> _______________________________________________

1 0

[issue1] amd64 eggs are called x86_64
by Jeroen Ruigrok van der Werven May 8, 2008

May 8, 2008

New submission from Jeroen Ruigrok van der Werven <asmodai(a)in-nomine.org>: Currently eggs created for amd64 platforms are called x86_64 in the egg filename. AMD renamed x86_64 to amd64 and asked people to follow suit. Also Python uses the amd64 nomenclature: http://mail.python.org/pipermail/python-bugs-list/2006-December/036400.html and http://mail.python.org/pipermail/python-dev/2008-May/079056.html As such, to limit end-user confusion eggs should be named amd64 as well instead of x86_64. ---------- messages: 1 nosy: asmodai priority: bug status: unread title: amd64 eggs are called x86_64 _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue1> _______________________________________________

2 1

[issue3] eggs on Windows do not differentiate between 32- or 64-bits
by Jeroen Ruigrok van der Werven May 8, 2008

May 8, 2008

New submission from Jeroen Ruigrok van der Werven <asmodai(a)in-nomine.org>: As I explained in http://mail.python.org/pipermail/distutils-sig/2008-April/009398.html eggs created on either a 32- or 64-bits Windows call the resulting file only a win32 egg. For pure Python modules this is not an issue. However, when using speedups or other code that needs to be natively compiled (C source code for example) you generate specific binaries for either 32- or 64-bits. We already differentiate between these versions on Unix and as such we should do the same on Windows. Something like module-1.0-py2.5-win32-i386.egg or module-1.0-py2.5-win32-amd64.egg. ---------- messages: 3 nosy: asmodai priority: urgent status: unread title: eggs on Windows do not differentiate between 32- or 64-bits _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue3> _______________________________________________

1 0

[issue2] easy_install broken on 64 bits Windows
by Jeroen Ruigrok van der Werven May 8, 2008

May 8, 2008

New submission from Jeroen Ruigrok van der Werven <asmodai(a)in-nomine.org>: As I reported in http://mail.python.org/pipermail/distutils-sig/2008-April/009398.html easy_install on a 64 bits Python on a 64 bits Windows is broken in that it gives the following error: Cannot find Python executable C:\Python25\python.exe I believe that due to cli.exe and gui.exe (built from launcher.c) being 32-bits executables they are trying to use 32-bit specific calls which fail on a 64 bits Windows. As Mark Hammond said in http://mail.python.org/pipermail/distutils-sig/2008-May/009462.html: "I suspect that the issue is that a 32bit cli.exe or gui.exe is attempting to LoadLibrary a 64bit executable and failing (specifically, loadable_exe() in launcher.c)" ---------- messages: 2 nosy: asmodai priority: urgent status: unread title: easy_install broken on 64 bits Windows _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue2> _______________________________________________

1 0

Puppet blog: Ruby has a distribution problem
by Ben Finney May 7, 2008

May 7, 2008

Howdy all, An interesting blog post from Luke Kanies that sparks an even more interesting discussion in the comments. There seems to be a split between those developers who write software that is expected to run in one place and those who write software that is expected to run in many places. If you, as a developer, know that your software will really only be installed at a single customer [...], then your life is drastically easier -- you don't usually have to worry about cross-platform issues, and you don't have to worry about different users having different needs, because you only have one user. Obviously there's no inherent problem with having the simpler life of a developer with only one user, but it seems to me that the Ruby community is, as a group, largely adopting that perspective as the default. This is worrying to me, because I'm building an application that I expect to be installed in thousands of locations (in fact, it's probably already installed in thousands of locations). I'd like to take as much advantage of existing Ruby code as possible, but it's not exactly easy. <URL:http://www.madstop.com/ruby/ruby_has_a_distribution_problem.html> It's about Ruby's current state of package distribution, but has many points that will be familiar to critics of distutils, setuptools, and cheese shop, or to readers of this forum in the last couple of weeks. -- \ “I cannot conceive that anybody will require multiplications | `\ at the rate of 40,000 or even 4,000 per hour ...” —F. H. | _o__) Wales, 1936 | Ben Finney

1 0

Re: [Distutils] shebang line modified by setuptools
by Phillip J. Eby May 7, 2008

May 7, 2008

At 09:07 PM 4/11/2008 -0700, Cliff Wells wrote: >Hi Phillip, > >I recently upgraded a hosting server from Python 2.4 to Python 2.5. >Many of the sites on this server couldn't easily be upgraded to 2.5 (at >least not in a timely fashion), so my interim solution was to simply >symlink ~/bin/python -> /usr/bin/python2.4 (~/bin is first in the user's >PATH). This worked swimmingly except for applications which relied on >Paste (I should note I use the method outlined here: >http://peak.telecommunity.com/DevCenter/EasyInstall#administrator-installat…). > >The reason the Paste apps had an issue is because apparently setuptools >modifies the shebang line of paster to be "#!/usr/bin/python". This >hardcoded path overrides any PATH settings. I understand that this is >done at the time Paste is installed to tie it to the installed version >of Python. This makes sense, except that it doesn't do what it's >intended to when Python is upgraded (/usr/bin/python is no longer the >version it was installed with). > >It seems the correct solution to this is to use "#!/usr/bin/env >python" (or rather, evaluate `which env` to account for some systems >which have /bin/env rather that /usr/bin/env) which allows the sys admin >to override the Python binary much more easily. No, it isn't the correct solution. The correct solution is to re-run easy_install on the target -- it will leave the existing installed code in place, but regenerate the scripts with headers pointing to the currently-in-use Python. Even that is often not as good an idea as reinstalling for a new version of Python; some packages (notably, setuptools itself, but I have others) include different code and data depending on the Python version they are built for. For example, a package built for Python 2.5 might not include dependency specs for ctypes, sqlite, or wsgiref, but the same package might need to specify those dependencies on earlier versions of Python. By the way, please don't send me unsolicited private emails about setuptools unless you're a client or potential client. There's a reason that every single official web page about setuptools directs you to email the distutils-sig. I don't do private email for ANY of my open source projects, unless you're a client or looking to be one. Mailing lists have searchable archives, meaning that my time answering a question is being offset by its potential utility to a much larger audience. Thanks.

14 66

#1858, looking for a reviewer
by Tarek Ziadé May 7, 2008

May 7, 2008

Hi, The register and upload commands have a --repository option that allows to use them with any server. You can register and upload a package to any server that has the right set of web services. They also work with a configuration file called .pypirc Unfortunately there is no inline option to define the username/password. This has to be defined in .pypirc. But this file does not allow having different sets of username/password, so in reality it is not possible to play with multiple servers. #1858 provides a patch for this [0] I have submitted it in January, after some discussion in catalog-sig and distutils-sig, that led to a proposal [1] I am looking for a final reviewer, to decide if the new .pypirc is considered suitable, and maybe have it integrated in the 2.6. This new format will be used in the Plone community to interact with plone.org and the cheeseshop [2], (with a third party package at this time, that implements the patch) Regards Tarek [0] http://bugs.python.org/issue1858 [1] http://wiki.python.org/moin/EnhancedPyPI [2] http://tarekziade.wordpress.com/2008/05/06/plone-paris-sprint-wrapup-3-newp… -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

1 0

Re: [Distutils] Script Files, Prefix, and Uninstallation
by Phillip J. Eby May 4, 2008

May 4, 2008

At 08:56 PM 5/4/2008 +0300, natan yellin wrote: >On Sun, May 4, 2008 at 8:51 PM, Phillip J. Eby ><<mailto:pje@telecommunity.com>pje(a)telecommunity.com> wrote: >At 11:04 AM 5/4/2008 +0300, natan yellin wrote: >Hello, >I'm relatively new to python, and I have a few questions related to distutils. > >1) If I attempt to install script files without a .py extension, >distutils installs them twice- once with a .py extension and once >without. Is there a way to work around that? > > >I've never seen the behavior you're describing. You should probably >post your setup.py for us to see what you're doing. > >I've attached it. By "post", I mean posting it to the distutils-sig. I don't do private tech support - especially not for the distutils. >2) Is there a way to change the default install prefix from /usr to >/usr/local? > > >You can change that systemwide by creating the appropriate config >file. Please see the configuration file section of the "Installing >Python Modules" manual. > >Is there any way to change it within the script? It makes more sense >to install my particular app into /usr/local than /usr. It can be changed in lots of places, including the script or setup.cfg. Please see the manual.

2 1

Script Files, Prefix, and Uninstallation
by natan yellin May 4, 2008

May 4, 2008

Hello, I'm relatively new to python, and I have a few questions related to distutils. 1) If I attempt to install script files without a .py extension, distutils installs them twice- once with a .py extension and once without. Is there a way to work around that? 2) Is there a way to change the default install prefix from /usr to /usr/local? 3) Is it possible to find the install prefix that was actually used. (e.g. if the user set --prefix to something other than /usr/local). I'd like to store the prefix in a file so that I can later uninstall from the correct prefix. (Or is there an easier way to uninstall that I'm missing?) Thanks in advance, Natan

2 1

Re: [Distutils] Fwd: setuptools: Spelling < 3.1.0beta3 ?
by Phillip J. Eby May 4, 2008

May 4, 2008

At 12:48 PM 5/2/2008 -0400, Alexander Michael wrote: >On Fri, May 2, 2008 at 12:30 PM, Pete <pfein(a)pobox.com> wrote: > > Hi- > > > > What's the proper way to spell "any version in the 3.0.x series" if a > > project has a 3.1.0beta3 release? > > > > Specifically, CherryPy has both 3.0.2 and 3.1.0beta3 > releases. I'd like to > > depend on any 3.0.x > > > > I've tried both 'CherryPy < 3.1' and 'CherryPy < 3.1.0' in my > > install_requires, and both cause setuptools to pull 3.1.0beta3. > > > > I realize I can use 'CherryPy == 3.0.2' but that defeats the "any 3.0.x" > > idea... > > I find this surprising as well, but the answer is: > > >>> import pkg_resources > >>> v = pkg_resources.parse_version > >>> v('3.1.0beta3') < v('3.1.0') > True > >>> v('3.1.0beta3') < v('3.1.0a0') > False Leading zeros before an alpha component are dropped from comparisons, so you could equally say '<3.1a'. However, what you really want is '<3.1dev', as 'dev' is the lowest-possible precedence pre-release tag. So, to say "any 3.0.x", you would need to say '>=3.0.1dev, <3.1dev' (assuming you wanted to include pre-release 3.0.x versions). > I wish it was "easier" to say "3.1.x" (as in any final sub-point > release in the 3 series) or "1.x" (as in any final version 1 release) > which didn't allow development, alpha, beta, candidate, etc. releases. > Is there? Not at the moment, no.

1 0