Mailman 3 September 2003 - Distutils-SIG

walking for sub-packages
by David Abrahams 27 Sep '03

27 Sep '03

I just added the following to a setup.py: # # Find all the sub-packages of Synopsis # def add_package(found_packages, directory, local_names): if '__init__.py' in local_names: found_packages.append( re.sub('.*Synopsis', 'Synopsis', directory) .replace(os.path.sep, '.') ) else: local_names = [] py_packages = [] os.path.walk('Synopsis', add_package, py_packages) # sanity check assert 'Synopsis.Core' in py_packages Then naturally, I call setup with packages=py_packages. Is something like that capability built into distutils? If not, shouldn't it be? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[bug] -lutil in get_config_var('LIBS') on cywgin
by David Abrahams 27 Sep '03

27 Sep '03

$ python Python 2.3 (#1, Aug 1 2003, 15:01:23) [GCC 3.2 20020927 (prerelease)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> from distutils import sysconfig >>> print sysconfig.get_config_var('LIBS') -lutil Cygwin doesn't have any libutil, so this causes problems for anything which takes distutils' word about which libraries are needed. http://synopsis.sf.net is one example. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

MANIFEST generation
by Alexandre Fayolle 26 Sep '03

26 Sep '03

Hi, I have the feeling that the MANIFEST file is not always generated from the MANIFEST.in, especially if MANIFEST.in has not changed since the previous generation. Is this the right behaviour? I was recently bitten by this when shipping a bugfix release: new files had been added which should have made it to the tarball, but since the MANIFEST file was not regenerated, this did not happen. Is regenerating the MANIFEST file so expensive that this tiny optimisation is necessary? My experience with most package is that the time gained is not that big -- especially compared to the time spent tracking the missing files ;o) -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Développement logiciel avancé - Intelligence Artificielle - Formations

4 5

Workarounds for C++ module linking issues - OK?
by Nicholas Riley 25 Sep '03

25 Sep '03

Hi, It's me again. With the exception of the clean problem in my previous email, I think I've got my distutils-based setup script working properly. To do so, I've needed to add a few workarounds where distutils wasn't doing the right thing, and I couldn't convince it to do so by ordinary means. The changes revolve around the fact that the module is written in C++, and I want to provide support back to Python 1.5.2. They are as follows. class build_mkext(build_ext): # force use of C++ compiler (helps on some platforms) def finalize_options(self): self.run_command('config') import os cc = os.environ.get('CXX', sysconfig.get_config_var('CXX')) if not cc: cc = sysconfig.get_config_var('CCC') # Python 1.5.2 if cc: os.environ['CC'] = cc build_ext.finalize_options(self) def build_extension(self, ext): # work around linker problem with MacPython 2.3 if sys.platform == 'darwin': try: self.compiler.linker_so.remove("-Wl,-x") except: pass # work around linker problem with Linux, Python 2.2 and earlier: # despite setting $CC above, still uses Python compiler if sys.platform == 'linux2': try: ext.libraries.append("stdc++") except: pass [...] Does this all look OK? I realize it's not the cleanest thing in the world, but such workarounds seldom are. I just don't want to do something that will break in the near future, and this is the first distutils setup script I've written. :-) If you need to see the rest of the file, it's at: <http://web.sabi.net/temp/setup.py> Thanks, -- =Nicholas Riley <njriley(a)uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>

1 0

clean -b argument ignored; set_undefined_options doesn't
by Nicholas Riley 25 Sep '03

25 Sep '03

Hi, Here's something that I think should work: % python setup.py --help clean [...] Options for 'clean' command: --build-base (-b) base build directory (default: 'build.build-base') % python setup.py clean -b ../builds running clean Nothing happens. This works, however: % python setup.py build -b ../builds clean running build running build_py running build_ext running config gcc -E -I/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -o_configtest.i _configtest.c removing: _configtest.c _configtest.i running clean removing '../builds/temp.darwin-6.8-Power_Macintosh-2.3' (and everything under it) The logic to set build_temp from build_base (-b) is only present in the build command, not in the clean command. The code to set this option runs from clean.set_undefined_options. But it's clean's build_base option which is set at the time, not build's, so it propagates an empty path. The test command class I found posted to this mailing list has a workaround for the above problem, which looks like this: def finalize_options(self): build = self.distribution.get_command_obj('build') build_options = ('build_base', 'build_purelib', 'build_platlib') for option in build_options: setattr(build, option, getattr(self, option)) build.ensure_finalized() for option in build_options: setattr(self, option, getattr(build, option)) and doesn't call self.set_undefined_options at all, though the last three lines could be replaced by it. There are several solutions I can think of: - set_undefined_options should be changed to propagate set options to the source command object before calling src_cmd_obj.ensure_finalized. - another method should be added to the cmd class, which does the above propagation then calls set_undefined_options. - a workaround such as the one above should be placed in the distutils.command.clean.clean class. Does this make sense? Unless there's a huge compatibility issue, I'd favor the first option, but my experience with distutils is limited. -- =Nicholas Riley <njriley(a)uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>

