Mailman 3 March 2010 - Distutils-SIG

easy_install is not robust against network errors
by Manlio Perillo 04 Mar '10

04 Mar '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have found that easy_install is not very robust against network problems. $easy_install --version distribute 0.6.10 Searching for SQLAlchemy==dev Reading http://pypi.python.org/simple/SQLAlchemy/ Download error: (113, 'No route to host') -- Some packages may not be found! Couldn't retrieve index page for 'SQLAlchemy' Scanning index of all packages (this may take a while) Reading http://pypi.python.org/simple/ Download error: (101, 'Network is unreachable') -- Some packages may not be found! No local packages or download links found for SQLAlchemy==dev Best match: None Traceback (most recent call last): File "organizzasposi/deps/bin/easy_install", line 8, in <module> load_entry_point('setuptools==0.6c11', 'console_scripts', 'easy_install')() File "/home/manlio/.../deps/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg/setuptools/command/easy_install.py", line 1712, in main File "/home/manlio/.../deps/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg/setuptools/command/easy_install.py", line 1700, in with_ei_usage File "/home/manlio/.../deps/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg/setuptools/command/easy_install.py", line 1716, in <lambda> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/home/manlio/.../deps/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg/setuptools/command/easy_install.py", line 211, in run File "/home/manlio/.../deps/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg/setuptools/command/easy_install.py", line 434, in easy_install File "/home/manlio/.../deps/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg/setuptools/package_index.py", line 475, in fetch_distribution AttributeError: 'NoneType' object has no attribute 'clone' Thanks Manlio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuQJP0ACgkQscQJ24LbaUREHgCgmZSiaiEzN7EyMWCOrcEtVJqm W/YAn0cGNpJXjTL3CflWHIzad5FikjLW =wZeY -----END PGP SIGNATURE-----

1 0

Installing header files with setuptools
by James Porter 03 Mar '10

03 Mar '10

Perhaps this is a bug or perhaps I'm just doing it wrong, but I can't figure out a good way to install C header files as part of a setuptools project. With distutils, there's a "headers" argument to setup() that installs the header files in their proper spot, but setuptools ignores this. It looks like setuptools is hijacking the install command and manually running install_lib, install_data, etc, but never install_headers. Does setuptools expect me to do this in a different way, or is this something that should be fixed? - Jim

3 6

Newby Question: install easy_install for python2.5 on RHEL
by Walter Coole 03 Mar '10

03 Mar '10

