Mailman 3 February 2009 - Distutils-SIG

Maintainer and Maintainer email metadata
by Tarek Ziadé 15 Feb '09

15 Feb '09

Hello, Right now Distutils will let you add the name of the maintainer and the name of the author as two distinct metadata in your package. When creating the PKG-INFO, Distutils includes an "Author" line. To build it, it will look at first for at the maintainer metadata and use it if provided, then only at the author metadata. This is not a correct behavior; Two points: 1/ Distutils should not use the maintainer metadata to create the *Author* line in the PKG-INFO 2/ We could add the extra "Maintainer" field in PKG-INFO, I am all for 1/, but I am not sure for 2/. I never use the Maintainer field my self. Any opinions ? Regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

2 2

Extending default file list
by Tarek Ziadé 14 Feb '09

14 Feb '09

Hi, for http://bugs.python.org/issue2279 I would like to extend the default file list (sdist.add_defaults) so it adds files pointed by package_data and data_files Any objection/opinion ? Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

1 0

[issue59] [PATCH] sandbox.py replaces builtin type file with builtin function open
by Philip Jenvey 13 Feb '09

13 Feb '09

New submission from Philip Jenvey <pjenvey(a)underboss.org>: builtin open changed from an alias to the file type to a function in Python 2.5. sandbox.py assumes file is open when replacing/restoring the two with sandboxed versions Attached is a patch that removes that hardcoding Prioritized as critical, this is evil! ---------- assignedto: pje files: builtin_file-r66750.diff messages: 236 nosy: pje, pjenvey priority: critical status: unread title: [PATCH] sandbox.py replaces builtin type file with builtin function open Added file: http://bugs.python.org/setuptools/file36/builtin_file-r66750.diff _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue59> _______________________________________________

1 0

Re: [Distutils] Wrong depedencies in install_lib command?
by P.J. Eby 13 Feb '09

13 Feb '09

At 08:06 PM 2/11/2009 +0100, Patrick Gerken wrote: >Hello, > >i tried to install reportlab via easy_install, which always failed >while compiling some c-modules. >Installing it via setup.py install worked flawlessly > >After a while, I found the difference. >setup.py install calls the command _build_, which calls _build_clib_ >and then _build_ext_ > >easy_install calls _bdist_egg_, which calls _install_lib_, which >calls _build_ext_ WITHOUT calling _build_clib_. >The module docstring of the command build_clib mentions, that these >libraries can be a dependency to build_ext, so I patched >install_lib.py to call build_clib too, and now I can easy_install >the newest reportlab! > >If anybody wants to reproduce the behaviour, I added my patch, which >I did against the current trunk of distutils/command/install_lib.py >I made a relative patch so to patch the file. you have to go into >this directory and call > >patch install_lib.py dependency.patch > >Does this qualify as a bug in the bugtracker? Yes, definitely. It'd be nice to have a setuptools patch to workaround the problem as well.

2 1

How to use buildout with a scripts directory?
by Jon Wright 12 Feb '09

12 Feb '09

Dear distutils-sig, [Apologies if this is a newbie question] I am trying to use buildout and am having trouble to figure out how to get it to install the scripts that come with a package. They are present inside the egg which is installed by buildout, but they don't end up in the bin directory. After running buildout my bin directory is empty, but I can find: .\eggs\imaged11-1.2.3-py2.5-win32.egg\EGG-INFO\scripts\peaksearch.py In the package I have a directory (ImageD11) with the library stuff in it and a directory named "scripts" with the scripts. When I use distutils or setuptools it does what I expected: setup.py: ... setup(name='ImageD11', ..., packages = ["ImageD11"], package_dir = {"ImageD11":"ImageD11"}, scripts = [ "scripts/peaksearch.py", "scripts/bgmaker.py", ...] ) c:\testImageD11distutils\> python setup.py install ... Installing peaksearch.py script to c:\python25\Scripts Installing bgmaker.py script to c:\python25\Scripts Now I am wondering how to persuade "buildout" to do the same thing, but place those scripts into it's own little area. In buildout.cfg I have: ================== [buildout] parts = ImageD11 [ImageD11] recipe = zc.recipe.egg:scripts scripts = scripts/peaksearch.py eggs = ImageD11 version = 1.2.3 It seems to acknowledge that scripts/peaksearch.py is requested, but doesn't seem to do anything about it. My scripts mostly just map command line arguments to function calls, something like this: if __name__=="__main__": import ImageD11.something, sys ImageD11.something.do_thing( sys.argv[1], sys.argv[2] ) I've read the documentation at http://pypi.python.org/pypi/zc.buildout several times but I still can't figure out how to make these scripts part of the build. There seems to be a lot of talk about entry_points, but I'm blocked on those: * what is the entry point for an if __name__=="__main__": idiom? * as these things were in ./scripts/, they aren't in the module, so how to I reference them anyway? Thanks in advance for any help! Jon

2 2

Wrong depedencies in install_lib command?
by Patrick Gerken 11 Feb '09

11 Feb '09

Hello, i tried to install reportlab via easy_install, which always failed while compiling some c-modules. Installing it via setup.py install worked flawlessly After a while, I found the difference. setup.py install calls the command _build_, which calls _build_clib_ and then _build_ext_ easy_install calls _bdist_egg_, which calls _install_lib_, which calls _build_ext_ WITHOUT calling _build_clib_. The module docstring of the command build_clib mentions, that these libraries can be a dependency to build_ext, so I patched install_lib.py to call build_clib too, and now I can easy_install the newest reportlab! If anybody wants to reproduce the behaviour, I added my patch, which I did against the current trunk of distutils/command/install_lib.py I made a relative patch so to patch the file. you have to go into this directory and call patch install_lib.py dependency.patch Does this qualify as a bug in the bugtracker? Best regards, Patrick

