Distutils-SIG June 2001

distutils-sig@python.org

15 participants
17 discussions

by Gaspard, Bradley S

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

20 years, 3 months

Distutils patches for Python OS/2 port

by Andrew MacIntyre

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!" <----------------------------------

20 years, 3 months

Re: Dependencies as feature for PEP Python software catalog entries

by Pete Shinners

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?

20 years, 4 months

Problem with build_rpm

by Juergen Hermann

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/

20 years, 4 months

Checking distutils features

by Juergen Hermann

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

20 years, 4 months

suggestions for mod_python

by Gregory (Grisha) Trubetskoy

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

20 years, 4 months

Cygwin Python sys.platform and distutils.util.get_platform() patch

by Jason Tishler

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

20 years, 4 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG June 2001