Distutils-SIG December 2005

distutils-sig@python.org

35 participants
60 discussions

Re: [Distutils] using distutils / setuptools on Windows (MinGW)
by Phillip J. Eby 19 Dec '05

19 Dec '05

At 08:01 PM 12/19/2005 +0000, Paul Moore wrote: >On 12/19/05, Phillip J. Eby <pje(a)telecommunity.com> wrote: > > At 04:59 PM 12/19/2005 +0100, Daniel Glöckner wrote: > > FYI, the shortest path to using MinGW with distutils or setuptools is to > > run this script and follow its directions: > > > > http://mail.python.org/pipermail/python-dev/2004-January/041676.html > > > > Once you've done that, the version of Python you ran it with will use the > > MinGW compiler automatically for all building, with no '-cmingw32' > required. > >Actually, the referenced script just prints instructions on modifying >distutils.cfg, it doesn't do it automatically. That's why I said "run this script and follow its directions". :) The script builds libpython2X.a, which is the hard part for most earlier Python versions. >As of Python 2.4, this is no longer needed - libpython24.a is shipped >with the standard Python Windows installer (and yes, I mean all >versions of Python 2.4 - memo to self, must upgrade home PC...) > >The distutils.cfg change is still needed if you want to make mingw the >default - personally, I just use the command line flag >--compiler=mingw32. This can be abrreviated -cmingw32, of course, but if you use easy_install it's best to update the distutils.cfg, so that it will use that compiler by default. Of course, if you have a setuptools-based project you can always do this once: setup.py build -cmingw32 saveopts -g This will update distutils.cfg automatically after running the build, to save any options you used on the command line in the (-g) global configuration. See the "saveopts" command in the setuptools manual for details. (This is one of several setuptools commands that could probably be non-controversial additions to the official distutils: alias, rotate, saveopts, and setopt.)

1 0

using distutils / setuptools on Windows (MinGW)
by Daniel Glöckner 19 Dec '05

19 Dec '05

Hi all! In our working group, we're starting to use python for some machine learning tasks. Performance needs force us to deliver some of our code as optimized C code. To make a long story short: I was the one to discover howto deploy native python extensions on windows. The online documentation on various sites about that topic is quite old and sometimes faulty. I think the setuptools are a big step forward for professional deployment of python applicatoions. Keep up the good work guys! Maybe I can contribute to the project by giving you a more recent documentation on compiling and deploying python code and python C extensions on windows using -MinGW -setuptools / distutils -SWIG. Cheers, Daniel

3 2

specify zip method (ZIP_STORED, ZIP_DEFLATED)
by Wolfgang Langner 19 Dec '05

19 Dec '05

Hello, is there a way to specify the zip method like ZIP_STORED or ZIP_DEFLATED as in python zipfile module ? I think it is possible to speed up something if ZIP_STORED is used to "compress" egg packages. (not tested only thoughts) And on a platform with no zlib it schould be possible to create .egg files. I have searched the docu but nothing found on that topic. bye by Wolfgang

2 1

[setuptools] setup.py develop inaccurate error message?
by John J Lee 18 Dec '05

18 Dec '05

