Mailman 3 September 2007 - Distutils-SIG

NumPy extensions and setup_requires
by Michael Hoffman Sept. 13, 2007

Sept. 13, 2007

I'm creating a package that uses NumPy to build an extension module. In order to do this, one must call numpy.get_include() like this: ext_modules = [Extension("_fwd_bwd", ["src/_fwd_bwd.pyx", "src/fwd_bwd.c"], include_dirs=[numpy.get_include()])] The problem is that if NumPy is not already installed, this will fail. I can't use setup_requires in a simple manner because the function call needs to happen before the call to setup(). The solution of creating another Distribution object to satisfy setup_requires before running setup() suggested in <http://mail.python.org/pipermail/distutils-sig/2006-October/006744.html> is unsatisfactory for the reasons also suggested there--if I do this --help will not work and it also seems a bit clunky. I was thinking of instead making a subclass of Extension that will call populate include_dirs from a function rather than a list of strings. Is this the best solution? -- Michael

1 1

HTTP access to svn://svn.eby-sarna.com/svnroot/ez_setup
by Michael Hoffman Sept. 12, 2007

Sept. 12, 2007

Is there a way to get HTTP access to the directory available at <svn://svn.eby-sarna.com/svnroot/ez_setup>? I'd like to set svn:externals access to this directory, but one of the hosts I use is behind a firewall and can't use port 3690. It can access HTTP through a proxy. I tried this: $ svn co http://svn.eby-sarna.com/svnroot/ez_setup svn: PROPFIND request failed on '/' svn: PROPFIND of '/': 200 OK (http://svn.eby-sarna.com) $ svn co http://svn.eby-sarna.com/ez_setup svn: PROPFIND request failed on '/ez_setup' svn: PROPFIND of '/ez_setup': 302 Moved Temporarily (http://svn.eby-sarna.com) -- Michael Hoffman

3 3

What is the legal status of virtual-python.py
by Ignas Mikalajunas Sept. 11, 2007

Sept. 11, 2007

Hello, I would like to reuse pieces of code from http://peak.telecommunity.com/dist/virtual-python.py in my "personal" edition of zc.buildout's bootstrap.py (i actually did that already). So running "python bootstrap.py" creates a virtual python in the same directory, and uses that virtual (clean) python to bootstrap zc.buildout. So i could use system python, and at the same time avoid bugs related with linux distribution installed packages conflicting with zc.buildout. All is nice, but now i have no idea what the legal status of this newly created bootstrap.py is. I mean it contains code that is under ZPL (original bootstrap.py), and code that has no license at all and was worked on by at least 2 authors - Phillip Eby and Ian Bicking. Can I even use/distribute the newly created bootstrap.py? Ignas Mikalajūas

1 0

zc.recipe.cmmi
by Miles Sept. 8, 2007

Sept. 8, 2007

Hi, I've created a branch for a change to this recipe to support the ability to download patches via http rather than just using what's on the filesystem. http://svn.zope.org/zc.recipe.cmmi/branches/miwa-patch-url/ We use this to keep common configuration tasks and patches as a "base" config (in one place) that specific projects can extend. Any thoughts at all? I plan to merge this in at the end of the week. Thanks, M

1 1

errors compiling c++ extensions with swig on windows
by Christian K. Sept. 7, 2007

Sept. 7, 2007

Hi, using the following setup file to build a extension from c++ source on windows/mingw with swig 1.3.31, import distutils from distutils.core import setup, Extension ext = Extension("_libpyorigin", ["libpyorigin.i","OPJFile.cpp"], extra_compile_args = ['-w']) setup(name = "libpyorigin", version = "0.1", options={'build_ext':{'swig_opts':'-c++'}}, ext_modules = [ext]) I get the following error: $ python setup.py build_ext --compiler=mingw32 running build_ext building '_libpyorigin' extension swigging libpyorigin.i to libpyorigin_wrap.cpp C:\msys\1.0\local\bin\swig.exe -python -c++ -o libpyorigin_wrap.cpp libpyorigin.i c:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Ic:\Python25\include -Ic:\Python25\PC -c libpyorigin_wrap.cpp -o build\temp.win32-2.5\Release\libpyorigin_wrap.o -w writing build\temp.win32-2.5\Release\_libpyorigin.def c:\mingw\bin\g++.exe -mno-cygwin -mdll -static --entry _DllMain@12 --output-lib build\temp.win32-2.5\Release\lib_libpyorigin.a --def build\temp.win32-2.5\Release\_libpyorigin.def -s build\temp.win32-2.5\Release\libpyorigin_wrap.o build\temp.win32-2.5\Release\opjfile.o -Lc:\Python25\libs -Lc:\Python25\PCBuild -lpython25 -lmsvcr71 -o build\lib.win32-2.5\_libpyorigin.pyd g++: build\temp.win32-2.5\Release\lib_libpyorigin.a: No such file or directory error: command 'g++' failed with exit status 1 What is distutils trying to do with that lib_libpyorigin.a? I could not find the meaning of --output-lib but I suspect g++ is trying to link with that lib but it was meant to build it, right? Is this a bug in distutils or did I do seomething wrong? The same works perfectly on linux, btw. Thanks, Christian