When I try to install with: sudo sh setuptools-0.6c11-py2.5.egg I get an error: error: invalid Python installation: unable to open /usr/lib64/python2.5/config/Makefile (No such file or directory) That I don't really understand. Yes, it's true that there is no /usr/lib64/python2.5/config directory, but I've gotten along nicely without one for quite a while. I haven't had much trouble with my Fedora box (which uses 2.5 by default) or the default 2.4 installation on my RHEL (which doesn't help, since my application needs 2.5), so I started thinking I knew what I was doing. I'm sure that there is some confusion due to the fact that I've installed python2.5 in a different-than-usual directory. I need to keep "python" referring to python2.4, since RHEL 5.2 depends on it. Presumably, if I can tell setuptools-0.6c11-py2.5.egg enough about where things are, it should be able to adapt. I've tried several variations, but haven't made much progress. If anyone could point out which option to use to override its choice of directory or which directory to point it to, that would be a big help. Or perhaps I've just been looking at this completely wrong-headedly, in which case I'd be most grateful for instructions on how to install some variation of setuptools to work with python2.5 on a RHEL 5 system. Thanks! Walter PS. In case it matters to anyone, all I really need to do is to install the beatbox module, for which I have the .egg file, but I don't know how to install a .egg file in a useful way without setuptools or some such. It seem a shame to break open the egg and install its guts manually, but if that seems like the available alternative, I'd welcome any pointers.

2 2

zc.buildout - macros extending macros
by Martin Aspeli 03 Mar '10

03 Mar '10

Hi, Possibly related to my earlier email about the ordering of extends lines, but also possibly a bug or missing feature: I have a buildout.cfg that extends instance.cfg and prod.cfg: [buildout] extends = instance.cfg prod.cfg In instance.cfg, I have: [instance] recipe = plone.recipe.zope2instance user = admin:admin ... In prod.cfg: [prod-instance] <= instance debug-mode = off cache-size = 10000 [instance1] <= prod-instance http-address = 8001 [instance2] <= prod-instance http-address = 8002 The idea is that shared instance settings (which are also used in a debug.cfg) are kept in [instance], but ones specific to the production server are kept in [prod-instance], and instance1...N are clones of the prod-instance that only vary the port. Unfortunately, the options from [instance] don't seem to make it into [instance1] or [instance2]. In other words, the macro doesn't seem to be evaluated "transitively". Am I doing something wrong, or is this just not supported? Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book

2 1

(no subject)
by Zubin Mithra 03 Mar '10

03 Mar '10

Hello, I`d like to work on distutils as part of GSoC 2010. Could you please help me, on as to when the ideas list for python distutils might be put up? Thank you, Zubin Mithra

2 1

trouble building setuptools on centos 3.8
by Mathieu Jobin 02 Mar '10

02 Mar '10

maybe you can help me. there is something wrong with building this rpm package ? maybe because I am running .... Python 2.2.3 (#1, May 1 2006, 12:33:49) -rwxrwxr-x pje/pje 277 2006-09-20 17:05:03 setuptools-0.6c11/setuptools/command/register.py -rw-rw-r-- pje/pje 4442 2008-02-15 12:29:24 setuptools-0.6c11/setuptools/command/test.py -rwxrwxr-x pje/pje 28275 2009-10-19 13:35:44 setuptools-0.6c11/setuptools/package_index.py -rwxrwxr-x pje/pje 7168 2009-10-19 17:18:57 setuptools-0.6c11/setuptools/gui.exe + STATUS=0 + '[' 0 -ne 0 ']' + cd setuptools-0.6c11 ++ /usr/bin/id -u + '[' 0 = 0 ']' + /bin/chown -Rhf root . ++ /usr/bin/id -u + '[' 0 = 0 ']' + /bin/chgrp -Rhf root . + /bin/chmod -Rf a+rX,g-w,o-w . + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.92516 + umask 022 + cd /usr/src/redhat/BUILD + cd setuptools-0.6c11 + python setup.py build setuptools/dist.py:661: Warning: 'yield' will become a reserved keyword in the future Traceback (most recent call last): File "setup.py", line 12, in ? from setuptools import setup, find_packages File "setuptools/__init__.py", line 2, in ? from setuptools.extension import Extension, Library File "setuptools/extension.py", line 2, in ? from dist import _get_unpatched File "setuptools/dist.py", line 661 yield pkg ^ SyntaxError: invalid syntax error: Bad exit status from /var/tmp/rpm-tmp.92516 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.92516 (%build) Failed to build package setuptools.spec. [root@qcsmbs1004 SPECS]# any idea ? thanks -- Go is to Western chess what philosophy is to double entry accounting. - From Shibumi, bestseller by Trevanian

1 0

setuptools doesn't seem to know about lib64 on Ubuntu
by Bill Janssen 02 Mar '10

02 Mar '10

Hi. I'm trying to install setuptools on a Ubuntu 9.10 system (64-bit), in a custom location: % python setup.py install --install-layout=deb --prefix=/opt/uplib-1.7.9 running install Checking .pth file support in /opt/uplib-1.7.9/lib/python2.6/dist-packages/ error: can't create or remove files in install directory The following error occurred while trying to add or remove files in the installation directory: [Errno 2] No such file or directory: '/opt/uplib-1.7.9/lib/python2.6/dist-packages/test-easy-install-10270.pth' The installation directory you specified (via --install-dir, --prefix, or the distutils default setting) was: /opt/uplib-1.7.9/lib/python2.6/dist-packages/ This directory does not currently exist. Please create it and try again, or choose a different installation directory (using the -d or --install-dir option). % The problem is that it should be looking at /opt/uplib-1.7.9/lib64/python2.6/dist-packages/ which *does* exist, and *is* on the PYTHONPATH. Is there some way I can force this via a commandline option? Bill

1 0

Fwd: The fate of Distutils in Python 2.7
by Tarek Ziadé 01 Mar '10

01 Mar '10

FIY (I didn't cross-post to make it easier for following the threads) ---------- Forwarded message ---------- From: Tarek Ziadé <ziade.tarek(a)gmail.com> Date: Fri, Feb 26, 2010 at 10:44 PM Subject: The fate of Distutils in Python 2.7 To: Python-Dev <python-dev(a)python.org> Hello, This is a follow-up of the Pycon summit + sprints on packaging. This is what we have planned to do: 1. refactor distutils in a new standalone version called distutils2 [this is done already and we are actively working in the code] 2. completely revert distutils in Lib/ and Doc/ so the code + doc is the same than the current 2.6.x branch 3. leave the new sysconfig module, that is used by the Makefile and the site module The rest of the work will happen in distutils2 and we will try to release a version asap for Python 2.x and 3.x (2.4 to 3.2), and the goal is to put it back in the stdlib in Python 3.3 Distutils in Python will be feature-frozen and I will only do bug fixes there. All feature requests will be redirected to Distutils2. I think the easiest way to manage this for me and for the feedback of the community is to add in bugs.python.org a "Distutils2" component, so I can start to reorganize the issues in there and reassign new issues to Distutils2 when it applies. Regards Tarek -- Tarek Ziadé | http://ziade.org -- Tarek Ziadé | http://ziade.org

3 6

Re: [Distutils] layout and setup.py for packaging documentation
by P.J. Eby 01 Mar '10

01 Mar '10

At 10:03 PM 2/28/2010 +0100, Jean Daniel wrote: >Can this be simpler? Yes. Don't install docs with your package. People who want them installed locally can just download your source install or use easy_install -e. Also, if your module is popular enough that people make Linux system packages for it, they will make sure the docs get put in a blessed install location. Python doesn't currently have a blessed install location for documentation, though perhaps it *should* have one in distutils2.

5 8

Re: [Distutils] layout and setup.py for packaging documentation
by P.J. Eby 01 Mar '10

01 Mar '10

At 10:39 PM 2/28/2010 +0000, Michael Foord wrote: >On 28 February 2010 22:14, P.J. Eby ><<mailto:pje@telecommunity.com>pje(a)telecommunity.com> wrote: >At 10:03 PM 2/28/2010 +0100, Jean Daniel wrote: >Can this be simpler? > >Yes. Don't install docs with your package. People who want them >installed locally can just download your source install or use easy_install -e. > >Also, if your module is popular enough that people make Linux system >packages for it, they will make sure the docs get put in a blessed >install location. Python doesn't currently have a blessed install >location for documentation, though perhaps it *should* have one in distutils2. > >How to include documentation in a package is a common question, so >it would be great if distutils2 could deal with this issue. > >My current solution is, as Phillip suggests, to not include the docs >in distributions available via PyPI and to provide a more 'complete' >download separately. That's not what I suggested, actually. I said, don't *install* docs with your package. Do *include* them in your source distribution, though, so people can download and read them with easy_install -e, and also so that those system packagers only have to download one tarball. You also need only produce a standard source distribution (setup.py sdist upload) for PyPI. In other words, Jean Daniel should retain his source layout of: wordish-1.0.2/ setup.py wordish.py docs/ index.html command-ref.html And simply make sure that docs/ is under revision control (setuptools) or add a "recursive-include docs" to MANIFEST.in (distutils). Then, "setup.py sdist" will build a correct tarball.

2 1