I got an error message while running setup.py develop that I don't understand: seems the error message claims an automatic install of a dependency failed, even though the dependency's egg actually did get installed and appears correct. (A bit tangential, but explanatory) background: Noting PJE's doc update repeating your recomendation to run setup.py develop. I wondered how setuptools would handle fetching a newer SVN revision of a dependency D installed with setup.py develop from an SVN checkout when running setup.py develop on a project P that depends on D. Would it use the .egg-link file to find and update the original working copy from which D was installed, or instead create a fresh SVN checkout? D == ClientForm P == mechanize So, I tried the following: 1. Installed ClientForm in site-packages from an SVN checkout using setup.py develop 2. Installed mechanize, which depends on Clientform, from an SVN checkout using setup.py develop 3. Modified my local copy of mechanize's setup.py to require a newer revision of ClientForm than I had installed in step 1. The modified dependency reads "ClientForm>=0.2.2-r21160, ==dev" 4. Ran python setup.py develop again for mechanize. That last step installed an egg with the right name (using a fresh checkout, which I guess answers the question above that motivated me), but also ended with this error message: error: Could not find required distribution ClientForm==dev,>=0.2.2-r21160 However, the ClientForm egg did in fact get installed and does indeed contain revision 21160. So, why the error message? Full output of step 4: mechanize[0]# python setup.py develop running develop running egg_info writing requirements to ./mechanize.egg-info/requires.txt writing ./mechanize.egg-info/PKG-INFO writing top-level names to ./mechanize.egg-info/top_level.txt running build_ext Creating /usr/lib/python2.3/site-packages/mechanize.egg-link (link to .) mechanize 0.0.12a.dev-r20866 is already the active version in easy-install.pth Installed /hda/usr/local/buf/comp/dev/wwwsearch/wwwsearch/mechanize Processing dependencies for mechanize==0.0.12a.dev-r20866 Searching for ClientForm==dev,>=0.2.2-r21160 Reading http://www.python.org/pypi/ClientForm/ Reading http://wwwsearch.sourceforge.net/ClientForm/ Best match: ClientForm dev Downloading http://codespeak.net/svn/wwwsearch/ClientForm/trunk#egg=ClientForm-dev Doing subversion checkout from http://codespeak.net/svn/wwwsearch/ClientForm/trunk to /tmp/easy_install-31mf3S/trunk Processing trunk Running setup.py -q bdist_egg --dist-dir /tmp/easy_install-31mf3S/trunk/egg-dist-tmp-qFDl23 Removing ClientForm 0.2.2.dev-r20620 from easy-install.pth file Adding ClientForm 0.2.2.dev-r21160 to easy-install.pth file Installed /usr/lib/python2.3/site-packages/ClientForm-0.2.2.dev_r21160-py2.3.egg error: Could not find required distribution ClientForm==dev,>=0.2.2-r21160 mechanize[0]# mechanize[0]# cd ../ClientForm ClientForm[0]# svn st -u ? README.html * 20620 README.html.in * 20620 test.py * 20620 setup.py M * 20620 ClientForm.py ? ClientForm.egg-info ? ClientForm.pyc X ez_setup Status against revision: 21261 Performing status on external item at 'ez_setup' ? ez_setup/__init__.pyc Status against revision: 2110 ClientForm[0]# cat /usr/lib/python2.3/site-packages/mechanize.egg-link /hda/usr/local/buf/comp/dev/wwwsearch/wwwsearch/mechanizeClientForm[0]# pwd /home/john/comp/dev/wwwsearch/wwwsearch/ClientForm ClientForm[0]# John

2 3

[setuptools] How to maintain version strings?
by John J Lee 18 Dec '05

18 Dec '05

Annoying little issue: I have version strings here and there in my projects, and would prefer to keep the version in a single place. In particular, I have __version__ strings in module code, and also in setup.py. I also want to avoid importing code from setup.py, because people sometimes want to install using a Python executable other than the one with which they intend to import the package (I assume that's sensible & possible with setuptools packages), and imports in setup.py have broken that in the past. Seems I can't just open('mymodule.py') and find the version string with a regexp, I assume because of setuptools' "sandbox". So, I just have to have my release script check that I remembered to update both. No big deal, but it annoys me :-) Anybody have a way of doing this (or a slap to my forehead to teach me the simple way to do it ;-)? John

2 1

Upgrade a package
by Sharky On PTNet 17 Dec '05

17 Dec '05

Hi, Every time I do an 'easy_install -U ...' for a package, it installs ok but remain with the old package in site-packages. Is there a way do remove old packages? ex.: $ ls -ltrd /usr/lib/python2.4/site-packages/Tur* drwxr-xr-x 4 root root 4096 2005-12-07 22:14 /usr/lib/python2.4/site-packages/TurboGears-0.8a5-py2.4.egg drwxr-xr-x 4 root root 4096 2005-12-17 13:13 /usr/lib/python2.4/site-packages/TurboGears-0.9a0dev-py2.4.egg $ ls -ltrd /usr/lib/python2.4/site-packages/setu* drwxr-xr-x 4 root root 4096 2005-11-24 19:08 /usr/lib/python2.4/site-packages/setuptools-0.6a7-py2.4.egg drwxr-xr-x 4 root root 4096 2005-12-07 21:24 /usr/lib/python2.4/site-packages/setuptools-0.6a9dev_r41630-py2.4.egg -rw-r--r-- 1 root root 70 2005-12-07 21:24 /usr/lib/python2.4/site-packages/setuptools.pth

2 1

Bug with bdist_rpm and version containing '-'
by Giovanni Bajo 17 Dec '05

17 Dec '05

Hello, while using distutils shipped with Python 2.4.2, I found out a problem when running bdist_rpm if the version of the package contains an hyphen ('-'). The problem is that RPMs do not support hyphens in versions, and bdist_rpm tries to work around this by replacing hyphens with underscores ('_'). While this is the correct solution, it appears to be incomplete, because bdist_rpm invokes 'sdist' to build the .tar.gz (or .tar.bz2) without notifying it of the change of the version string (and thus of the change of the filename that sdist will have to generate). I have succesfully worked around this bug with this hack in my setup.py: class _bdist_rpm(bdist_rpm): def run_command(self, cmd, *args, **kwargs): if cmd == "sdist": old_version = self.distribution.metadata.version if self.distribution.metadata.version is not None: self.distribution.metadata.version = old_version.replace("-", "_") bdist_rpm.run_command(self, cmd, *args, **kwargs) self.distribution.metadata.version = old_version return bdist_rpm.run_command(self, cmd, *args, **kwargs) This works by patching the version at the moment of the call to 'sdist' from within bdist_rpm. Of course it's a gross hack but I couldn't find a better way :) Thanks, Giovanni Bajo

