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.)
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
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
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
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
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
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
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.
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
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