From thomas.heller@ion-tof.com Thu Jun 7 15:15:01 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Jun 7 14:15:01 2001 Subject: [Distutils] some installer grumbles References: <5.1.0.14.1.20010531083657.00ac4e98@laplaza.org> Message-ID: <111501c0ef7d$e1465fd0$e000a8c0@thomasnotebook> Sorry for the late reply, but I've been very busy... > This is the result of operator error, but nonetheless... > I accidentally launched an install of PyXML on a w2k system where > it was already installed. I know the instructions say to remove > old installations first (actually it wasn't an "old" installation, > it was the same version, to be really nitpicky) as I said, > Operator Error. However, at this point: > > (a) the existing installation is not detected with a > bailout option ("blah blah already installed blah blah > do you want to continue?") This should probably wait until there is a distutils registry of installed modules. > > (b) there's no way to abort the installation once it starts > (no cancel button) > I've hesitated to add this because an installation cancelled in the middle of file-copying would certainly leave the system in a not very useful state. > (c) you are prompted for EACH file as to whether to > replace or not; there is no "yes to all" (or "no to all") so one > would potentially have to click "yes" or "no" hundreds of > times to complete for something like PyXML. You could press the 'N' or 'Y' button and leave it pressed, so this would not take forever ;-) Seriously: I should add this. My excuse: The yes/no to all is asked once just before the start of the installation. Thomas From mats@laplaza.org Thu Jun 7 16:05:00 2001 From: mats@laplaza.org (Mats Wichmann) Date: Thu Jun 7 15:05:00 2001 Subject: [Distutils] some installer grumbles In-Reply-To: <111501c0ef7d$e1465fd0$e000a8c0@thomasnotebook> References: <5.1.0.14.1.20010531083657.00ac4e98@laplaza.org> Message-ID: <5.1.0.14.1.20010607121921.00a938d8@laplaza.org> Thanks for the comments! >> (a) the existing installation is not detected with a >> bailout option ("blah blah already installed blah blah >> do you want to continue?") >This should probably wait until there is a distutils registry >of installed modules. Is this in the works? >> (c) you are prompted for EACH file as to whether to >> replace or not; there is no "yes to all" (or "no to all") so one >> would potentially have to click "yes" or "no" hundreds of >> times to complete for something like PyXML. >Seriously: I should add this. My excuse: The yes/no to all >is asked once just before the start of the installation. Yes, I retried my "operator error" intentionally later just to confirm, and this time I noticed that initial box. I /think/ the problem was at that point I didn't yet know I was in trouble.... it was already a while ago so I don't remember that clearly. Mats From thomas.heller@ion-tof.com Thu Jun 7 16:24:01 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Jun 7 15:24:01 2001 Subject: [Distutils] some installer grumbles References: <5.1.0.14.1.20010531083657.00ac4e98@laplaza.org> <5.1.0.14.1.20010607121921.00a938d8@laplaza.org> Message-ID: <127001c0ef87$7186b190$e000a8c0@thomasnotebook> > > >> (a) the existing installation is not detected with a > >> bailout option ("blah blah already installed blah blah > >> do you want to continue?") > >This should probably wait until there is a distutils registry > >of installed modules. > > Is this in the works? No, I'm not aware of any activity. However, it's on the todo list. Here is a comment from a message 'Tasks arising from IPC9' by Andrew Kuchling, dated 3/10/2001: 3) Other Distutils changes would be to design and create a package database, and implement an uninstall command. The 'sdist' command would also grow an --upload or --register option that would automatically submit the package to the catalog (but first we'd need to finalize how that should be done). IIRC, Andrew said this would probably require a PEP. Thomas From grisha@modpython.org Fri Jun 8 18:59:01 2001 From: grisha@modpython.org (Gregory (Grisha) Trubetskoy) Date: Fri Jun 8 17:59:01 2001 Subject: [Distutils] suggestions for mod_python Message-ID: 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 From mats@laplaza.org Fri Jun 8 19:16:14 2001 From: mats@laplaza.org (Mats Wichmann) Date: Fri Jun 8 18:16:14 2001 Subject: [Distutils] Package database, uninstall, etc. In-Reply-To: <127001c0ef87$7186b190$e000a8c0@thomasnotebook> References: <5.1.0.14.1.20010531083657.00ac4e98@laplaza.org> <5.1.0.14.1.20010607121921.00a938d8@laplaza.org> Message-ID: <5.1.0.14.1.20010608154059.00b18168@laplaza.org> Prior discussion has roughly been: My gripe: the fact that a package is already installed is not detected with a warning. Thomas Heller: This should probably wait until there is a distutils registry of installed modules. Me: Is this in the works? Thomas: No, I'm not aware of any activity. He goes on to say folks (well, AMK) know it's needed, and probably requires a PEP. Should we get that ball rolling? In the most general terms, it appears that PEP 241 formally, plus just "how distutils works", describes one of the software collection types we're interested in: the distribution (although PEP 241 itself appears to describe only one component of the distribution, the metadata, or what other terminology calls a "Software Definition File"). The other type we need, to implement things like removal, show installed packages, detection of previous install of same or different version, track dependencies (gack...no... not RPM!!!), etc., is an "installed software" collection. I'd propose that's an appropriate subject for a PEP. I don't have any idea how much or how little of this is considered "necessary" (as opposed to "might be nice"). (I can volunteer to carry the ball if necessary, but I'm sure I'm nowhere near the best qualified person). Mats From slash@dotnetslash.net Fri Jun 8 20:56:16 2001 From: slash@dotnetslash.net (Mark W. Alexander) Date: Fri Jun 8 19:56:16 2001 Subject: [Distutils] Package database, uninstall, etc. In-Reply-To: <5.1.0.14.1.20010608154059.00b18168@laplaza.org> Message-ID: I thought the major point of supporting the creation of "native" binary packages was so that installation and dependencoes could be handled however the local architecure handles it. Doing "python setup.py install" is no different that "./configure && make install". Neither one is going to look to see if anything's already there. "python setup.py bdist_whatever", however will create a nice, neat little package. With the full implementation of PEP241 standards, (esp. standard names and versions) the package manager will know if a package is already installed, and _it_ will do appropriate warnings, allow for "forcing", deal with multiple version installs, ... , all the things that package managers do. If all this stuff is packed into distutils, then administrators will have to look in multiple places to figure out what is installed on which machine. I see distutils as a distribution tool, not an administration tool. Like it or not, different platforms come with different administration tools, and no matter how good open general-purpose replacements are, they're a pain to keep in sync with the one the vendor uses. mwa On Fri, 8 Jun 2001, Mats Wichmann wrote: > Prior discussion has roughly been: > > My gripe: the fact that a package is already installed is not > detected with a warning. > > Thomas Heller: This should probably wait until there is a > distutils registry of installed modules. > > Me: Is this in the works? > > Thomas: No, I'm not aware of any activity. > > He goes on to say folks (well, AMK) know it's needed, and > probably requires a PEP. > > > Should we get that ball rolling? In the most general terms, > it appears that PEP 241 formally, plus just "how distutils > works", describes one of the software collection types we're > interested in: the distribution (although PEP 241 itself > appears to describe only one component of the distribution, > the metadata, or what other terminology calls a "Software > Definition File"). > > The other type we need, to implement things like removal, > show installed packages, detection of previous install of > same or different version, track dependencies (gack...no... > not RPM!!!), etc., is an "installed software" collection. > > I'd propose that's an appropriate subject for a PEP. > I don't have any idea how much or how little of this > is considered "necessary" (as opposed to "might be nice"). > > (I can volunteer to carry the ball if necessary, but I'm > sure I'm nowhere near the best qualified person). > > Mats > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig > -- Mark W. Alexander slash@dotnetslash.net From slash@dotnetslash.net Fri Jun 8 21:00:01 2001 From: slash@dotnetslash.net (Mark W. Alexander) Date: Fri Jun 8 20:00:01 2001 Subject: [Distutils] suggestions for mod_python In-Reply-To: Message-ID: It sounds to me like you'd be better off using both: apxs for the apache module and distutils for the python module. Forcing either one to do what the other already does is likely to be uncomfortable. mwa On Fri, 8 Jun 2001, Gregory (Grisha) Trubetskoy wrote: > > 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 > > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig > -- Mark W. Alexander slash@dotnetslash.net From grisha@modpython.org Fri Jun 8 21:10:02 2001 From: grisha@modpython.org (Gregory (Grisha) Trubetskoy) Date: Fri Jun 8 20:10:02 2001 Subject: [Distutils] suggestions for mod_python In-Reply-To: Message-ID: The trick though is that mod_python.so at the same time needs to have all Python info as well, because even though it gets loaded by apache, it also has Python module functionality in it.... I guess the real question is: Do distutils provide a uniform way of retreiving compile-time arguments, or is going through /usr/local/lib/python2.1/config/Makefile (or whatever) still the way to go with Python 2.1? Grisha On Fri, 8 Jun 2001, Mark W. Alexander wrote: > It sounds to me like you'd be better off using both: apxs for the apache > module and distutils for the python module. Forcing either one to do > what the other already does is likely to be uncomfortable. > > mwa > > On Fri, 8 Jun 2001, Gregory (Grisha) Trubetskoy wrote: > > > > > 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 > > > > > > > > _______________________________________________ > > Distutils-SIG maillist - Distutils-SIG@python.org > > http://mail.python.org/mailman/listinfo/distutils-sig > > > > -- > Mark W. Alexander > slash@dotnetslash.net > From 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'] =3D "wiki web" if hasattr(distutils.dist.DistributionMetadata, 'get_platforms'): setup_args['platforms'] =3D "win32 posix" apply(setup, (), setup_args) Is there a more official way? Ciao, J=FCrgen From mal@lemburg.com Mon Jun 11 07:42:00 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Jun 11 06:42:00 2001 Subject: [Distutils] Checking distutils features References: Message-ID: <3B24A033.8AA40F85@lemburg.com> Juergen Hermann wrote: > > 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? I don't think so... you will have to override the DistributionMetadata class inplace, that is before even running setup(). Changes to the compiler classes require the same procedure. I think we ought to make distutils more customizable in this respect too, e.g. by providing a generic class lookup dictionary (much ilke the cmdclass dict) in the setup() call as keyword parameter which then allows overriding compiler classes and other classes for which there is no general hook. Another thing which I stumbled across is that there seems to be no way to define the order of calling the various commands, e.g. to insert a new command into the general flow of execution. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From 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/BUIL= D + cd cin-1.3 + env 'CFLAGS=3D-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 shou= ld use "sys.executable", not a fixed "python" string. Ciao, J=FCrgen -- J=FCrgen Hermann, Developer (jhe@webde-ag.de) WEB.DE AG, http://webde-ag.de/ From R.Liebscher@gmx.de Wed Jun 13 10:54:02 2001 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Wed Jun 13 09:54:02 2001 Subject: [Distutils] Problem with build_rpm References: Message-ID: <3B277019.B756F3E3@gmx.de> Juergen Hermann wrote: > > 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. The bangpath is ignored when you write "python setup.py ...". Distutils is included in python 1.6 or later. For python 1.5 you can download it at http://www.python.org/sigs/distutils-sig/download.html Kind regards Rene Liebscher From mal@lemburg.com Wed Jun 13 11:53:00 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Jun 13 10:53:00 2001 Subject: [Distutils] Problem with build_rpm References: Message-ID: <3B277E0A.C14DE5C9@lemburg.com> Juergen Hermann wrote: > > 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. > This helps: # Python version to use PYTHONVERSION = 2.0 PYTHON = python$(PYTHONVERSION) $(PYTHON) setup.py bdist_rpm --python $(PYTHON) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From Juergen Hermann" Message-ID: On Wed, 13 Jun 2001 15:52:25 +0200, Rene Liebscher wrote: >The bangpath is ignored when you write "python setup.py ...". Well, I did not write that, and if I wrote "python2.1 setup.py" it'd still fail. Ciao, J=FCrgen From akuchlin@mems-exchange.org Wed Jun 13 15:15:00 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed Jun 13 14:15:00 2001 Subject: [Distutils] Problem with build_rpm In-Reply-To: ; from jh@web.de on Wed, Jun 13, 2001 at 03:36:40PM +0200 References: Message-ID: <20010613141338.A26397@ute.cnri.reston.va.us> On Wed, Jun 13, 2001 at 03:36:40PM +0200, Juergen Hermann wrote: >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. It should do this if you specify the --fix-python option. See the code in Lib/distutils/commands/bdist_rpm.py for details. --amk From shredwheat@mediaone.net Tue Jun 19 12:45:13 2001 From: shredwheat@mediaone.net (Pete Shinners) Date: Tue Jun 19 11:45:13 2001 Subject: [Distutils] Re: Dependencies as feature for PEP Python software catalog entries Message-ID: <003601c0f8d6$ba368980$0200a8c0@petebox> 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: > 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? From Andrew.MacIntyre@aba.gov.au Wed Jun 20 00:58:00 2001 From: Andrew.MacIntyre@aba.gov.au (Andrew MacIntyre) Date: Tue Jun 19 23:58:00 2001 Subject: [Distutils] Distutils patches for Python OS/2 port Message-ID: 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@aba.gov.au Planning & Licensing Branch \ Tel: +61 2 6256 2812 Australian Broadcasting Authority \ Fax: +61 2 6253 3277 -> "These thoughts are mine alone!" <---------------------------------- From fdrake@acm.org Wed Jun 20 01:07:00 2001 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed Jun 20 00:07:00 2001 Subject: [Distutils] Distutils patches for Python OS/2 port In-Reply-To: References: Message-ID: <15152.8443.147783.664019@cj42289-a.reston1.va.home.com> Andrew MacIntyre writes: > 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. Why wait? > 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. It's probably best to submit this as a separate patch. Distutils has a separate patch category on the SourceForge patch manager, and it will probably be reviewed by a different person. Keeping each individual patch small actually makes it easier to review and incorporate patches. -Fred -- Fred L. Drake, Jr. PythonLabs at Digital Creations From phrxy@csv.warwick.ac.uk Fri Jun 22 23:19:00 2001 From: phrxy@csv.warwick.ac.uk (John J. Lee) Date: Fri Jun 22 22:19:00 2001 Subject: [Distutils] SWIG Support In-Reply-To: Message-ID: On Wed, 30 May 2001, Gaspard, Bradley S wrote: > 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. Seeing as nobody more knowledgeable has answered your question -- SWIG support does work, for minimal stuff I've tried, at least. You may get some warnings about the SWIG-generated code, because distutils turns them on. Ignore them. I don't know if it knows about shadow classes yet. example: import distutils from distutils.core import setup, Extension setup(name="foo", version="0.1", packages=[...], ext_modules=[Extension("foo.bar", ["uri/to/barmodule.c", "uri/to/bar.i"])] ) HTH John From phrxy@csv.warwick.ac.uk Fri Jun 22 23:26:01 2001 From: phrxy@csv.warwick.ac.uk (John J. Lee) Date: Fri Jun 22 22:26:01 2001 Subject: [Distutils] 'Other' languages (than C) Message-ID: Has it been decided where the best place is in distutils to put support for non-C languages (FORTRAN is my particular wish)? John From t.sargeant@inpharmatica.co.uk Tue Jun 26 07:11:01 2001 From: t.sargeant@inpharmatica.co.uk (Toby Sargeant) Date: Tue Jun 26 06:11:01 2001 Subject: [Distutils] a couple of distutils questions Message-ID: <20010626110954.C10899@inpharmatica.co.uk> This is my first use of the distutils package, so I accept that I might have gone about things the wrong way. Initially for my freetype 2 extension module, I used autoconf to build a Setup.in file for building the module. I decided to switch to using distutils recently, and in doing so wanted to still be able to provide the --freetype-path and --with-pil-headers options to deal with different install locations for freetype and PIL. After a lot of poking around and many false starts, it seemed that there wasn't a good way to handle command line arguments that didn't involve extensive poking around in internal distutils objects. Eventually I gave up and just used the following code: handle={ '--freetype-path=' : optFreetypePath, '--with-pil-headers=' : optPilHeaders } arg=1 while arg Hi! Did anyone invest any work into libtool support, i.e. linking of libtool (.la) libraries? Would there be interest in such a thing? Ciao, J=FCrgen -- J=FCrgen Hermann, Developer (jhe@webde-ag.de) WEB.DE AG, http://webde-ag.de/ From trace@reinventnow.com Thu Jun 28 20:05:00 2001 From: trace@reinventnow.com (tracy s. ruggles) Date: Thu Jun 28 19:05:00 2001 Subject: [Distutils] Trouble installing on a VPS (a shared web hosting setup) In-Reply-To: Message-ID: Hi, I've been troubling myself with trying to install MySQLdb on my VPS (a shared web hosting setup). I have my own copy of Python running out of my /usr/local directory. I have had to edit Lib/distutils/sysconfig.py to have it return the appropriate include and library directories. It assumes a certain structure of directories from the root directory. But, my root directory is actually /usr/home/ol0401 Anyway, here's what I get when I try to run the MySQLdb setup.py script: .. ol0401.vwh.net% python setup.py build running build running build_py not copying CompatMysqldb.py (output up-to-date) not copying _mysql_exceptions.py (output up-to-date) not copying MySQLdb/__init__.py (output up-to-date) not copying MySQLdb/converters.py (output up-to-date) not copying MySQLdb/connections.py (output up-to-date) not copying MySQLdb/cursors.py (output up-to-date) not copying MySQLdb/sets.py (output up-to-date) not copying MySQLdb/times.py (output up-to-date) not copying MySQLdb/constants/__init__.py (output up-to-date) not copying MySQLdb/constants/CR.py (output up-to-date) not copying MySQLdb/constants/FIELD_TYPE.py (output up-to-date) not copying MySQLdb/constants/ER.py (output up-to-date) not copying MySQLdb/constants/FLAG.py (output up-to-date) not copying MySQLdb/constants/REFRESH.py (output up-to-date) not copying MySQLdb/constants/CLIENT.py (output up-to-date) running build_ext building '_mysql' extension skipping _mysql.c (build/temp.solaris-2.6-sun4u-2.1/_mysql.o up-to-date) gcc -shared build/temp.solaris-2.6-sun4u-2.1/_mysql.o /usr/home/ol0401/usr/local/mysql-3.23.38/lib/mysql/libmysqlclient.a -L/usr/home/ol0401/usr/local/mysql-3.23.38/lib/mysql -R/usr/home/ol0401/usr/local/mysql-3.23.38/lib/mysql -lmysqlclient -lz -o build/lib.solaris-2.6-sun4u-2.1/_mysql.so /usr/local/sparc-sun-solaris2.6/bin/ld: cannot open -lz: No such file or directory collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 ol0401.vwh.net% .. As you can see, it successfully builds many of the files, but chokes when it starts to build the _mysql extension. I've verified that all of the files listed in that last "gcc" command actually exist, except for the _mysql.so file. I'm totally unfamiliar with gcc and building in general. Does anyone know what's going on here? And, also, is there a way to get the distutils package to work when it's being run in an environment where the user is in a shared web hosting environment? Thanks, Tracy -- Tracy S. Ruggles :: trace@reinventnow.com :: 512/858.2280 "RHUBARB. / Rhubarb is susan not susan not seat in bunch toys not wild and laughable not in little places not in neglect and vegetable not in fold coal age not please." -- Gertrude Stein From goodmansond@hotmail.com Fri Jun 29 18:53:01 2001 From: goodmansond@hotmail.com (Dean Goodmanson) Date: Fri Jun 29 17:53:01 2001 Subject: [Distutils] Re: Distutils-SIG digest, Vol 1 #542 - 1 msg Message-ID: >From: distutils-sig-request@python.org >Reply-To: distutils-sig@python.org >To: distutils-sig@python.org >Subject: Distutils-SIG digest, Vol 1 #542 - 1 msg >Date: Fri, 29 Jun 2001 12:01:03 -0400 > >Send Distutils-SIG mailing list submissions to > distutils-sig@python.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/distutils-sig >or, via email, send a message with subject or body 'help' to > distutils-sig-request@python.org > >You can reach the person managing the list at > distutils-sig-admin@python.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Distutils-SIG digest..." > > >Today's Topics: > > 1. Trouble installing on a VPS (a shared web hosting setup) (tracy s. >ruggles) > >--__--__-- > >Message: 1 >Date: Thu, 28 Jun 2001 18:05:38 -0500 >From: "tracy s. ruggles" >To: >Subject: [Distutils] Trouble installing on a VPS (a shared web hosting >setup) > >Hi, > >I've been troubling myself with trying to install MySQLdb on my VPS (a >shared web hosting setup). > >I have my own copy of Python running out of my /usr/local directory. > >I have had to edit Lib/distutils/sysconfig.py to have it return the >appropriate include and library directories. It assumes a certain >structure >of directories from the root directory. But, my root directory is actually >/usr/home/ol0401 > >Anyway, here's what I get when I try to run the MySQLdb setup.py script: > >.. > > ol0401.vwh.net% python setup.py build > running build > running build_py > not copying CompatMysqldb.py (output up-to-date) > not copying _mysql_exceptions.py (output up-to-date) > not copying MySQLdb/__init__.py (output up-to-date) > not copying MySQLdb/converters.py (output up-to-date) > not copying MySQLdb/connections.py (output up-to-date) > not copying MySQLdb/cursors.py (output up-to-date) > not copying MySQLdb/sets.py (output up-to-date) > not copying MySQLdb/times.py (output up-to-date) > not copying MySQLdb/constants/__init__.py (output up-to-date) > not copying MySQLdb/constants/CR.py (output up-to-date) > not copying MySQLdb/constants/FIELD_TYPE.py (output up-to-date) > not copying MySQLdb/constants/ER.py (output up-to-date) > not copying MySQLdb/constants/FLAG.py (output up-to-date) > not copying MySQLdb/constants/REFRESH.py (output up-to-date) > not copying MySQLdb/constants/CLIENT.py (output up-to-date) > running build_ext > building '_mysql' extension > skipping _mysql.c (build/temp.solaris-2.6-sun4u-2.1/_mysql.o >up-to-date) > gcc -shared build/temp.solaris-2.6-sun4u-2.1/_mysql.o >/usr/home/ol0401/usr/local/mysql-3.23.38/lib/mysql/libmysqlclient.a >-L/usr/home/ol0401/usr/local/mysql-3.23.38/lib/mysql >-R/usr/home/ol0401/usr/local/mysql-3.23.38/lib/mysql -lmysqlclient -lz -o >build/lib.solaris-2.6-sun4u-2.1/_mysql.so > /usr/local/sparc-sun-solaris2.6/bin/ld: cannot open -lz: No such file >or >directory > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > ol0401.vwh.net% > >.. > >As you can see, it successfully builds many of the files, but chokes when >it >starts to build the _mysql extension. > >I've verified that all of the files listed in that last "gcc" command >actually exist, except for the _mysql.so file. > >I'm totally unfamiliar with gcc and building in general. Does anyone know >what's going on here? > >And, also, is there a way to get the distutils package to work when it's >being run in an environment where the user is in a shared web hosting >environment? > >Thanks, >Tracy > > >-- >Tracy S. Ruggles :: trace@reinventnow.com :: 512/858.2280 > >"RHUBARB. / Rhubarb is susan not susan not seat in bunch toys not wild and >laughable not in little places not in neglect and vegetable not in fold >coal >age not please." -- Gertrude Stein > > > > > >--__--__-- > >_______________________________________________ >Distutils-SIG maillist - Distutils-SIG@python.org >http://mail.python.org/mailman/listinfo/distutils-sig > > >End of Distutils-SIG Digest _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com