2 2

Re: [Distutils] problem finding dll with C extension
by Phillip J. Eby 17 Dec '05

17 Dec '05

At 04:31 PM 12/16/2005 -0800, mike cantor wrote: >Another piece of information. The error message I get ("ImportError: DLL >load failed: The specified module could not be found") is different that >the error message I get if I try to import a non-existent module (namely, >"ImportError: No module named Foo"). So somewhere within the module a DLL >is failing to load. Any ideas???? Either libgsl or one of its dependencies isn't loading. My guess would be that E:\Program Files\GnuWin32\lib isn't on your PATH.

2 1

Re: [Distutils] problem finding dll with C extension
by mike cantor 17 Dec '05

17 Dec '05

Another piece of information. The error message I get ("ImportError: DLL load failed: The specified module could not be found") is different that the error message I get if I try to import a non-existent module (namely, "ImportError: No module named Foo"). So somewhere within the module a DLL is failing to load. Any ideas???? At 12:44 PM 12/16/2005, mike cantor wrote: >Hi, > >I have just built a C extension. "python setup.py install" successfully >builds the extension and puts the library , PGModule.pyd, in the >Python23\Lib\site-packages folder. However, from within Python, "import >PGModule" yields "ImportError: DLL load failed: The specified module could >not be found" > >The setup.py file I am using looks like this: > >from distutils.core import setup, Extension >setup(name='PGModule', ext_modules=[ Extension('PGModule', > sources = ['PGfit_DataTypes.c', 'PGModule.c'], > include_dirs=["E:\Program > Files\GnuWin32\include","E:\sundials\includes"], > libraries = ["libgsl"], > library_dirs = ["E:\Program Files\GnuWin32\lib"]) ]) > >A few more clues/oddities: The extension uses the gsl (gnu scientific >library) library. Without the "libraries" and "library_dir" flags, my >code compiles fine but does not link (I get error messages like "in >PGModule.o unidentified reference gsl_set_vector" etc). Other extensions >that I compile from the same directory and using the same setup file, but >minus the library flags, build fine and are importable and usable from >within Python. When I look in the site-packages folder, PGModule.pyd is >right there along with other modules (e.g. PGFit.pyd), yet "import >PGModule" from a python shell yields the aforementioned error while >"import PGFit" executes successfully. > >Any ideas? > >Thanks a ton, >-mike

1 0

problem finding dll with C extension
by mike cantor 16 Dec '05

16 Dec '05

Hi, I have just built a C extension. "python setup.py install" successfully builds the extension and puts the library , PGModule.pyd, in the Python23\Lib\site-packages folder. However, from within Python, "import PGModule" yields "ImportError: DLL load failed: The specified module could not be found" The setup.py file I am using looks like this: from distutils.core import setup, Extension setup(name='PGModule', ext_modules=[ Extension('PGModule', sources = ['PGfit_DataTypes.c', 'PGModule.c'], include_dirs=["E:\Program Files\GnuWin32\include","E:\sundials\includes"], libraries = ["libgsl"], library_dirs = ["E:\Program Files\GnuWin32\lib"]) ]) A few more clues/oddities: The extension uses the gsl (gnu scientific library) library. Without the "libraries" and "library_dir" flags, my code compiles fine but does not link (I get error messages like "in PGModule.o unidentified reference gsl_set_vector" etc). Other extensions that I compile from the same directory and using the same setup file, but minus the library flags, build fine and are importable and usable from within Python. When I look in the site-packages folder, PGModule.pyd is right there along with other modules (e.g. PGFit.pyd), yet "import PGModule" from a python shell yields the aforementioned error while "import PGFit" executes successfully. Any ideas? Thanks a ton, -mike

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG December 2005