I am a new distutils user. Can anyone tell me if the SWIG support is
actually working and is there a way that it can support the -shadow option??
I am getting compile errors under distutils that I don't normally get (for
an extention where I don't use the shadow option). Examples of setup.py
scripts would be appreciated.
SWIG1.1-883
Python 2.0
Thanks in advance.
Brad
Once Python 2.1.1 is released, and I've updated the OS/2+EMX port, I
plan to submit the diffs for the port to the Python patch manager.
I'd appreciate advice on whether to include the DistUtils patches as
part of a complete Python port patch, or submit them separately. If
the latter, pointers on submission also appreciated.
For info:
The only significant change to the DistUtils involves adding
emxccompiler.py, which is derived from cygwinccompiler.py (IIRC - I'm
not close to the sources right now). It is possible the EMX changes
could be merged back into the original, as the changes aren't too
drastic.
There are other changes to various files of course, to add platform
specifics - ccompiler.py, spawn.py, sysconfig.py, util.py,
command/bdist_dumb.py and command/build_ext.py come to mind.
-----------------------------------------------------------------------
Andrew MacIntyre \ E-mail: andrew.macintyre(a)aba.gov.au
Planning & Licensing Branch \ Tel: +61 2 6256 2812
Australian Broadcasting Authority \ Fax: +61 2 6253 3277
-> "These thoughts are mine alone!" <----------------------------------
note, this was a letter sent to me and a few others "off-list"
i thought i'd send my reply to this mail list also...
From: <cognite(a)zianet.com>
> First, Thanks for your work on the python packages collection!
>
> SUGGEST: adding a Dependencies section to the tags of a
> Python software catalog
>
> The dependencies of a package are needed a priori. They are
> not mentioned in the Catalog-SIG PEP. Dependencies are tied
> to versions, of course. Size of the total and its pieces would
> help, too. A partial example, sort of like the ones in the
> posted PEP at python.org , exemplifies.
>
> EXAMPLE:
> The Facts found in this case:
> Dependencies of pyUI include not only pygame but also SDL.
> The licenses are not the same.
>
> Thus notes on installing it included the DOWNLOAD LOCATIONS
> (not shown; elsewhere in the catalog entry, presumably) and
> "ORDERED RULES" of the package's footing in code and licenses.
> Putting that together took considerable study time for info
> that the package's author could have readily provided in a
> catalog entry, as it was part of the package's basic design.
> Not that these notes are ideally complete, but they were
> necessary to get things straight enough to get the package up.
> So they provide an example of some of the background info that
> would make a catalog entry useful.
>
> ==============
> ..\GUIs\pyUI\pygame\pygame-1.0>less pygame-testing.nb
> ------------- pyUI NOTES
> SC 5June2001
>
> pyUI may be easy as claimed, and look slick,
> but it has dependencies
> on GUI manager pygame and GUI runtime environment SDL (Simple
> DirectMedia Layer). SDL is GNU; there are
> windows binaries. pygame is LGPL.
>
>
> ------------- pygame NOTES
>
> sophisticated setup.py and preparatory/fallback config.
> Sorts type of files by suffix, puts into resp. dirs.
> Gathers dlls on Windows, compiles C components,
> links to Numeric python if available. Python >=2.0.
>
> (1) put python >=2.0
> add NumPy/Numeric if desired; ...
>
> (2) put SDL via
> put SDL.dll 217k from binary SDL-1.2.0-win32.zip 91k into path
> (tgz 1343k)
>
> (3) put pygame via
> pygameDir/> python setup.py install
>
> =========
great idea, but tricky to implement...
* in your example, pyui does not directly make use of SDL.
so why should it be listed in the pyui dependencies?
shouldn't the only dependency be "pygame". and then pygame
has its own list of dependencies? what if the dependencies
for pygame change? this would mean you'd have to go and
change the dependencies for pyui also, that doesn't seem
quite right.
* does distutils check for the dependencies itself and report
any unfound ones? this isn't too bad for other python projects
that have been installed with distutils (since we can control
the environment), but what about non-python dependencies. should
the distutils package provide its own code for detecting the
dependencies? that might be best, it's the most flexible. i've
seen distutils already has a bunch of "autoconfig" type functions
which allow it to compile small test programs and return the
results.
* of course, it would be nice if this was tied into the python
catalog PEP, so dependencies could be easily found? perhaps we
also allow non-python dependencies to live in the online catalog
too? as long as their license allows redistribution and whatnot?
unfortunately they all have potentially varied compile steps.
for example, i just looked at freetype2 (an optional pygame
dependency) and it is not the standard "configure;make" routine.
* one other problem is supporting multiple versions of the same
python package. in fact versioning alltogether might be tricky.
what if one package says it needs Numeric v20 and another needs
Numeric v18. just about all python packages i've seen install to
the same directory. there is no support for both versions.
this could potentially cause the most trouble. the best solution
might be to change python and distutils a bit. distutils installs
into versioned directory names. it then installs some sort of
special .PTH file which python uses to determine the "default"
version for that library. then we change the import command
(or maybe sys too?) to specify needed version numbers for a
python package. something like "import Numeric[20.1]" or setting
something in sys, like "sys.versioninfo['Numeric'] = 20.1".
then when doing "import Numeric" python would check the
sys.versioninfo and import Numeric from the correct directory.
as for the install directories, perhaps distutils would create
the versioned package names using some sort of invalid python
namevalue character to separate the package name and installed
version, "Numeric-20.1".
owell, there's the initial problems and potential solutions that
come to my head. its not all an easy thing to fix, but the more
solutions python provides for these problems, the better off we
may be?
Hi!
I tried build_rpm today and failed, because of this:
+ cd /home/jhe/src/python/extensions/cin/build/bdist.linux-i686/rpm/BUILD
+ cd cin-1.3
+ env 'CFLAGS=-O2 -m486 -fno-strength-reduce' python setup.py build
Traceback (innermost last):
File "setup.py", line 14, in ?
from distutils.core import setup, Extension
ImportError: No module named distutils.core
Bad exit status from /var/tmp/rpm-tmp.49462 (%build)
error: command 'rpm' failed with exit status 1
The problem here is that "python" is Python 1.5, and setup.py has a "#!
/usr/bin/env python2.1" bangpath, i.e. the call in the "+ env" line should
use "sys.executable", not a fixed "python" string.
Ciao, Jürgen
--
Jürgen Hermann, Developer (jhe(a)webde-ag.de)
WEB.DE AG, http://webde-ag.de/
Hi!
I needed this in my setup.py to support distutils 1.0.1:
if hasattr(distutils.dist.DistributionMetadata, 'get_keywords'):
setup_args['keywords'] = "wiki web"
if hasattr(distutils.dist.DistributionMetadata, 'get_platforms'):
setup_args['platforms'] = "win32 posix"
apply(setup, (), setup_args)
Is there a more official way?
Ciao, Jürgen
Sorry, I'm a newbie to distutils and the sig, I need some advice.
I am trying to adopt mod_python to distutils. Here is my dilemma:
The end result of the mod_python compile is usually a file called
mod_python.so. Mod_python.so is NOT a Python module, it's an Apache
module. (There is also a Python package to go along with it, but that's
irrelevant here I think).
Currently, at ./configure time I peek in Modules/Makefile to find out the
libs against which Python was linked (which breaks in python 2.1, btw).
The actual mod_python.so is built using apxs. Apxs is a tool that comes
with Apache to build Apache modules. It knows what compile/linker args the
module will need as far as Apache is concerned, and it takes all necessary
libs for Python as an argument via a Makefile built by autoconf.
I'm thinking that the right way to go is use some fucntionality of
distutils that can just list me the necessay libs during ./configure and
stick with useing apxs, since the end result isn't a Python but an Apache
module... So far I haven't been able to figure out how to get that info
(but then I've only spent a day looking at distutils...)
Any advice/suggestions would be very much appreciated,
Grisha
I would like to submit the attached patch (i.e., the first attachment)
to Python CVS for inclusion in 2.2. IMO, this is the right solution for
many reasons. I have included one example as the the second attachment.
If the patch is accepted, then I will back patch and re-release my Cygwin
Python 2.1 distribution.
Since these two simple changes have possibly far reaching ramifications,
I thought that it would be prudent to solicit feedback before submitting
the patch. My goal is to eliminate (or at least minimize) the heartache
caused by these changes, if any.
Note that the two parts of the patch are actually independent but
related so I have decided to submit them as one patch instead of two.
The first part changes sys.platform, sys.path, and the platform specific
module directory name as follows:
$ # before patch
$ python -c 'import sys; print sys.platform'
cygwin_nt-4.01
$ python -c 'import sys; print sys.path'
[..., '/usr/lib/python2.1/plat-cygwin_nt-4.01', ...]
$ find /usr/lib/python2.1 -name '*cygwin*' -type d
/usr/lib/python2.1/plat-cygwin_nt-4.01
$ # after patch
$ python -c 'import sys; print sys.platform'
cygwin
$ python -c 'import sys; print sys.path'
[..., '/usr/lib/python2.1/plat-cygwin', ...]
$ find /usr/lib/python2.1 -name '*cygwin*' -type d
/usr/lib/python2.1/plat-cygwin
The second part changes sys.path (only when Python is run out of the
build tree) and the directory names used by distutils when building
extension modules:
$ # before patch
$ python -c 'import sys; print sys.path'
[..., '/home/jt/src/Python-2.1/build/lib.cygwin_nt-4.0-1.3.2-i686-2.1']
$ find . -name '*cygwin*'
./build/lib.cygwin_nt-4.0-1.3.0-i686-2.1
./build/temp.cygwin_nt-4.0-1.3.0-i686-2.1
$ # after patch
$ python -c 'import sys; print sys.path'
[..., '/home/jt/src/Python-2.1/build/lib.cygwin-1.3.2-i686-2.1']
$ find . -name '*cygwin*'
./build/lib.cygwin-1.3.2-i686-2.2
./build/temp.cygwin-1.3.2-i686-2.2
If I don't receive any negative responses to this patch proposal by
2001/6/1 9:00 EDT, then I will submit this patch to the SourceForge
Python Patch Manager.
Thanks,
Jason
--
Jason Tishler
Director, Software Engineering Phone: 732.264.8770 x235
Dot Hill Systems Corp. Fax: 732.264.8798
82 Bethany Road, Suite 7 Email: Jason.Tishler(a)dothill.com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com