Mailman 3 October 2004 - Distutils-SIG

Add RPM-friendly Record Option
by Jeff Pitman 14 Oct '04

14 Oct '04

Hi: I'm new here. I submitted a patch for your kind review that spews out an RPM-consumable list including %dir and %lang attributes. The concept could be expanded further. The patch link is here: http://sourceforge.net/tracker/index.php?func=detail&aid=1035576&group_id=5… I know install.py is probably supposed to be RPM-agnostic, but I saw this as the easiest solution. The --record option is still in-tact with a minor aesthetic improvement of using a list comprehension. Critic away! take care, -- -jeff

4 6

Windows .lib files for Python extensions
by Todd Miller 13 Oct '04

13 Oct '04

I have a numarray user who is trying to link his application (on windows) to one of the numarray DLL's and he says he needs a .lib file to do it. I accidentally found a bizarre approach to building a .lib with the right name: build with Python-2.4 and VC.NET followed by build with Python-2.3 and VC6.0. This produces 2.4 and 2.3 versions of libnumarray.lib. I didn't add anything to my setup to generate anything other than Python extensions. My dim recollection of "windows stuff" is that libnumarray.lib would probably contain "DLL stubs" to permit quasi-static linking to libnumarray.pyd. Is this the case or is it just a static library? Is something new going on in the distutils for Python-2.4 which leaves behind an artifact which would affect a Python-2.3 build? Is there a standard approach to producing .lib files for Python-2.3? Regards, Todd

1 0

patch for more SWIG support
by Andi Vajda 13 Oct '04

13 Oct '04

The distutils documentation about using it with SWIG says that support is rough around the edges. (see http://www.python.org/doc/current/dist/setup-script.html, section 3.3.2) The attached patch tries to unroughen things a little. I needed support for two things: . specifying more swig options than just '-c++' . specifying the path to the swig executable The attached patch to build_ext.py replaces the --swig-cpp option with: . --swig-opts=<space separated options passed to swig> . --swig=<path to swig executable> I just subscribed to this list, pardon my ignorance about the process to follow to get this patch accepted and integrated into the sources, what do I need to do next ? Thanks ! Andi.. ps: the attached patch file is relative to the Pythonn 2.3.3 source distribution

5 12

A bit o' help on creating a distribution with MingW32
by Scott David Daniels 12 Oct '04

12 Oct '04

I am having a bit of trouble creating a windows distributable with a C module using MingW32. While I can do: python setup.py build_ext --compile=mingw32 or: python setup.py build --compile=mingw32 I don't know how to do: python setup.py bdist_wininst --compile=mingw32 If I do: python setup.py build --compile=mingw32 python setup.py bdist_wininst --skip-build I get an executable with no tag for the particular python version. The built executable doesn't record the python version at all, so even if I rename whatever-0.4.win32.exe to whatever-0.4.win32-py2.4.exe, it gives me the choice of installing in both python 2.4 and python 2.3 directories. Actually I need to patch config.h before this works, but if I can get the process down, I am sure I can convince somebody to accept my patch to config.in (or whatever). Is there some trick I am missing? -- -- Scott David Daniels Scott.Daniels(a)Acm.Org

3 3

ANN: py2app 0.1.3
by Bob Ippolito 10 Oct '04

10 Oct '04

`py2app`_ is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to `py2exe`_, that builds Mac OS X applications from Python scripts, extensions, and related data files. It tries very hard to include all dependencies it can find so that your application can be distributed standalone, as Mac OS X applications should be. `py2app`_ 0.1.3 is a refactoring and new features release: * ``altgraph``, my fork of Istvan Albert's `graphlib`_, is now part of the distribution * ``py2app.modulegraph`` has been refactored to use ``altgraph`` * `py2app`_ can now create `GraphViz`_ DOT graphs with the ``-g`` option (`TinyTinyEdit example`_) * Moved the filter stack into ``py2app.modulegraph`` * Fixed a bug that may have been in 0.1.2 where explicitly included packages would not be scanned by ``macholib`` * ``py2app.apptemplate`` now contains a stripped down ``site`` module as opposed to a ``sitecustomize`` * Alias builds are now the only ones that contain the system and user ``site-packages`` directory in ``sys.path`` * The ``pydoc`` recipe has been beefed up to also exclude ``BaseHTTPServer``, etc. Known issues: * Commands marked with XXX in the help are not implemented * Includes *all* files from packages, it should be smart enough to strip unused .py/.pyc/.pyo files (to save space, depending on which optimization flag is used) * ``macholib`` should be refactored to use ``altgraph`` * ``py2app.build_app`` and ``py2app.modulegraph`` should be refactored to search for dependencies on a per-application basis Download and related links are here: http://undefined.org/python/#py2app .. _`graphlib`: http://www.personal.psu.edu/staff/i/u/iua1/python/graphlib/html/ .. _`GraphViz`: http://www.research.att.com/sw/tools/graphviz/ .. _`TinyTinyEdit example`: http://undefined.org/~bob/TinyTinyEdit.pdf .. _`py2app`: http://undefined.org/python/#py2app .. _`py2exe`: http://starship.python.net/crew/theller/py2exe/

1 0

ANN: py2app 0.1.2
by Bob Ippolito 08 Oct '04

08 Oct '04

`py2app`_ is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to `py2exe`_, that builds Mac OS X applications from Python scripts, extensions, and related data files. It tries very hard to include all dependencies it can find so that your application can be distributed standalone, as Mac OS X applications should be. `py2app`_ 0.1.2 is primarily a bugfix release: * The encodings package now gets included in the zip file (saves space) * A copy of the Python interpreter is not included anymore in standalone builds (saves space) * The executable bootstrap is now stripped by default (saves a little space) * sys.argv is set correctly now, it used to point to the executable, now it points to the boot script. This should enhance compatibility with some applications. * Adds an "Alias" feature to modulegraph, so that sys.modules craziness such as wxPython.wx -> wx can be accomodated (this particular craziness is also now handled by default) * A sys.path alternative may be passed to find_modules now, though this is not used yet * The Command instance is now passed to recipes instead of the Distribution instance (though no recipes currently use either) * The post-filtering of modules and extensions is now generalized into a stack and can be modified by recipes * A `wxPython`_ example demonstrating how to package `wxGlade`_ has been added * PyRuntimeLocations is now set to (only) the location of the current interpreter's Python.framework for alias and semi-standalone build modes (enhances compatibility with extensions built with an unpatched Makefile with Mac OS X 10.3's Python 2.3.0) Known issues: * Includes *all* files from packages, it should be smart enough to strip unused .py/.pyc/.pyo files (to save space, depending on which optimization flag is used). Download and related links are here: http://undefined.org/python/#py2app .. _`wxGlade`: http://wxglade.sourceforge.net/ .. _`wxPython`: http://www.wxpython.org/ .. _`py2app`: http://undefined.org/python/#py2app .. _`py2exe`: http://starship.python.net/crew/theller/py2exe/

