From rdatta@crossaccess.com Fri Nov 2 12:10:01 2001 From: rdatta@crossaccess.com (R Datta) Date: Fri Nov 2 12:10:01 2001 Subject: [Distutils] Re: distutils for jython Message-ID: <5.1.0.14.0.20011102090746.038d9bc8@cxamail.crossaccess.com> Try using this javaos.py (http://us.f1.yahoofs.com/users/c014a8c5/bc/Mail+Attachments/javaos.py.py?bcQ0fM8ABL6CG1kG) I have put in two (kludgy) patches: for utime & chmod. They are ugly but at least now setup.py runs to completion. Raj At 06:34 AM 10/31/2001, Dawurske,Jens wrote: >Hi, > >I ran into the same problems described in >http://mail.python.org/pipermail/distutils-sig/2001-October/002613.html . > >Is there already a patch so os.utime is available for jython? I'm using >jython 2.1a3. > >Thanks in advance > >Jens > >Jens Dawurske mailto:JDawurske@ohltec.de >ohltec AG www.ohltec.de >web campus Kiel >Kaistrasse 101 Tel.: 0431-7755 500 >24114 Kiel Fax: 0431-7755 555 Thanks Raj Datta Professional Services Direct : 408-530-4932 CrossAccess Corp Cell : 408-316-5473 2900 Gordon Ave #100 Fax : 408-735-0328 Santa Clara CA 95051 Email : rdatta@crossaccess.com From hinsen@cnrs-orleans.fr Wed Nov 7 06:24:01 2001 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Wed Nov 7 06:24:01 2001 Subject: [Distutils] Installation problem with True64 AFS file system Message-ID: <200111071121.fA7BLmF03633@chinon.cnrs-orleans.fr> An MMTK user sent me a bug report which is in my opinion a distutils problem. Does anyone have an idea what is going on here? As an aside, I'm having problems with the installation of MMTK itself on Alpha/Tru64. I keep getting these: copying MMTK/Database/Groups/aspartic_acid_uni2 -> /afs/bi/v/@sys/languages/python/latest/lib/python2.0/site-packages/MMTK/Database/Groups error: /afs/bi/v/@sys/languages/python/latest/lib/python2.0/site-packages/MMTK/Database/Groups/aspartic_acid_uni2: Not owner The file is copied, but the installation process halts there. I am able to proceed by rerunning the python setup.py install; it notices that that file got there OK, copies the next one, and halts again. As you notice, we have the AFS file system (whose chmod/chown semantics are quite different from regular UNIX). This is not a problem on Linux, HP, SGI or Sun, only on Alpha. Also, it does not matter whether I have my normal account or the administrator account on AFS. What is the installation program trying to do and is it altogether necessary? Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From gherman@darwin.in-berlin.de Fri Nov 9 05:23:00 2001 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Fri Nov 9 05:23:00 2001 Subject: [Distutils] distutils on OS X? Message-ID: <1005301328.3bebae509dc34@webmail.in-berlin.de> Hi, I haven't seen many postings about Darwin and Mac OS X in this group, so let me add one! Has anybody a clue about the official status of distutils on this platform? I'm trying to build the reportlab package, but find that distutils seems to be fully unaware of anything like a 'darwin' platform... On my OS X box I get the following: [localhost:~/Desktop/reportlab/lib] dinu% python Python 2.1 (#4, 05/17/01, 18:34:21) [GCC Apple DevKit-based CPP 6.0alpha] on darwin1 Type "copyright", "credits" or "license" for more information. >>> import sys, os >>> from distutils.util import get_platform >>> os.name 'posix' >>> sys.platform 'darwin1' >>> get_platform() 'darwin-1.4-Power Macintosh' >>> (Note the space in 'darwin-1.4-Power Macintosh'!) I checked the distutils packge of 2.2a?, but that doesn't seem to be any different. When trying to build the reportlab package (after adding 'darwin1' to the list of known platforms), I get this: [localhost:~/Desktop/reportlab/lib] dinu% python setup.py build running build running build_ext building '_rl_accel' extension creating build creating build/temp.darwin-1.4-Power Macintosh-2.1 cc -g -O2 -Wall -Wstrict-prototypes -I/usr/local/include/python2.1 -c _rl_accel.c -o build/temp.darwin-1.4-Power Macintosh-2.1/_rl_accel.o In file included from /usr/local/include/python2.1/pyport.h:84, from /usr/local/include/python2.1/Python.h:54, from _rl_accel.c:10: /usr/include/math.h:191: warning: function declaration isn't a prototype creating build/lib.darwin-1.4-Power Macintosh-2.1 cc -bundle -undefined suppress build/temp.darwin-1.4-Power Macintosh-2.1/_rl_accel.o -o build/lib.darwin-1.4-Power Macintosh-2.1/_rl_accel.so /usr/bin/ld: /usr/lib/libSystem.dylib load command 6 unknown cmd field error: command 'cc' failed with exit status 1 I can see that Just posted a message about possibly related issues but didn't get any feedback... Well, that's it for a start... Regards, Dinu -- Dinu C. Gherman ................................................................ "They made a desert and called it peace." (Tacitus) From thomas.heller@ion-tof.com Fri Nov 9 05:39:01 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri Nov 9 05:39:01 2001 Subject: [Distutils] distutils on OS X? References: <1005301328.3bebae509dc34@webmail.in-berlin.de> Message-ID: <008f01c1690a$b2022900$e000a8c0@thomasnotebook> > Hi, > > I haven't seen many postings about Darwin and Mac OS X in this > group, so let me add one! > > Has anybody a clue about the official status of distutils on > this platform? I'm trying to build the reportlab package, > but find that distutils seems to be fully unaware of anything > like a 'darwin' platform... > > On my OS X box I get the following: > > [localhost:~/Desktop/reportlab/lib] dinu% python > Python 2.1 (#4, 05/17/01, 18:34:21) > [GCC Apple DevKit-based CPP 6.0alpha] on darwin1 > Type "copyright", "credits" or "license" for more information. > >>> import sys, os > >>> from distutils.util import get_platform > >>> os.name > 'posix' > >>> sys.platform > 'darwin1' > >>> get_platform() > 'darwin-1.4-Power Macintosh' > >>> > > (Note the space in 'darwin-1.4-Power Macintosh'!) I checked the > distutils packge of 2.2a?, but that doesn't seem to be any > different. > So what's the problem? Has it to do with the space? Probably best would be to prepare a patch, assure that it works, and upload it to sourceforge. Thomas From jack@oratrix.nl Fri Nov 9 05:51:01 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri Nov 9 05:51:01 2001 Subject: [Distutils] distutils on OS X? In-Reply-To: Message by Dinu Gherman , Fri, 09 Nov 2001 11:22:08 +0100 (CET) , <1005301328.3bebae509dc34@webmail.in-berlin.de> Message-ID: <20011109105016.CD1B8303181@snelboot.oratrix.nl> > Hi, > > I haven't seen many postings about Darwin and Mac OS X in this > group, so let me add one! > > Has anybody a clue about the official status of distutils on > this platform? I'm trying to build the reportlab package, > but find that distutils seems to be fully unaware of anything > like a 'darwin' platform... Hmm, distutils seems to be aware enough of Darwin that Python's own setup.py, for building the standard extension modules, works grand. > [...] > > cc -bundle -undefined suppress build/temp.darwin-1.4-Power Macintosh-2.1/_rl_accel.o -o build/lib.darwin-1.4-Power Macintosh-2.1/_rl_accel.so > /usr/bin/ld: /usr/lib/libSystem.dylib load command 6 unknown cmd field > error: command 'cc' failed with exit status 1 My guess is that the "-undefined suppress" is the main problem. As of Mac OS X 10.1 using that option is heavily discouraged. What the option does is basically say "ignore all undefined references, we'll see what we can do about them at load time". I'm not 100% sure that this is the problem here, because the error message looks a bit funny, but the rest of the info in this message is true anyway, even if it doesn't solve the immedeate problem:-) The correct way to build extensions is either one of the following: - Build a framework Python, by using --enable-framework on the configure. This will create the whole Python core as a framework, and extensions will be linked against this framework. This creates a more MacOSX-like python (and it is what I usually do), but the Python will be less unix-like. Distutils already understands about this one. - Modify distutils so that it passes the "-bundle_loader python" option to the linker (where "python" is the path to the Python executable), and not pass "-undefined suppress". This will allow the linker to lookup the external references from the extension in the python executable, and register that those externals will be satisfied from the loading executable at load time. (Note that the executable at load time needn't be in the same place). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From just@letterror.com Fri Nov 9 05:58:01 2001 From: just@letterror.com (Just van Rossum) Date: Fri Nov 9 05:58:01 2001 Subject: [Distutils] distutils on OS X? In-Reply-To: <1005301328.3bebae509dc34@webmail.in-berlin.de> Message-ID: <20011109115716-r01010800-ead40ed3-0920-010c@10.0.0.23> Dinu Gherman wrote: > Well, that's it for a start... I can't reproduce your problem, CVS Python, stock reportlab, OSX 10.1. Just From just@letterror.com Fri Nov 9 06:26:01 2001 From: just@letterror.com (Just van Rossum) Date: Fri Nov 9 06:26:01 2001 Subject: [Distutils] distutils on OS X? In-Reply-To: <20011109115716-r01010800-ead40ed3-0920-010c@10.0.0.23> Message-ID: <20011109122601-r01010800-f02a4d1f-0920-010c@10.0.0.23> Just van Rossum wrote: > I can't reproduce your problem, CVS Python, stock reportlab, OSX 10.1. But I can with Python 2.1.1... This did work under 10.0.4, and I see the following difference between the build outputs: Under 2.1.1: cc -bundle -undefined suppress build/temp.darwin-1.4-Power Macintosh-2.1/_rl_accel.o -o build/lib.darwin-1.4-Power Macintosh-2.1/_rl_accel.so Under 2.2 cvs: cc -bundle -flat_namespace -undefined suppress build/temp.darwin-1.4-Power Macintosh-2.2/_rl_accel.o -o build/lib.darwin-1.4-Power Macintosh-2.2/_rl_accel.so This -flat_namespace option might help, so maybe it's fixable by editing the configure script. Jack? (This would most definitely be a candidate for 2.1.2, if there'll be one.) (Dinu: I have the reportlab .so's for Python 2.1.1, as built under 10.0.4, in case nothing works and you must use 2.1.1. It's just not reportlab 1.10.) Just From jack@oratrix.nl Fri Nov 9 07:09:00 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri Nov 9 07:09:00 2001 Subject: [Distutils] distutils on OS X? In-Reply-To: Message by Just van Rossum , Fri, 9 Nov 2001 12:25:59 +0100 , <20011109122601-r01010800-f02a4d1f-0920-010c@10.0.0.23> Message-ID: <20011109120741.4147E303181@snelboot.oratrix.nl> > Under 2.2 cvs: > cc -bundle -flat_namespace -undefined suppress build/temp.darwin-1.4-Power > Macintosh-2.2/_rl_accel.o -o build/lib.darwin-1.4-Power > Macintosh-2.2/_rl_accel.so > > This -flat_namespace option might help, so maybe it's fixable by editing the > configure script. Jack? (This would most definitely be a candidate for 2.1.2, if > there'll be one.) Agreed, for 2.1.2. But note that the -flat_namespace should only be used on 10.1/Darwin 1.4, not on 10.0/Darwin 1.2. For 2.2 I would like to do away with the -flat_namespace and in stead follow the path I explained in a previous mail. It is much less error-prone, and it should be more efficient to load modules too (according to Apple's docs). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From gherman@darwin.in-berlin.de Fri Nov 9 08:01:01 2001 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Fri Nov 9 08:01:01 2001 Subject: [Distutils] distutils on OS X? In-Reply-To: <20011109122601-r01010800-f02a4d1f-0920-010c@10.0.0.23> References: <20011109122601-r01010800-f02a4d1f-0920-010c@10.0.0.23> Message-ID: <1005310843.3bebd37bdf75b@webmail.in-berlin.de> Just van Rossum : > (Dinu: I have the reportlab .so's for Python 2.1.1, as built > under 10.0.4, in case nothing works and you must use 2.1.1. > It's just not reportlab 1.10.) I'm on 10.1 and there's is no way back. Unfortunately most of the Cocoa developer tools also don't work anymore... which is an ugly Apple move IMHO, that forces people to download 180 MB after registering in their developers pro- gram, I'm told... sigh! The .so's are not that important for me, but I'd like to be able to generate them, soon... I've patched get_platform() to replace blanks, but that doesn't help. And then, Jack's comments leave me slightly more confused than I was before. ;-) What I'm actually trying is to build an OS X package (.pkg) using distutils, but so far the bdist_rpm thing is still beyond me. Probably I'll better start with bdist_dumb. Dinu From just@letterror.com Fri Nov 9 08:23:02 2001 From: just@letterror.com (Just van Rossum) Date: Fri Nov 9 08:23:02 2001 Subject: [Distutils] distutils on OS X? In-Reply-To: <1005310843.3bebd37bdf75b@webmail.in-berlin.de> Message-ID: <20011109142253-r01010800-1767eff9-0920-010c@10.0.0.23> Dinu Gherman wrote: > > (Dinu: I have the reportlab .so's for Python 2.1.1, as built > > under 10.0.4, in case nothing works and you must use 2.1.1. > > It's just not reportlab 1.10.) > > I'm on 10.1 and there's is no way back. Erm, they work just fine on 10.1, at least in my 2.1.1 install. > Unfortunately most > of the Cocoa developer tools also don't work anymore... > which is an ugly Apple move IMHO, that forces people to > download 180 MB after registering in their developers pro- > gram, I'm told... sigh! It's free, though. > The .so's are not that important for me, but I'd like to be > able to generate them, soon... I've patched get_platform() > to replace blanks, but that doesn't help. And then, Jack's > comments leave me slightly more confused than I was before. > ;-) Me too ;-) > What I'm actually trying is to build an OS X package (.pkg) > using distutils, but so far the bdist_rpm thing is still > beyond me. Probably I'll better start with bdist_dumb. I think you should move to Python 2.2... Jack and others have done *many* OSX/Darwin things since 2.1.1. Just From jack@oratrix.nl Fri Nov 9 09:47:01 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri Nov 9 09:47:01 2001 Subject: [Distutils] distutils on OS X? In-Reply-To: Message by Dinu Gherman , Fri, 09 Nov 2001 14:00:43 +0100 (CET) , <1005310843.3bebd37bdf75b@webmail.in-berlin.de> Message-ID: <20011109144612.2B5BB303181@snelboot.oratrix.nl> > I'm on 10.1 and there's is no way back. Unfortunately most > of the Cocoa developer tools also don't work anymore... > which is an ugly Apple move IMHO, that forces people to > download 180 MB after registering in their developers pro- > gram, I'm told... sigh! If you mean that you are running 10.1, but still using the old 10.0 development tools then I understand why you get funny errors. Running the old development tools under 10.1 is something that Apple explicitly says will not work. It stands to reason, if you think of it: the shared library format has changed to allow two level namespaces, and those new shared libraries are installed with 10.1. However, your old 10.0 linker has absolutely no knowledge of the format of two level namespace libraries... Once you've installed the 10.1 developer tools, if you want to support 10.0 as well as 10.1 you should read the Two-Level Namespace Executables release note. It explains how to do it, and what the pitfalls are. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From pinard@iro.umontreal.ca Fri Nov 9 10:25:01 2001 From: pinard@iro.umontreal.ca (=?iso-8859-1?q?Fran=E7ois?= Pinard) Date: Fri Nov 9 10:25:01 2001 Subject: [Distutils] Setting group and owner on installed files Message-ID: Hello, my Distutils friends! :-) I've been reading this list for a good while, but this is my first message here, so far that I remember. Before going any further, let me express my satisfaction about `distutils', which gives us the mean of very simple and surprisingly quick installations of our Python things. Despite we use some recent Python version on a few machines, we use Python 1.5.2 for most of them. I installed Distutils explicitely on all those, so it is available everywhere and to everybody in the team, here. We are many people (accounts) installing local Python code, and we like avoiding being root while installing. Our setup use 2775 on installation directories and 664 or 775 for installed files, everything under the same Unix group. It would be very convenient to us if we could manage with Distutils, so these permissions and common group were enforced on installation files, directly at `python setup.py install' time. The main purpose of this letter is suggesting such a feature for some later version of Distutils. But also, to welcome any clever suggestion someone could have in the meantime! Keep happy, all! -- François Pinard http://www.iro.umontreal.ca/~pinard From gherman@darwin.in-berlin.de Fri Nov 9 11:24:01 2001 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Fri Nov 9 11:24:01 2001 Subject: [Distutils] distutils on OS X? In-Reply-To: <20011109144612.2B5BB303181@snelboot.oratrix.nl> References: <20011109144612.2B5BB303181@snelboot.oratrix.nl> Message-ID: <1005323034.3bec031abd5cb@webmail.in-berlin.de> Jack Jansen : > It stands to reason, if you think of it: the shared library format has > changed > to allow two level namespaces, and those new shared libraries are > installed > with 10.1. However, your old 10.0 linker has absolutely no knowledge of > the > format of two level namespace libraries... Well, I didn't know in detail... I checked my update CD- ROM and indeed: it has 621 MB, i.e. no more space left for dev tools! Maybe they should start releasing DVDs only? After all, I think Apple will hardly sell any more boxes without! ;-) BTW, I've got a 0.2 version of a Python PackageMaker tool, although it does *not* use distutils yet! So far it kind of works ok, but there seem to be little issues left mostly with respect to permissions (I guess). Also, the total file sizes of the unzipped root package directory and the zipped archive needs to be evaluated somehow, although I think it can be faked for the beginning. If somebody wants to give it a try and knows 'pax' and OS X's 'bom' stuff a little better than I do, let me know and I'll email you what I have. Dinu From mal@lemburg.com Sat Nov 10 13:59:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat Nov 10 13:59:01 2001 Subject: [Distutils] Setting group and owner on installed files References: Message-ID: <3BED7534.EF7B055A@lemburg.com> Fran=E7ois Pinard wrote: >=20 > Hello, my Distutils friends! :-) >=20 > I've been reading this list for a good while, but this is my first mess= age > here, so far that I remember. Before going any further, let me express > my satisfaction about `distutils', which gives us the mean of very simp= le > and surprisingly quick installations of our Python things. >=20 > Despite we use some recent Python version on a few machines, we use Pyt= hon > 1.5.2 for most of them. I installed Distutils explicitely on all those= , > so it is available everywhere and to everybody in the team, here. We a= re > many people (accounts) installing local Python code, and we like avoidi= ng > being root while installing. Our setup use 2775 on installation direct= ories > and 664 or 775 for installed files, everything under the same Unix grou= p. Well, the low-level machinery certainly is there in distutils; it's just that the commands don't support setting the installation mode for directories and files. Would make a nice addition indeed. The right location for such a site-wide distutils configuration would be a site setup.cfg file (don't remember where distutils looks for this, but the code should have that information). In the meantime, I'd suggest to use the Unix umask setting and perhaps a small shell script which you tell people to use for installing using distutils (or perhaps create a custom distutils installation which uses your mode settings). =20 > It would be very convenient to us if we could manage with Distutils, so > these permissions and common group were enforced on installation files, > directly at `python setup.py install' time. The main purpose of this l= etter > is suggesting such a feature for some later version of Distutils. But = also, > to welcome any clever suggestion someone could have in the meantime! Patches are always welcome too ;-) --=20 Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From pinard@iro.umontreal.ca Sat Nov 10 14:52:01 2001 From: pinard@iro.umontreal.ca (=?iso-8859-1?q?Fran=E7ois?= Pinard) Date: Sat Nov 10 14:52:01 2001 Subject: [Distutils] Re: Setting group and owner on installed files In-Reply-To: <3BED7534.EF7B055A@lemburg.com> References: <3BED7534.EF7B055A@lemburg.com> Message-ID: [M.-A. Lemburg] > > We are many people (accounts) installing local Python code, and we > > like avoiding being root while installing. Our setup use 2775 on > > installation directories and 664 or 775 for installed files, everything > > under the same Unix group. > [...] Would make a nice addition indeed. [...] Patches are always > welcome too ;-) Oh, no doubt that they would be welcome, and quite probable I would have produced some if it was easy for me. You will agree with me that there is a notable distance, between making a suggestion as a mere user, and having understood enough from the code structure and writing philosophy to produce a sensible patch. Until I find enough time for becoming acquainted with distutils internals, best is probably that I try to be a good user first, by at least describing the problems I see, and communicating simple suggestions that come to mind! Even this requires some commitment, you know! :-) > The right location for such a site-wide distutils configuration > would be a site setup.cfg file (don't remember where distutils > looks for this, but the code should have that information). Yes, of course, this is exactly what I had in mind. The correct location seems to be: sys.prixe + '/lib/python' + sys.version[:3] + '/distutils/distutils.cfg' but the documentation speaks of `pydistutils' instead of `distutils'. By the way, could this be brought to the attention of the people taking care of this documentation? (I do not have the documentation here, nor easy Web access, and being out of town, I cannot give a precise reference right now -- I hope that a simple editor search through the documentation source will allow to pinpoint the text to adjust.) > In the meantime, I'd suggest to use the Unix umask setting and perhaps > a small shell script which you tell people to use for installing using > distutils (or perhaps create a custom distutils installation which uses > your mode settings). What I'm doing right now is wrapping the various calls to `setup.py' into a Makefile, as a way to help my co-workers at making the transition, but also to compensate for a few little things like the one above. For example, I use that Makefile to `rm -rf build' before `setup.py build', as I noticed that moved or renamed files will continue getting installed both in their previous and current location or name, which is sometimes inconvenient. Oh, I tried `python setup.py clean', but in simple packages, this yields: running clean warning: clean: 'build/temp.linux-i686-2.0' does not exist -- can't clean it and the `warning:' is not clean enough itself - it raises unneeded questions. By the way, as a general rule everywhere, the word `warning:' should be better written `WARNING:', that little bit of shouting attracts the eye within all the remaining verbosity. I presume that you are like me, and after the few first times around, you do not always read everything, each and every time you build. Warning should stand out, and should not be abused for things not really worth saying. Let me take the opportunity of this message for another little glitch I saw while using `python setup.py sdist'. Whenever a file included from MANIFEST.in happens to be a symbolic link, the generated archive should contain a copy of the pointed to file, and not a mere symbolic link. A symbolic link might have some meaning if the link points elsewhere in the archive, but is not practical if it points to a file which itself not included. The simplest is probably to just never allow symbolic links in generated archives. The `h' option of `tar' should take care of this, but I'm not sure how portable it is to various non-GNU tars. Simpler and safer might be to drive the copy from Python, while preparing the distribution, instead of hard-linking, whenever the original file is a symbolic link. I hope it all sounds reasonable... -- François Pinard http://www.iro.umontreal.ca/~pinard From mal@lemburg.com Fri Nov 16 05:35:00 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Nov 16 05:35:00 2001 Subject: [Distutils] Re: buildpkg.py to evaluate (Was: Python package maker for OS X Installer.app) References: Message-ID: <3BF4E3E5.E87778A4@lemburg.com> Say, would it be possible to write a distutils interface for Dinu's package manager driver ? If so, I wish someone from the Mac crowd would seriously look into this. If you need help, just ask... IMHO, distutils really needs more support for native package managers, e.g. for FreeBSD, Solaris, AIX, HP-UX, etc. We currently have RedHat RPM and Windows -- which is great for quite a large audience, but leaves out a large number of Python supported platforms. Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From jack@oratrix.nl Fri Nov 16 05:51:24 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri Nov 16 05:51:24 2001 Subject: [Distutils] Re: buildpkg.py to evaluate (Was: Python package maker for OS X Installer.app) In-Reply-To: Message by "M.-A. Lemburg" , Fri, 16 Nov 2001 11:01:09 +0100 , <3BF4E3E5.E87778A4@lemburg.com> Message-ID: <20011116105054.9699F303183@snelboot.oratrix.nl> > Say, would it be possible to write a distutils interface for Dinu's > package manager driver ? If so, I wish someone from the Mac crowd > would seriously look into this. If you need help, just ask... I pointed Dinu in the right direction (at least, I pointed him at dbist_dumb.py, which I think is the right direction:-). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From gherman@darwin.in-berlin.de Fri Nov 16 06:11:24 2001 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Fri Nov 16 06:11:24 2001 Subject: [Distutils] Re: buildpkg.py to evaluate (Was: Python package maker for OS X Installer.app) In-Reply-To: <20011116105054.9699F303183@snelboot.oratrix.nl> References: <20011116105054.9699F303183@snelboot.oratrix.nl> Message-ID: <1005909034.3bf4f42a4a443@webmail.in-berlin.de> Jack Jansen : > > Say, would it be possible to write a distutils interface for Dinu's > > package manager driver ? If so, I wish someone from the Mac crowd > > would seriously look into this. If you need help, just ask... Not sure people on this list are aware of the code I hacked up and sent to some guys on pythonmac-sig for review. I've quickly put it here in some temporary space: http://me.in-berlin.de:8080/dinu/tmp/buildpkg-0.2.py > I pointed Dinu in the right direction (at least, I pointed him at > dbist_dumb.py, which I think is the right direction:-). I looked at that before writing the current code (Marc-Andre pointed me to the RPM one). After getting quickly lost (which is because I'm pretty new to distutils, I assume) I decided to get something running outside of it. It was particularly un- clear to me how to best make use of all options for the build process, but maybe I just didn't spend enough time on it. Now, I'm not sure I'm going to make further in-depht analysis, especially as it might be a good occasion for someone to ac- tually write some section in the docs about how to add a new installer to the framework. If it's already there please do point me to it, as I can't spend much time on that now. Regards, Dinu From slash@dotnetslash.net Fri Nov 16 12:55:01 2001 From: slash@dotnetslash.net (Mark W. Alexander) Date: Fri Nov 16 12:55:01 2001 Subject: [Distutils] Re: buildpkg.py to evaluate (Was: Python package maker for OS X Installer.app) In-Reply-To: <3BF4E3E5.E87778A4@lemburg.com> Message-ID: I submitted Solaris and HP-UX packaging commands in April, along with a new base class that allows other packaging commands to be written with consistent support for all PEP241 metadata. They work for me (TM). We'll never know if they work for others if they aren't integrated. Frankly, I'm a little annoyed that they've sat this long, otherwise I might have pursued a Debian command as well. mwa On Fri, 16 Nov 2001, M.-A. Lemburg wrote: > Say, would it be possible to write a distutils interface for Dinu's > package manager driver ? If so, I wish someone from the Mac crowd > would seriously look into this. If you need help, just ask... > > IMHO, distutils really needs more support for native package > managers, e.g. for FreeBSD, Solaris, AIX, HP-UX, etc. We currently > have RedHat RPM and Windows -- which is great for quite a > large audience, but leaves out a large number of Python supported > platforms. > > Thanks, > -- Mark W. Alexander slash@dotnetslash.net From mal@lemburg.com Fri Nov 16 15:07:00 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Nov 16 15:07:00 2001 Subject: [Distutils] Re: buildpkg.py to evaluate (Was: Python packagemaker for OS X Installer.app) References: Message-ID: <3BF566F8.94411735@lemburg.com> "Mark W. Alexander" wrote: > > I submitted Solaris and HP-UX packaging commands in April, along with > a new base class that allows other packaging commands to be written > with consistent support for all PEP241 metadata. > > They work for me (TM). We'll never know if they work for others if > they aren't integrated. Frankly, I'm a little annoyed that they've sat > this long, otherwise I might have pursued a Debian command as well. Hmm, I think we have to do something about the development process for distutils. AFAIK, Andrew is the current distutils champion -- perhaps we ought to be a little more flexible w/r to checkins and allow more people to review the distutils patches ?! Mark, we won't get your patches into Python 2.2 because of the feature freeze, so there's currently no chance to check in your patches, but after 2.2 is out we could look at doing those checkins right away and perhaps even create a separate distribution of distutils before Python 2.3 goes out the door. BTW, if patches don't get reviewed, feel free to forward a short message to this list. > mwa > > On Fri, 16 Nov 2001, M.-A. Lemburg wrote: > > > Say, would it be possible to write a distutils interface for Dinu's > > package manager driver ? If so, I wish someone from the Mac crowd > > would seriously look into this. If you need help, just ask... > > > > IMHO, distutils really needs more support for native package > > managers, e.g. for FreeBSD, Solaris, AIX, HP-UX, etc. We currently > > have RedHat RPM and Windows -- which is great for quite a > > large audience, but leaves out a large number of Python supported > > platforms. > > > > Thanks, > > > > -- > Mark W. Alexander > slash@dotnetslash.net -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From jack@oratrix.nl Fri Nov 16 18:06:02 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri Nov 16 18:06:02 2001 Subject: [Distutils] Re: buildpkg.py to evaluate (Was: Python packagemaker for OS X Installer.app) In-Reply-To: Message by "M.-A. Lemburg" , Fri, 16 Nov 2001 20:20:24 +0100 , <3BF566F8.94411735@lemburg.com> Message-ID: <20011116230526.1450BDB4A0@oratrix.oratrix.nl> Recently, "M.-A. Lemburg" said: > Hmm, I think we have to do something about the development process > for distutils. AFAIK, Andrew is the current distutils champion -- > perhaps we ought to be a little more flexible w/r to checkins > and allow more people to review the distutils patches ?! Yes, definitely. I've also had distutils Mac support miss 2.0 because of this... No critique implied, I fully understand that people have priorities, but I think we should get rid of bottlenecks if at all possible. > Mark, we won't get your patches into Python 2.2 because of the feature > freeze, so there's currently no chance to check in your patches, > but after 2.2 is out we could look at doing those checkins right > away and perhaps even create a separate distribution of distutils > before Python 2.3 goes out the door. Hmm, personally I wouldn't object to features of this type, which will probably be of the form of a single new bdist_foobar module and little else. I know I'm taking the "no new features" dictum rather liberally for MacPython. But that might be the Amsterdammer in me, others may feel different:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From akuchlin@mems-exchange.org Fri Nov 16 18:06:03 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri Nov 16 18:06:03 2001 Subject: [Distutils] Re: buildpkg.py to evaluate (Was: Python packagemaker for OS X Installer.app) In-Reply-To: <3BF566F8.94411735@lemburg.com>; from mal@lemburg.com on Fri, Nov 16, 2001 at 08:20:24PM +0100 References: <3BF566F8.94411735@lemburg.com> Message-ID: <20011116180543.B25789@ute.mems-exchange.org> On Fri, Nov 16, 2001 at 08:20:24PM +0100, M.-A. Lemburg wrote: >Hmm, I think we have to do something about the development process >for distutils. AFAIK, Andrew is the current distutils champion -- >perhaps we ought to be a little more flexible w/r to checkins >and allow more people to review the distutils patches ?! Agreed. If anyone else wants to review and/or approve Distutils patches or bugs, feel free to assign them to yourself, as I'll never get around to looking at them. --amk From mal@lemburg.com Sun Nov 18 09:29:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun Nov 18 09:29:01 2001 Subject: [Distutils] Re: buildpkg.py to evaluate (Was: Python packagemaker for OS X Installer.app) References: <20011116230526.1450BDB4A0@oratrix.oratrix.nl> Message-ID: <3BF7C287.B10A6B05@lemburg.com> Jack Jansen wrote: > > Recently, "M.-A. Lemburg" said: > > Hmm, I think we have to do something about the development process > > for distutils. AFAIK, Andrew is the current distutils champion -- > > perhaps we ought to be a little more flexible w/r to checkins > > and allow more people to review the distutils patches ?! > > Yes, definitely. I've also had distutils Mac support miss 2.0 because > of this... No critique implied, I fully understand that people have > priorities, but I think we should get rid of bottlenecks if at all > possible. Right -- we should allow for distutils updates *between* Python releases too. > > Mark, we won't get your patches into Python 2.2 because of the feature > > freeze, so there's currently no chance to check in your patches, > > but after 2.2 is out we could look at doing those checkins right > > away and perhaps even create a separate distribution of distutils > > before Python 2.3 goes out the door. > > Hmm, personally I wouldn't object to features of this type, which will > probably be of the form of a single new bdist_foobar module and little > else. I know I'm taking the "no new features" dictum rather liberally > for MacPython. But that might be the Amsterdammer in me, others may > feel different:-) That may be easy for the Mac port, it certainly is not for the CVS trunk. IMO, that's ok for distutils installation parts, since these must be very stable. The development parts however could change more frequently, since developers will usually be more flexible in handling possible bugs in new minor releases. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal@lemburg.com Sun Nov 18 09:29:02 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun Nov 18 09:29:02 2001 Subject: [Distutils] Re: buildpkg.py to evaluate (Was: Python packagemaker for OS X Installer.app) References: <3BF566F8.94411735@lemburg.com> <20011116180543.B25789@ute.mems-exchange.org> Message-ID: <3BF7C2C8.F7520CD4@lemburg.com> Andrew Kuchling wrote: > > On Fri, Nov 16, 2001 at 08:20:24PM +0100, M.-A. Lemburg wrote: > >Hmm, I think we have to do something about the development process > >for distutils. AFAIK, Andrew is the current distutils champion -- > >perhaps we ought to be a little more flexible w/r to checkins > >and allow more people to review the distutils patches ?! > > Agreed. If anyone else wants to review and/or approve Distutils > patches or bugs, feel free to assign them to yourself, as I'll never > get around to looking at them. Thanks, Andrew. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From jack@oratrix.nl Sun Nov 18 16:48:01 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sun Nov 18 16:48:01 2001 Subject: [Distutils] Re: buildpkg.py to evaluate (Was: Python packagemaker for OS X Installer.app) In-Reply-To: Message by "M.-A. Lemburg" , Sun, 18 Nov 2001 15:15:35 +0100 , <3BF7C287.B10A6B05@lemburg.com> Message-ID: <20011118214753.05E24DB4A0@oratrix.oratrix.nl> Recently, "M.-A. Lemburg" said: > Jack Jansen wrote: > > > > Recently, "M.-A. Lemburg" said: > > > Hmm, I think we have to do something about the development process > > > for distutils. AFAIK, Andrew is the current distutils champion -- > > > perhaps we ought to be a little more flexible w/r to checkins > > > and allow more people to review the distutils patches ?! > > > > Yes, definitely. I've also had distutils Mac support miss 2.0 because > > of this... No critique implied, I fully understand that people have > > priorities, but I think we should get rid of bottlenecks if at all > > possible. > > Right -- we should allow for distutils updates *between* Python > releases too. This wouldn't work for the Mac (and probably not for Windows either): no-one is going to download anything except complete, test-and-tried MacPython distributions. There are a few thousand people who download betas and about 2 people developing from CVS, but the majority of the MacPython users follow distributions. That is: unless distutils itself could be thaught how to upgrade itself, and distutils distributions have a "minimal required version" field. For most Python packages this wouldn't work, but I think for distutils it could be done. Distutils is pure Python, so there are no problems with missing compilers, search paths, etc, and on every user machine we should be able to download a new version (or, in case of inadequate permissions, tell the user to inform the sysmgr). Also, distutils on the machine where a distribution is created could act as the enforcer of the rule that each distutils-based distribution needs to include the distutils version number under which it is supposed to run. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From mal@lemburg.com Mon Nov 19 05:06:00 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Nov 19 05:06:00 2001 Subject: [Distutils] Re: buildpkg.py to evaluate (Was: Python packagemaker for OS X Installer.app) References: <20011118214753.05E24DB4A0@oratrix.oratrix.nl> Message-ID: <3BF8CDBA.F7E0F727@lemburg.com> Jack Jansen wrote: > > Recently, "M.-A. Lemburg" said: > > Jack Jansen wrote: > > > > > > Recently, "M.-A. Lemburg" said: > > > > Hmm, I think we have to do something about the development process > > > > for distutils. AFAIK, Andrew is the current distutils champion -- > > > > perhaps we ought to be a little more flexible w/r to checkins > > > > and allow more people to review the distutils patches ?! > > > > > > Yes, definitely. I've also had distutils Mac support miss 2.0 because > > > of this... No critique implied, I fully understand that people have > > > priorities, but I think we should get rid of bottlenecks if at all > > > possible. > > > > Right -- we should allow for distutils updates *between* Python > > releases too. > > This wouldn't work for the Mac (and probably not for Windows either): > no-one is going to download anything except complete, test-and-tried > MacPython distributions. There are a few thousand people who > download betas and about 2 people developing from CVS, but the > majority of the MacPython users follow distributions. I wasn't talking about distutils releases which change the installation part of distutils (i.e. install commands etc). It's the development side (e.g. bdist_macos) which should be made available between Python releases to a wider audience of package developers. > That is: unless distutils itself could be thaught how to upgrade > itself, and distutils distributions have a "minimal required version" > field. For most Python packages this wouldn't work, but I think for > distutils it could be done. Distutils is pure Python, so there are no > problems with missing compilers, search paths, etc, and on every user > machine we should be able to download a new version (or, in case of > inadequate permissions, tell the user to inform the sysmgr). Also, > distutils on the machine where a distribution is created could act as > the enforcer of the rule that each distutils-based distribution needs > to include the distutils version number under which it is supposed to run. Nice idea, but there are at least two problems: 1. security concerns on the admin side (how do you know that you can trust the download source) 2. permission problems (only admins would be able to let distutils upgrade itself) I don't know about others, but the first thing I do after downloading a new version of Netscape|Quicken|... is to disable the auto-update feature. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From frog@creatis.insa-lyon.fr Mon Nov 19 09:53:01 2001 From: frog@creatis.insa-lyon.fr (Eric Boix) Date: Mon Nov 19 09:53:01 2001 Subject: [Distutils] data_files "odd" behavior under Un*x Message-ID: <20011119155214.G4522@tux.creatis.insa-lyon.fr> Hi, Apparently the surprising behavior of data_files under Unices as reported by Pete Shinners in December 2000 (see http://aspn.activestate.com/ASPN/Mail/Message/distutils-sig/588325 ) seems to be the one of the current cvs version. Will this behavior persist or am I doing something wrong ? (I use the workaround suggested by Pete Shinners, but this seems odd), Any tip/comment appreciated, Thanks in advance, Eric Boix. ---- http://www.creatis.insa-lyon.fr/~frog From thomas.heller@ion-tof.com Tue Nov 20 02:41:01 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Nov 20 02:41:01 2001 Subject: [Distutils] Version number required for setup? Message-ID: <05e701c17196$c2eefd80$e000a8c0@thomasnotebook> distutils/command/dist.py contains this code # -- Metadata query methods ---------------------------------------- ... def get_version(self): return self.version or "???" which returns '???' as a version number if none is specified in the setup script. Since the bdist commands construct a filename containing the version number this leads to an invalid filename under windows, and the builds fail with a traceback like this: zip -rq D:\workspace\projects\epos\bin\dist\startup-???.win32.zip . creating 'D:\workspace\projects\epos\bin\dist\startup-???.win32.zip' and adding '.' to it error: D:\workspace\projects\epos\bin\dist\startup-???.win32.zip: Invalid argument The fix for bug #409403 (Signal an error if the distribution's metadata has no version) fixed this behaviour by requiring a version number: if self.metadata.version is None: raise DistutilsSetupError, \ "No version number specified for distribution" In the meantime, version 1.47 of dist.py, this code has been removed again. Log message: "Back out the requirement to supply a version number". Why was this done? I do not know whether we should require a version number or not, but at least the "???" string literal should be changed to something which can be part of a valid filename under windows (although IMO 'UNKNOWN' isn't really a better version number than '???')... Thomas From mal@lemburg.com Tue Nov 20 08:51:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue Nov 20 08:51:01 2001 Subject: [Distutils] Version number required for setup? References: <05e701c17196$c2eefd80$e000a8c0@thomasnotebook> Message-ID: <3BFA5DF9.757EED68@lemburg.com> Thomas Heller wrote: > > distutils/command/dist.py contains this code > > # -- Metadata query methods ---------------------------------------- > ... > def get_version(self): > return self.version or "???" > > which returns '???' as a version number if none is specified > in the setup script. > > Since the bdist commands construct a filename containing the version > number this leads to an invalid filename under windows, and the builds > fail with a traceback like this: > > zip -rq D:\workspace\projects\epos\bin\dist\startup-???.win32.zip . > creating 'D:\workspace\projects\epos\bin\dist\startup-???.win32.zip' > and adding '.' to it > error: D:\workspace\projects\epos\bin\dist\startup-???.win32.zip: > Invalid argument > > The fix for bug #409403 (Signal an error if the distribution's metadata > has no version) fixed this behaviour by requiring a version number: > > if self.metadata.version is None: > raise DistutilsSetupError, \ > "No version number specified for distribution" > > In the meantime, version 1.47 of dist.py, this code has been removed again. > Log message: "Back out the requirement to supply a version number". > Why was this done? No idea and I think that we should indeed require the version number -- it's not much of an effort for a developer to add a version number after all. > I do not know whether we should require a version number or not, but at > least the "???" string literal should be changed to something which can > be part of a valid filename under windows (although IMO 'UNKNOWN' isn't > really a better version number than '???')... How about '0.0.0' ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From akuchlin@mems-exchange.org Tue Nov 20 09:07:00 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue Nov 20 09:07:00 2001 Subject: [Distutils] Version number required for setup? In-Reply-To: <05e701c17196$c2eefd80$e000a8c0@thomasnotebook>; from thomas.heller@ion-tof.com on Tue, Nov 20, 2001 at 08:40:55AM +0100 References: <05e701c17196$c2eefd80$e000a8c0@thomasnotebook> Message-ID: <20011120090624.B8420@ute.mems-exchange.org> On Tue, Nov 20, 2001 at 08:40:55AM +0100, Thomas Heller wrote: >In the meantime, version 1.47 of dist.py, this code has been removed again. >Log message: "Back out the requirement to supply a version number". >Why was this done? The motivation came from Numeric Python, where several Distutil scripts are used to build subcomponents. These individual subcomponents don't have version numbers of their own, so requiring a version number in each script was too strict. Using either 0.0.0 or UNKNOWN as the version number would be fine with me. (It would also be a 2.1.2 bugfix candidate.) --amk