1 0

Re: [Distutils] occasional zipimport.ZipImportError: bad local file header
by P.J. Eby 10 Feb '09

10 Feb '09

At 06:43 PM 2/5/2009 +0000, Fadhley Salim wrote: >I'm working on an automatic testing framework which installs eggs >downloaded directly from the web-server. From time to time I get a very >long stacktrace leading to a ZipImportError (see the pastebin link). >Leading up to the error all I do is download the egg into the system's >%TEMP% folder. I'm installing the egg like this: > >easy_install.main( ['-zma', '-f' , config.INSTALL_TOOLS_EGG_VALIDHOSTS, >filepath, ] > >There is apparantly nothing wrong with the file - I can open it in >Winzip. If I re-run the process it seems to work fine. The file in >question appears to be identical. The error is rare, it seems to occur >in about 1 out of 100 easy_install operations. Any suggestions what >might be causing this? > >Very long stacktrace on pastebin: >http://python.pastebin.com/m378949f3 > >I am using setuptools==0.6c9 on Python 2.4 running on Windows XP This might be due to: http://bugs.python.org/issue856103 Specifically, zipimport's caching doesn't notice that it's not working on the same zipfile any more. easy_install is supposed to have some code in it to clear out the zipimport cache, but there is some possibility that it could have two versions of the path in there on a case-insensitive filesystem (e.g. Windows), and only one of them is getting cleared. Dunno if that's the case or not, but it might be something to look into. You could always stick a debugging print in the uncache_zipdir function and see if there's any correlation between what it's doing and when you're getting the error.

1 0

[buildout] setuptools/buildout trying to use /root/.python-eggs after setuid()ing with Zope
by Andreas Jung 10 Feb '09

10 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, I am not sure which component is in charge for the following issue: - standard Plone 3.1 installation installed with paster/Zopeskel with a 'zope' account without special privileges - in the instance is started from through /etc/init.d as root but immediately setuid to effective-user 'zope' - after setuid(), setuptools is trying to write to /root/.python-eggs during the startup-phase for (my own) module zopyx.textindexng3 - - it creates inside: new:~/.python-eggs # ls -la total 1 drwxrwxrwx 3 root root 144 Feb 4 13:17 . drwxr-xr-x 24 root root 1200 Feb 4 17:10 .. - -rw-r--r-- 1 zope users 0 Feb 4 13:17 a drwxr-xr-x 3 zope users 72 Feb 4 13:17 zopyx.textindexng3-4.0.1-py2.4-linux-x86_64.egg-tmp Why is setuptools using /root/.python-eggs only for this particular module and isn't it using something like /home/zope/.python-eggs instead - especially having changed the UID already? Andreas - -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info(a)zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK - ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkmJv30ACgkQCJIWIbr9KYwFVACbBM1JaanJvokkXLwcyMc6Dc4y FCoAoIfG2qniHaLZbxS3OeGzh2fZkffe =g4Ta -----END PGP SIGNATURE-----

3 2

zc.buildout newbie question
by Teemu Harju 05 Feb '09

05 Feb '09

Hi all, I've been looking into zc.buildout since it seems to be quite useful application when developing and distributing Python applications. However, I'm finding it difficult to figure out how it should actually be used. I give you an example of what I'm trying to do and what my problem is. This is probably really trivial but bear with me. ;-) I'm developing a Twisted application and would like to use zc.buildout for bootstrapping development environments and probably even deploying the application to the production system. Here's my very simple buildout.cfg: --- [buildout] parts = twisted [twisted] recipe = minitage.recipe:du url = http://tmrc.mit.edu/mirror/twisted/Twisted/8.2/Twisted-8.2.0.tar.bz2 --- This works fine and installs Twisted under parts/site-packages-2.5/ and twistd, trial and other scripts under bin/. I'm doing all this inside virtualenv, but I guess it shouldn't matter. Now, my problem is that since the packages are installed in parts/ so they are not visible to my python interpreter. What is the right way to do this? Should I just add /parts/site-packages-2.5 to my PYTHONPATH or? Is there some way to do that using buildout.cfg? I tried to find examples of this but didn't find any. Br, - Teemu -- Teemu Harju email/jabber: teemu.harju(a)gmail.com blog: http://blog.teemu.im

4 4

zc.buildout 'extends' options
by Martin Aspeli 05 Feb '09

05 Feb '09

Hi Jim & co, Plone 3.2 currently distributes its packages as eggs, and people use an 'extends' option with a remote URL to get a known good set for each version, e.g.: [buildout] extends = http://dist.plone.org/release/3.2/versions.cfg This is similar to how Grok does its distributions, of course. Now, as far as I can tell, this doesn't work offline. -o mode does not complain, but if you're totally offline (turn off your network interface), then urllib throws an error when buildout tries to evaluate the 'extends' option, and buildout crashes completely. I'd like to have an optional download cache directory, e.g. [buildout] extends-cache = extends-cache-directory extends = http://dist.plone.org/release/3.2/versions.cfg In offline mode, buildout would look for the file to extend (probably with some hash of the url used as filename) in the directory specified by extends-cache. This would allow full offline mode (e.g. on a machine with no network card configured). In particular, it would allow Plone's buildout-based installers to ship with the versions.cfg file and not require people to be able to download them. Is this desirable? Any plans for such a feature? Would you accept a patch, if we could make it work? -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book

3 4