1 0

py2exe question
by Paul Gardella 25 Sep '03

25 Sep '03

Hi, Not sure if it's appropriate to post py2exe questions here, so my first question is: is it OK? If not, is there a place where I can post py2exe questions? The py2exe question: When I run: python setup.py py2exe with the below setup.py, it just tells me: running py2exe error: Nothing to do The setup.py file: from distutils.core import setup import py2exe setup(name = "csmarter", version = "1.0", description="CSMARTer Society Editing Tool for Cougaar", author=<some names>, author_email=<an email addr>, url="http://www.cougaar.org", packages = ["csmarter", "csmarter.CSMARTer", "csmarter.ACMEPy"], data_files=[<some files>] ) This setup.py works great when I just run distutils on it. But when I run py2exe, I get the msg shown above. Something to note: the distribution root (where setup.py is located) contains no Python scripts (other than setup.py), but it does contain a subdirectory ("csmarter") which is a Python package (i.e., it has an __init__.py). This csmarter package contains no Python scripts itself (other than the __init__.py), but only two subdirectories/subpackages (CSMARTer and ACMEPy) which contain all the .py files. Is py2exe telling me there's nothing to do because there are no Python scripts in the distribution root or is there some other reason? Thanks. Paul Gardella

2 2

Customizing for MinGW
by andreas.held＠smi-grp.com 23 Sep '03

23 Sep '03

Hi I am distributing an extension that can be built either using MinGW or MSVC on Windows. However, the extension must link against some additional libraries, whose name change depending on the compiler that was used to build them. For instance, using MSVC I have # module declarations module1 = Extension('_MyModule', libraries=ExtLib_One) and for MinGW I have # module declarations module1 = Extension('_MyModule', libraries=ExtLibOne) Unfortunately, I do not have any influence on the naming of those libraries and I wondered whether I can customize distutils to account for this. Basically, what I want is the follwoing if sys.platform=='win32': if compiler=='mingw32': libnames= ExtLibOne else: libnames=ExtLib_One How can I obtain the information on what compiler the script was invoked with, e.g. I would need the value of the command line switch '--compiler'? Can this be done at all? Thanks for your help Regards Andreas Held pyfltk.sourceforge.net

1 0

new Sexual attractant jqnyqyywchayyla
by Kip Waters 22 Sep '03

22 Sep '03

1 0

Attempt at writing bdist_dpkg
by amk＠amk.ca 22 Sep '03

22 Sep '03

I've found myself making a lot of Debian packages for various Python modules, so I've started working on a bdist_dpkg.py module for Distutils. Currently it's in nondist/sandbox/Lib/ in the Python CVS; you can download a copy from http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/nondist/sandbo… . When you run it, it creates a debian/ subdirectory containing a dummy changelog and default versions of control and rules. prerm and postinst are also created to compile .py files to .pyc and to remove them. Generated debian/ files contain a special marker and only files containing this marker will be overwritten, so if you have a custom rules or preinst file it won't be stomped on. Issues: * I can't figure out a way to put the marker in the 'control' and 'changelog' files, because their formats don't seem to support comments. * Right now the .deb for a packaged "foo" is named "foo"; it should be pythonX.Y-foo or whatever the Debian convention is. * The bdist_dpkg command needs to grow many options (e.g. setting the package name, using a particular file as the change log, etc.) Suggestions are welcome. If you have CVS access, feel free to modify the code and check in your changes. --amk

1 0

distutils extension commands and option passing
by Stefan Seefeld 20 Sep '03

20 Sep '03

hi there, one of the things I like most about distutils is the compositional approach to the build system, i.e. commands such as 'bdist' being defined independently of 'build', so as soon as I have a working 'build' command, 'bdist' (and its variants) will work out-of-the-box most of the time. However, I'v now run into an issue with this very approach, and I wonder how to deal with that: As the 'build_ext' command shipped with distutils isn't powerful enough for my extensions, I'v written one myself. It's basically a wrapper around a call to 'make -C ...'. That is accompagnied by a 'config' command, doing, what else, a 'configure' call... I'v added various options to the config command to be able to enable/disable the various extensions that can be supported. But there doesn't seem to be a way to call 'python setup.py bdist_rpm' (say) and somehow pass options that are really meant for the config command, or is there ? That means I have to write my 'config' command such that the default is the desired configuration for the rpm. Right ? Any tips are highly appreciated, Stefan

2 2