I've had some problems with py2exe which I *think* highlights a bug in
distutils.
I had a mysterious problems with py2exe causing a 'crash' - not an
exception but a full on windows 'the memory referenced could not be
read' crash. I could reproduce this problem on two machines - (both
windows XP) one with python 2.3 and another with python 2.4, however
no-one else had the same problem.
In order to trace the exact point the crash was occurring I set the
DISTUTILS_DEBUG environment variable.
The crash I was investigating then disapeared (I told you it was
mysterious) - but I got a traceback from within distutils.
The traceback occurs within distutils.command.install - the 'dump_dirs'
function in install.py.
The offending code is :
val = getattr(self, opt_name)
print " %s: %s" % (opt_name, val)
when run from py2exe this causes an AttributeError for the 'no_compile'
attribute.
If replaced with the following code, it works fine.
try:
val = getattr(self, opt_name)
except AttributeError:
print 'Attribute not found :', opt_name
else:
print " %s: %s" % (opt_name, val)
(This is for the Movable Python project - which works fine :-)
Regards,
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
Hi again,
I'm developing a C++ library & associated extension module within the
same directory. My setup.py contains this line:
parser_mod = Extension("paircomp._paircomp_parser",
["c++-ext/_paircomp_parser.cc",],
include_dirs=['../lib',],
library_dirs=['../lib',],
libraries=['paircomp', 'stdc++'])
One of the important libraries that I need to include is -lpaircomp,
in '../lib/libpaircomp.a'.
Currently when I change libpaircomp.a (by, for example, making some
internal change to the C++ library that's not reflected in the API)
my Python extensions do not get recompiled by 'python setup.py build'.
(This is run automatically by the Makefile.)
So at the moment I either have to use Makefile trickery or just do an
'rm -fr build' to force recompilation of the extension when the library
is changed.
Is there a canonical way to tell distutils that 'this extension depends
on this file, so force rebuild if the file changes'?
One obvious possibility would be to simple compare last-changed dates
on all of the libraries with last-changed dates on the .so file
produced by setup.py.
thanks,
--titus
Yarden Katz wrote:
>Oliver Schoenborn <oliver.schoenborn(a)utoronto.ca> writes:
>
>
>>I would guess it's your (possibly missing) MANIFEST file, which should
>>include a line for the data stuff.
>>
>>
>If I "rm MANIFEST" and let distutils recreate it, the problem doesn't change. Am I supposed to manually edit MANIFEST?
>
>
Actually, I meant the MANIFEST*.in* file: AFAIR, sdist only includes
certain known files (*.py etc) and you have to tell it what else to
include in the MANIFEST.in file. The MANIFEST file is automatically
generated if it doesn't exist. OTOH, I think you can directly create a
MANIFEST file, it does not get overwritten if it already exists *and
*there is no *.in* file.
I have refactored the manifest code into a separate module that you can
use for packaging data for other build commands, such as bdist, let me
know if you would like to give it a try (haven't had time to submit it
as a patch yet). I used it to package a database and config files etc
with my distribution.
Oliver
Hi. I'm trying to distribute a piece of software and I'm able to get
distutils to package all of my *.py modules, which are in a single
package, correctly. However, I've been unable to get it to package
any of the data files. I wrote the following setup.py file:
setup(name='pychinko',
version='0.1',
...
packages=['pychinko'],
data_files = [('ruletests/rules', ['ruletests/rules/spoRules.n3'])],
package_dir = {'pychinko': '.'},
package_data = {'pychinko': ['ruletests/rules/spoRules.n3']})
But both data_files and package_data lines (and some variations on
them) are ignored when I run "python setup.py sdist". The pychinko package is
included correctly, but none of the data files are. When it's
packaged I get something like:
creating pychinko-0.1
making hard links in pychinko-0.1...
hard linking setup.py -> pychinko-0.1
hard linking ./__init__.py -> pychinko-0.1/.
hard linking ./afon.py -> pychinko-0.1/.
hard linking ./builtins.py -> pychinko-0.1/.
hard linking ./config.py -> pychinko-0.1/.
...
But again, no data files at all. Any idea what could be doing this?
My dir structure looks something like this:
pychinko/
setup.py
foo.py
bar.py
...
ruletests/
rules/
...
Thanks a lot, appreciate your help,
--
Yarden Katz <yarden(a)umd.edu> | Mind the gap
This email address is no longer valid.
--------------------
Original Message:
X-YahooFilteredBulk: 200.125.45.112
Authentication-Results: mta285.mail.scd.yahoo.comfrom=python.org; domainkeys=neutral (no sig)
X-Originating-IP: [200.125.45.112]
Return-Path: <distutils-sig(a)python.org>
Received: from 200.125.45.112 (EHLO yahoo.com) (200.125.45.112)
by mta285.mail.scd.yahoo.com with SMTP; Mon, 10 Jan 2005 08:51:28 -0800
From: distutils-sig(a)python.org
To: bustamam98(a)yahoo.com
Subject: Spamed?
Date: Mon, 10 Jan 2005 14:50:51 -0300
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0016----=_NextPart_000_0016"
X-Priority: 3
X-MSMail-Priority: Normal
This is a multi-part message in MIME format.
------=_NextPart_000_0016----=_NextPart_000_0016
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
Are you a spammer? (I found your email on a spammer website!?!)
------=_Next
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
The automatic reply to this e-mail which you should have
received in response to your e-mail to webmaster(a)smallco.com has not been defined.
Please contact postmaster(a)smallco.com for assistance.
The automatic reply to this e-mail which you should have
received in response to your e-mail to webmaster(a)smallco.com has not been defined.
Please contact postmaster(a)smallco.com for assistance.
hi there,
I'm writing a custom 'build_scripts' command
that works around a bug in earlier versions
of distutils, i.e. it makes scripts executable
on posix platforms after they got copied to
the build_dir.
I'm looking for a discriminator that allows
me to decide whether or not to run the code,
depending on whether the distutils version
requires it.
It seems the version coming with python 2.2
requires it, while python 2.3 and up don't.
However, distutils.__version__ for python 2.2
as well as python 2.3 are the same ('1.0.3') !
Am I just looking in the wrong place ?
Thanks,
Stefan
The automatic reply to this e-mail which you should have
received in response to your e-mail to webmaster(a)smallco.com has not been defined.
Please contact postmaster(a)smallco.com for assistance.
