Mailman 3 February 2007 - Distutils-SIG

C extensions with non-uniform compiler options
by Konrad Hinsen 20 Feb '07

20 Feb '07

I need to build a C extension consisting of several C code files, one of which needs to be compiled with different compiler options. There doesn't seem to be a standard way to do this. As a workaround I added a dummy extension that uses that file, and specified the necessary compiler options for that extension. Then I removed the source file from the file list of the real extension and replaced it by an entry in extra_objects. The idea is the re-use the version compiled for the dummy extension module. However, there are two problems: 1) The documentation for extra_objects states that "These files must not have extensions, as the default extension for the compiler is used." That would be nice, but isn't true: on my Mac, the required ".o" is not added. 2) The object file I wish to add has been created in "build/ temp.macosx-10.3-fat-2.5", but this directory is machine-specific. I need to construct this path in a portable way - but how? Did anyone already solve these problems, or find another solution? Thanks in advance, Konrad.

1 0

is_python should catch TypeError
by Matt Good 17 Feb '07

17 Feb '07

I just got an error trying to upgrade SilverCity from easy_install: File "/usr/lib/python2.4/site-packages/setuptools-0.6c5-py2.4.egg/setuptools/command/easy_install.py", line 1462, in is_python compile(text, filename, 'exec') TypeError: compile() expected string without null bytes You can reproduce it easily: >>> from setuptools.command.easy_install import is_python >>> is_python('\0') The fix is simply to add TypeError to the except clause along with SyntaxError. -- Matt Good

2 1

Buildout: Recipes with extras
by Thomas Lotze 17 Feb '07

17 Feb '07

Automatic installation of eggs required by an egg extra doesn't seem to work for a recipe used with zc.buildout as documented for eggs in general: Suppose myrecipe has two entry points, the "fancy" one employing yourrecipe. Now if I declare yourrecipe as an extra requirement only to be installed if the "fancy" entry point is used to install any buildout part: myrecipe/setup.py: ... setup(... entry_points={"zc.buildout": [ "default = myrecipe.foo:Recipe", "fancy = myrecipe.bar:Recipe [bar_extra]", ]}, extras_require={"bar_extra": ["yourrecipe"]}, ... ) and use myrecipe I get a pkg_resources.DistributionNotFound error concerning yourrecipe. It sort of works if I manually copy the yourrecipe egg to the eggs directory beforehand, though. Is this a real bug, or are recipes supposed to be so simple as to not need extras? -- Viele Grüße, Thomas

3 6

easy_install feature request
by Thomas Heller 16 Feb '07

16 Feb '07