1 0

ANN: py2app 0.1.1
by Bob Ippolito 07 Oct '04

07 Oct '04

`py2app`_ is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to `py2exe`_, that builds Mac OS X applications from Python scripts, extensions, and related data files. It tries very hard to include all dependencies it can find so that your application can be distributed standalone, as Mac OS X applications should be. `py2app`_ 0.1.1 is primarily a bugfix release: * Several problems related to Mac OS X 10.2 compatibility and standalone building have been resolved * Scripts that are not in the same directory as setup.py now work * A new recipe has been added that removes the pydoc -> Tkinter dependency * A recipe has been added for py2app itself * a `wxPython`_ example (superdoodle) has been added. Demonstrates not only how easy it is (finally!) to bundle `wxPython`_ applications, but also how one setup.py can deal with both `py2exe`_ and `py2app`_. * A new experimental tool, py2applet, has been added. Once you've built it (``python setup.py py2app``, of course), you should be able to build simple applications simply by dragging your main script and optionally any packages, data files, Info.plist and icon it needs. Known issues: * Includes *all* files from packages, it should be smart enough to strip unused .py/.pyc/.pyo files (to save space, depending on which optimization flag is used). * The default PyRuntimeLocations can cause problems on machines that have a /Library/Frameworks/Python.framework installed. Workaround is to set a plist that has the following key: ``PyRuntimeLocations=['/System/Library/Frameworks/Python.framework/ Versions/2.3/Python']`` (this will be resolved soon) Download and related links are here: http://undefined.org/python/#py2app .. _`wxPython`: http://www.wxpython.org/ .. _`py2app`: http://undefined.org/python/#py2app .. _`py2exe`: http://starship.python.net/crew/theller/py2exe/

2 4

VIRUS IN YOUR MAIL TO kfioffice
by admin＠www.kfi.ro 07 Oct '04

07 Oct '04

V I R U S A L E R T Our viruschecker found a VIRUS in your email to "kfioffice". We stopped delivery of this email! Now it is on you to check your system for viruses Visit http://www.amavis.org for details on this viruschecker. For your reference, here are the headers from your email: ------------------------- BEGIN HEADERS ----------------------------- Return-Path: <distutils-sig(a)python.org> Received: from kfi.ro (client-2-68-109-203.iqara.net [203.109.68.2] (may be forged)) by www.kfi.ro (8.11.3/8.11.3) with ESMTP id i976Z7p12568 for <kfi(a)kfi.ro>; Thu, 7 Oct 2004 09:35:07 +0300 Message-Id: <200410070635.i976Z7p12568(a)www.kfi.ro> From: distutils-sig(a)python.org To: kfi(a)kfi.ro Subject: Re: Thank you for delivery Date: Thu, 7 Oct 2004 11:43:51 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) -------------------------- END HEADERS ------------------------------

1 0

distutils with swig support
by Christian Dieterich 06 Oct '04

06 Oct '04

Hi, Some of my Python packages that build swigged code need to run swig with include directories and/or with macro definitions. The standard Python distutils does not provide this as an option, so I ended up with two sub-classes of the distutils package that I distribute along with the setup script. I consider it more a hack, but my colleagues keep telling me, I should let you know, so that it might be considered for a future distutils version or that it is at least available to the community. Below is an attachment including an alternative distribution class for distutils that applies the --include-dirs and --define options of the build_ext command not only to the compiler but also to swig. The include_dirs and define_macros keywords in the setup call are considered as well. Usually the Python support file from swig is left unused in the src directory. The alternative distribution class also puts the Python output of swig to the build/lib.machine/package directory, so that it gets installed. Here are a few lines of a setup.py script that uses the alternative distribution class. The two files dist_with_swig.py and build_ext_with_swig.py live in the same directory than setup.py. # import setup tools from distutils.core import setup, Extension # import distribution class with swig support from dist_with_swig import Distribution_with_swig # set up package setup(distclass=Distribution_with_swig, name="my_package", ...) Happy swigging, Christian P.S. I used distutils version 1.0.3 of Python 2.3.3 to sub-class. In the attachment are also the patches for dist.py and build_ext.py.

1 0

addition to distutils documentation
by Faheem Mitha 06 Oct '04

06 Oct '04

Hi, Can you add a mention of the new depends target for distutils to the documentation "Distributing Python Modules ". I think it of general interest. Thanks. See eg. http://docs.python.org/whatsnew/node18.html. Should I file a bug about this? Please reply to the above email address. Faheem.

1 0