1 0

setuptools special case Pyrex and break Cython
by Stefan Behnel Sept. 5, 2007

Sept. 5, 2007

Hi, Phillip Eby asked me to forward this request to the distutils mailing list, so here it goes. In current setuptools, the file setuptools/extension.py checks for Pyrex being installed and otherwise renames all .pyx file entries to .c. This does not work when Cython is installed *instead of* Pyrex, as Cython will never be executed in this case. It just fails saying that the .c file doesn't exist. I'm currently shipping a fake Pyrex/Distutils/build_ext.py module with lxml to make it work with both, but I don't even see a major advantage in the extension.py module at all. It's plain easy to do that yourself in the setup.py script if (and only if) you want it to build without Pyrex/Cython, but currently, it is enforced in setuptools. This really only works if the distributor wants it and does something to make it work, so always enforcing this behaviour doesn't give you any real advantage. I'd like to see this module removed from setuptools or at least have Cython supported in the same way. Stefan

2 21

profiling setuptools console scripts
by Chris McDonough Sept. 5, 2007

Sept. 5, 2007

This is very minor, but I recently ran across a case where I wanted to profile some code invoked that is invoked by a setuptools console_script. The generated script is in the form: sys.exit( load_entry_point('supervisor==3.0a2', 'console_scripts', 'supervisord')() ) Due to the explicit sys.exit() call, I could not (or at least could not figure out how to) place the profiling hair in the invoked code. I wound up having to change the script to look like this: cmd = "load_entry_point ('supervisor==3.0a2','console_scripts','supervisord')()" if os.environ.has_key('SUPERVISOR_PROFILE'): import profile import pstats profile.runctx(cmd, globals(), locals(), '/tmp/superprofile') stats = pstats.Stats('/tmp/superprofile') stats.strip_dirs() stats.sort_stats('cumulative', 'calls', 'time') stats.print_stats(.3) else: sys.exit(eval(cmd)) I'm wondering if the default generated console_script should refrain from explicitly calling sys.exit. What a wonderful thing setuptools is, seriously. I'm really enjoying using it. - C

2 2

Why are egg-info and related pth files required for rpm packages?
by Stanley A. Klein Sept. 4, 2007

Sept. 4, 2007

I recently installed Fedora 7 and looked at /usr/lib/python2.5/site-packages. The directory has numerous Python packages installed but no egg-info and few .pth files. Of the three .pth files in my installation, only one has a content different from the name of the package (pointing to a subdirectory of site-packages with a different name). Setuptools has the advantage of simplifying preparation of rpms because it has find_packages(). However, it produces egg-info and .pth files as part of the rpm's. I can understand the need for these files when packaging into eggs for installation in places other than python/site-packages or when packaging for non-Linux operating systems. But why are they needed when installing as rpms on Linux systems into site-packages? I think this issue applies to most Linux packaging, which is usually either rpm or deb. Stan Klein

3 3

my wishlist for easy_install
by Toni Mueller Sept. 4, 2007

Sept. 4, 2007

Hi, I'd really like to see these two features in easy_install which I can't find right now: 1 - coexist with the operating system/recognize packages which are installed via operating system means 2 - remove packages Currently, when I want to easy_install a package, it starts downloading all sorts of stuff from PYPI although I have already similar (the same - maybe other versions) packages in my system which I installed via the operating system's package manager. I'd really like to not have to manually inspect a prospective package to then manually download and install all dependencies via the package manager, and then to proceed to easy_install -N the offending package, but instead have this process automated. I'd also be able to say something like easy_install -r package to remove such a package, but only if I installed it via easy_install in the first place, leaving operating system installed packages alone. I'm mostly using easy_install on Debian/Linux (Etch), but other platforms (OpenBSD, maybe Solaris) are relevant for me, too. Thanks for listening! Best, --Toni++

3 2

setuptools 0.6c7 released
by Phillip J. Eby Sept. 4, 2007

Sept. 4, 2007

Highlights: * Now uses the PyPI /simple API * ftp: URLs fixed * nested namespace packages work in --single-version-externally-managed * single-version packages in site-packages don't override .egg in site-packages * workaround for distutils' "broken symlinks" bug * fix egg_info failing on new, uncommitted SVN directories

1 0