The more I manage the third-party packages I have installed with easy_install, the more I like that I never have to fiddle around in the file system. (Except when I want to free the space that a no-longer needed package consumes, "easy_install -m <package-name>" works fine). However (since I'm playing around with support for eggs in py2exe), it is not possible to reinstall an already installed (by it multi-version or not) package in zipped or unzipped form by using easy_install. I always have to delete the package in the file-system and then call 'easy_install -z|-Z package'. Thomas

2 1

c extensions: how to rebuild and test quickly
by Paul Pogonyshev 15 Feb '07

15 Feb '07

Hi, Distutils create dynamic library for a C extension in `build/...' directory. This makes it impossible to run program without installing it, which I find very important for developing. Ideally, process should look like this: edit Python code -> test (uninstalled); or edit C code -> ./setup.by build -> test (uninstalled). This is all possible if I create a symbolic link from build directory to the sources. Then extension module can be imported normally and everything is like it was with all code limited to Python. Is it possible in some standard (and preferably portable) way with distutils? Is it already done? Paul

4 8

ctypes setuptools egg
by Venkat Bommakanti 15 Feb '07

15 Feb '07

Hi folks, I'd like to know if there is a source egg of ctypes (for Python 2.4.x) that can be built and deployed via setuptools... I need to be able to cross compile ctypes from an i686Linux box targeting both i686 and ppc Linux's. I'd like to deploy it with a python app that is also being built/pkg as an egg. I searched the archives, but found no pointers. Thanks, /venkat ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com

3 2

Re: [Distutils] Cheesecake service
by Phillip J. Eby 15 Feb '07

15 Feb '07

At 03:41 AM 2/14/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote: >On top of PyPI and Cheesecake I've build a Cheesecake service - a >service which automatically downloads and scores new package releases. >It is available at this address: http://pypi.pycheesecake.org/pypi/ . >Probably of most interest here is the easy_installability page >(http://pypi.pycheesecake.org/pypi/easy_installability) which shows >releases which are listed on PyPI, yet still can't be easy_installed. >[snip] >I'm open to any suggestions on how this service can be improved. More information about *how* the installation failed would be useful for package authors to see at a glance what's wrong. Right now, it's too easy to dismiss it as a peculiarity of your installation. Being able to click through and see the log/tracebacks would probably make it more likely that an author spots the problem(s).

3 6

Building shared libraries?
by Hans Meine 15 Feb '07

15 Feb '07

Hi! I know that distutils' purpose is not to re-implement libtool, but.. it seems that it is a common problem that one wants to ship several extension modules which rely on the same code. E.g. we have several image processing functions split across several extension modules (written in C++), and we need them all to know about our PythonImage class. (E.g. PythonImage::subImage(...) or the like.) A natural way to solve this is to compile pythonimage.cxx into a small shared library which the extension modules link against. So far, it seems that all projects which have this problem use Extension(...) to build a shared library or call make / do whatever custom hacks were necessary for them. (One source of information were the answers to David Abrahams question some years ago: http://mail.python.org/pipermail/distutils-sig/2002-October/002966.html and I also asked on C++-sig lately: http://mail.python.org/pipermail/c++-sig/2007-February/011973.html ) Would it be possible to add a distutils.SharedLibrary class? (OK, would someone be willing to provide the code? ;-) ) Ciao, / / /--/ / / ANS

1 0

[PATCH] Handling of scripts / substitution of python executable path
by Hans Meine 15 Feb '07

15 Feb '07

Hi! For a long time, I have been annoyed by distutils behavior concerning "scripts": I always put #!/usr/bin/env python into the first line in order to let the incredibly useful "env" program start the right python version. I know that it is quite evil to hardcode /usr/bin/python or /usr/local/bin/python; I have seen dozens of #! hacks for finding e.g. perl, and I was delighted to find /usr/bin/env, which solves the problem once and for all. (And yes - it is always in /usr/bin/! ;-) ) Now distutils tries to be intelligent and "destroys" my nice #! lines, which can be quite evil in complex setups, e.g. when you share your home directory via NFS (or rsync/unison) between several environments with different python installations. Furthermore, we are using the "module" system here at our university, so that I can dynamically choose between half a dozen python versions ("module" manages your PATH variables). Replacing the python path turns nice, pure python scrips into platform-specific programs as you can see here: meine@kogspc12:~ head -n1 ~/vigra/interactive/build/scripts-2.4/pyterm #!/software/python-2.4.4/SuSE-9.0/bin/python Note the SuSE-9.0 exec-prefix in the path; we are using several Linux and Solaris versions here: meine@kogspc12:~/tmp/vi3build -> ls -1 /software/python-2.4.4/*/bin/python /software/python-2.4.4/SuSE-10.0/bin/python* /software/python-2.4.4/SuSE-9.0/bin/python* /software/python-2.4.4/SunOS-5.8/bin/python* I see that distutils as it is now does the right thing * on Windows systems, * on any system where /usr/bin/env is missing, or * when the source file has a #! with a broken path. What I propose is a minimal invasive change which keeps /usr/bin/env iff it is in the #! line *and* exists on the current system. (A more brave change would be to always use /usr/bin/env if it exists, but I think that is a topic open for discussion.) Attached you'll find a patch which implements this; I did not yet update tests/test_build_scripts.py however. Comments? Ciao, / / /--/ / / ANS

1 0

Re: [Distutils] pkg_resources._macosx_vers without using os.popen
by Phillip J. Eby 14 Feb '07

14 Feb '07

At 02:35 PM 2/13/2007 -0800, Ronald Oussoren wrote: >Philip, > >The attached patched replaces pkg_resources._macosx_vers by a function >that directly parses the relevant XML file instead of using sw_vers. The >patch is an svn diff relative to the trunk. > >The main reason I prefer this version is that I'm debugging some C code in >a project using setuptools using command-line gdb (who needs IDE's?) and I >often (but not always) get I/O errors when reading from a pipe to a >forked-off process when running python from gdb. With this patch >pkg_resources no longer forks of processes and gdb is happy. > >When you're not using gdb there's little reason to prefer this version >over the original one. Your patch uses plistlib, which doesn't appear to be part of the Python standard library.

2 1