From bogus@does.not.exist.com Thu Dec 6 16:52:01 2001 From: bogus@does.not.exist.com (Andrew Kuchling) Date: Thu Dec 6 16:52:01 2001 Subject: [Distutils] Any volunteers for Distutils maintainer? Message-ID: I lack the time to properly maintain the Distutils these days. Is anyone interested in taking it over? It's not clear if much *new* development is needed on the package, though there are a pile of bugs for it in the SourceForge bug tracker. (I've just marked all the outstanding bug and patches as unassigned; feel free to grab any one that interests you and assign it to yourself. Perhaps a single Distutils czar isn't needed any longer, just a group of people who process bugs and patch submissions with reasonable speed.) --amk From Keila - Curitiba" Ol=E1! Veja meu site pessoal. Basta clicar no endere=E7o abaixo. GARANTO SER SUI-GENERIS - CLIQUE ABAIXO: http://www.pastorinha.atfreeweb.com Mais de 162.000 internautas visitaram a PG., existe 6 =C1lbuns: Se voc=EA quiser, por favor, indique minha Home Page, a outros Internautas. Mais detalhes, se comunique, passe um e-mail, que responderei brevemente. Dentro da Home Page, ao lado das fotos, voc=EA poder=E1 saber muito mais sobre mim! Obrigada. e-mail: arosadesaron@zipmail.com.br Beijos:- Keila - Curitiba - Pr - Podes falar comigo, direto dela. Brevemente uma Carta Aberta. - Embora derrubem a p=E1gina eu a subo em 3 horas novamente. "Esta mensagem =E9 enviada com a complac=EAncia da nova legisla=E7=E3o=20 sobre correio eletr=F4nico, Se=E7=E3o 301, Par=E1grafo (a) (2) (c) Decreto S. 1= 618, T=EDtulo Terceiro aprovado pelo "105=BA Congresso Base das Normativas Internacionais sobre o SPAM". Este E-mail n=E3o poder=E1 ser considerado SPAM quando incluir uma forma de ser removido. Para ser removido de futuros correios, simplesmente responda indicando no Assunto: REMOVER" From mal@lemburg.com Fri Dec 7 04:01:12 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Dec 7 04:01:12 2001 Subject: [Distutils] Any volunteers for Distutils maintainer? References: Message-ID: <3C108551.B0D30114@lemburg.com> Andrew Kuchling wrote: > > I lack the time to properly maintain the Distutils these days. Is > anyone interested in taking it over? Thanks for all the work you've done on distutils so far, Andrew! > It's not clear if much *new* > development is needed on the package, though there are a pile of bugs > for it in the SourceForge bug tracker. Oh, I do think that distutils needs to move on. Inparticular it needs support for more native OS packaging tools. We'll look into these after the 2.2 feature freeze. > (I've just marked all the > outstanding bug and patches as unassigned; feel free to grab any one > that interests you and assign it to yourself. Perhaps a single > Distutils czar isn't needed any longer, just a group of people who > process bugs and patch submissions with reasonable speed.) Let's try the bazar method. If it doesn't work out (conflicting opinions, etc), we'll have to perhaps change back to the cathedral. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From hinsen@cnrs-orleans.fr Fri Dec 7 04:58:00 2001 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Fri Dec 7 04:58:00 2001 Subject: [Distutils] Any volunteers for Distutils maintainer? In-Reply-To: <3C108551.B0D30114@lemburg.com> References: <3C108551.B0D30114@lemburg.com> Message-ID: "M.-A. Lemburg" writes: > Thanks for all the work you've done on distutils so far, Andrew! Seconded! > Oh, I do think that distutils needs to move on. Inparticular it > needs support for more native OS packaging tools. We'll look > into these after the 2.2 feature freeze. My pet peeve is missing support for compiler optimization levels. This is what still makes me hesitate to fully switch to distutils, one of my modules runs at half speed when compiled under distutils supervision, and I see no way to change that. 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 thomas.heller@ion-tof.com Fri Dec 7 09:09:00 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri Dec 7 09:09:00 2001 Subject: [Distutils] Any volunteers for Distutils maintainer? References: Message-ID: <16e501c17f28$881aed50$e000a8c0@thomasnotebook> >[...] Perhaps a single > Distutils czar isn't needed any longer, just a group of people who > process bugs and patch submissions with reasonable speed.) I can probably take care of this, but only as long as I can test it on windows. I cannot test *anything* on linux or other systems. Thomas From mal@lemburg.com Fri Dec 7 09:16:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Dec 7 09:16:01 2001 Subject: [Distutils] Any volunteers for Distutils maintainer? References: <16e501c17f28$881aed50$e000a8c0@thomasnotebook> Message-ID: <3C10CF04.C2F2B68B@lemburg.com> Thomas Heller wrote: > > >[...] Perhaps a single > > Distutils czar isn't needed any longer, just a group of people who > > process bugs and patch submissions with reasonable speed.) > > I can probably take care of this, but only as long as I can test it > on windows. I cannot test *anything* on linux or other systems. I can take over the Linux part. -- 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 Dec 7 09:29:00 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri Dec 7 09:29:00 2001 Subject: [Distutils] Any volunteers for Distutils maintainer? In-Reply-To: Message by "M.-A. Lemburg" , Fri, 07 Dec 2001 15:15:32 +0100 , <3C10CF04.C2F2B68B@lemburg.com> Message-ID: <20011207142635.5D375303183@snelboot.oratrix.nl> > Thomas Heller wrote: > > > > >[...] Perhaps a single > > > Distutils czar isn't needed any longer, just a group of people who > > > process bugs and patch submissions with reasonable speed.) > > > > I can probably take care of this, but only as long as I can test it > > on windows. I cannot test *anything* on linux or other systems. > > I can take over the Linux part. I would very much like it if someone else can take over the Mac part, so if someone has a Mac and CodeWarrior: please speak up! If no-one speaks up I guess I'll have to do it, but I really don't want to:-) -- 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 slash@dotnetslash.net Fri Dec 7 09:51:01 2001 From: slash@dotnetslash.net (Mark W. Alexander) Date: Fri Dec 7 09:51:01 2001 Subject: [Distutils] Any volunteers for Distutils maintainer? In-Reply-To: <3C108551.B0D30114@lemburg.com> Message-ID: On Fri, 7 Dec 2001, M.-A. Lemburg wrote: > Andrew Kuchling wrote: > > > > I lack the time to properly maintain the Distutils these days. Is > > anyone interested in taking it over? > > Thanks for all the work you've done on distutils so far, Andrew! Seconded! > > It's not clear if much *new* > > development is needed on the package, though there are a pile of bugs > > for it in the SourceForge bug tracker. > > Oh, I do think that distutils needs to move on. Inparticular it > needs support for more native OS packaging tools. We'll look > into these after the 2.2 feature freeze. I just got a Sharp Zaurus, so I'll sign up for ipk format as long as I'm allowed a stupid question: How portable are pyc and pyo files? Would I be able to compile them on a development platform (i386) and package just the bytecode versions? mwa From mal@lemburg.com Fri Dec 7 10:24:04 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Dec 7 10:24:04 2001 Subject: [Distutils] Any volunteers for Distutils maintainer? References: Message-ID: <3C10DF21.B61ADE6B@lemburg.com> "Mark W. Alexander" wrote: > > > > It's not clear if much *new* > > > development is needed on the package, though there are a pile of bugs > > > for it in the SourceForge bug tracker. > > > > Oh, I do think that distutils needs to move on. Inparticular it > > needs support for more native OS packaging tools. We'll look > > into these after the 2.2 feature freeze. > > I just got a Sharp Zaurus, so I'll sign up for ipk format as long as > I'm allowed a stupid question: How portable are pyc and pyo files? > Would I be able to compile them on a development platform (i386) and > package just the bytecode versions? What is a Sharp Zaurus ? (Sounds like a Greek razorblade to me ;-) In any case, .pyc/o files should be portable since they rely on marshal for the encoding. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From slash@dotnetslash.net Fri Dec 7 10:34:01 2001 From: slash@dotnetslash.net (Mark W. Alexander) Date: Fri Dec 7 10:34:01 2001 Subject: [Distutils] Any volunteers for Distutils maintainer? In-Reply-To: <3C10DF21.B61ADE6B@lemburg.com> Message-ID: On Fri, 7 Dec 2001, M.-A. Lemburg wrote: > "Mark W. Alexander" wrote: > > > > > > It's not clear if much *new* > > > > development is needed on the package, though there are a pile of bugs > > > > for it in the SourceForge bug tracker. > > > > > > Oh, I do think that distutils needs to move on. Inparticular it > > > needs support for more native OS packaging tools. We'll look > > > into these after the 2.2 feature freeze. > > > > I just got a Sharp Zaurus, so I'll sign up for ipk format as long as > > I'm allowed a stupid question: How portable are pyc and pyo files? > > Would I be able to compile them on a development platform (i386) and > > package just the bytecode versions? > > What is a Sharp Zaurus ? (Sounds like a Greek razorblade to me ;-) It's Sharp's entry into the U.S. PDA market running Lineo Embedix and QT Palmtop environment. After fighting an HP Jornada with (the appropriately named) WinCE, I have to say: This thing ROCKS! Even though it's a developer edition, being able to open a terminal window, us vi and ssh in and out of it while it's sitting in it's cradle makes the possibilities endless. And, there's already a python ipk available ;) The ipk files should also work on the Compaw iPAQ pda. Quick demo here: http://developer.sharpsec.com/ mwa From mal@lemburg.com Fri Dec 7 10:35:00 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Dec 7 10:35:00 2001 Subject: [Distutils] Any volunteers for Distutils maintainer? References: <3C108551.B0D30114@lemburg.com> Message-ID: <3C10E1B8.5CD79458@lemburg.com> Konrad Hinsen wrote: > > > Oh, I do think that distutils needs to move on. Inparticular it > > needs support for more native OS packaging tools. We'll look > > into these after the 2.2 feature freeze. > > My pet peeve is missing support for compiler optimization levels. > This is what still makes me hesitate to fully switch to distutils, > one of my modules runs at half speed when compiled under distutils > supervision, and I see no way to change that. Right; I'm currently using a gross hack to enable setting the compiler options (see mxSetup.py in my distutils packages). It would be nice if a packager could define the options in a more flexible way, e.g. by setting an option. We should keep that in mind for next year... could you create a feature request on SF for this ? Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From slash@dotnetslash.net Fri Dec 7 10:44:03 2001 From: slash@dotnetslash.net (Mark W. Alexander) Date: Fri Dec 7 10:44:03 2001 Subject: [Distutils] Any volunteers for Distutils maintainer? In-Reply-To: <3C10E1B8.5CD79458@lemburg.com> Message-ID: On Fri, 7 Dec 2001, M.-A. Lemburg wrote: > Konrad Hinsen wrote: > > > > > Oh, I do think that distutils needs to move on. Inparticular it > > > needs support for more native OS packaging tools. We'll look > > > into these after the 2.2 feature freeze. > > > > My pet peeve is missing support for compiler optimization levels. > > This is what still makes me hesitate to fully switch to distutils, > > one of my modules runs at half speed when compiled under distutils > > supervision, and I see no way to change that. > > Right; I'm currently using a gross hack to enable setting the > compiler options (see mxSetup.py in my distutils packages). It > would be nice if a packager could define the options in a more > flexible way, e.g. by setting an option. Here's another crazy idea. How about adding cross-compiling support? I'm thinking in terms of the catalog-sig. If we could get a catalog server housing distutils packages, the catalog server could generate binary packages for any supported platform, regardless of what platform it was running. Authors could just upload their source and the rest would be magic. I have done enough cross-platform development to be dangerous, but I think all distutils would have to support is a --target option and some sanity checking to see if the appropriate tools exist on the compiling machine. Comments? mwa From hinsen@cnrs-orleans.fr Fri Dec 7 10:56:19 2001 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Fri Dec 7 10:56:19 2001 Subject: [Distutils] Any volunteers for Distutils maintainer? In-Reply-To: <3C10E1B8.5CD79458@lemburg.com> (mal@lemburg.com) References: <3C108551.B0D30114@lemburg.com> <3C10E1B8.5CD79458@lemburg.com> Message-ID: <200112071553.fB7Fr0O09284@chinon.cnrs-orleans.fr> > We should keep that in mind for next year... could you create > a feature request on SF for this ? Done! 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 jafo@tummy.com Fri Dec 7 17:20:02 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Fri Dec 7 17:20:02 2001 Subject: [Distutils] Any volunteers for Distutils maintainer? In-Reply-To: <3C10E1B8.5CD79458@lemburg.com>; from mal@lemburg.com on Fri, Dec 07, 2001 at 04:35:20PM +0100 References: <3C108551.B0D30114@lemburg.com> <3C10E1B8.5CD79458@lemburg.com> Message-ID: <20011207151930.B31059@tummy.com> On Fri, Dec 07, 2001 at 04:35:20PM +0100, M.-A. Lemburg wrote: >would be nice if a packager could define the options in a more >flexible way, e.g. by setting an option. I would think that you'd want that option to be more under the *BUILDER*s control than the packager -- with perhaps a way for the packager to override some settings. For example, when it's known that a certain optimization level is going to produce the wrong code... Sean -- That weapon will replace your tongue. You will learn to speak through it. And your poetry will now be written with blood. -- _Dead_Man_ Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From mal@lemburg.com Mon Dec 10 04:40:59 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Dec 10 04:40:59 2001 Subject: [Distutils] Any volunteers for Distutils maintainer? References: Message-ID: <3C14833A.8EAC9DFF@lemburg.com> "Mark W. Alexander" wrote: > > Here's another crazy idea. How about adding cross-compiling support? > I'm thinking in terms of the catalog-sig. If we could get a catalog > server housing distutils packages, the catalog server could generate > binary packages for any supported platform, regardless of what > platform it was running. Authors could just upload their source and > the rest would be magic. > > I have done enough cross-platform development to be dangerous, but I > think all distutils would have to support is a --target option and > some sanity checking to see if the appropriate tools exist on the > compiling machine. > > Comments? You like driving the SF compile farm using distutils ? Sounds like a cool idea, but it's probably too hard to find a common base of tools for these things. Also, I believe that using Python to do the necessary copying etc. and then having it run distutils on the various machines is the easier and more flexible approach. In any case, it would certainly be nice to have a compile farm for Python extensions -- the SF one is restricted to SF projects so not much use for other things and building your own little farm is too much work. -- 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 Mon Dec 10 05:01:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Dec 10 05:01:01 2001 Subject: [Distutils] Any volunteers for Distutils maintainer? References: <3C108551.B0D30114@lemburg.com> <3C10E1B8.5CD79458@lemburg.com> <20011207151930.B31059@tummy.com> Message-ID: <3C1487E4.F4A6E77B@lemburg.com> Sean Reifschneider wrote: > > On Fri, Dec 07, 2001 at 04:35:20PM +0100, M.-A. Lemburg wrote: > >would be nice if a packager could define the options in a more > >flexible way, e.g. by setting an option. > > I would think that you'd want that option to be more under the *BUILDER*s > control than the packager -- with perhaps a way for the packager to > override some settings. For example, when it's known that a certain > optimization level is going to produce the wrong code... I think that with distutils packager and builder are usually the same person :-) Seriously, I was thinking of putting the default for the optimization level into the setup.cfg file which can then be edited by a package builder for a specific platform. BTW, AFAIK, command line options override the settings in setup.cfg so the builder could even compile without even touching setup.cfg. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From jafo@tummy.com Mon Dec 10 08:05:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Mon Dec 10 08:05:01 2001 Subject: [Distutils] Any volunteers for Distutils maintainer? In-Reply-To: <3C1487E4.F4A6E77B@lemburg.com>; from mal@lemburg.com on Mon, Dec 10, 2001 at 11:01:08AM +0100 References: <3C108551.B0D30114@lemburg.com> <3C10E1B8.5CD79458@lemburg.com> <20011207151930.B31059@tummy.com> <3C1487E4.F4A6E77B@lemburg.com> Message-ID: <20011210060434.X2209@tummy.com> On Mon, Dec 10, 2001 at 11:01:08AM +0100, M.-A. Lemburg wrote: >I think that with distutils packager and builder are >usually the same person :-) I don't think so... If that were true, we wouldn't need distutils... At the very least, you will hopefully have people building your distutils packages on platforms that you don't have access to... >Seriously, I was thinking of putting the default for the >optimization level into the setup.cfg file which can then >be edited by a package builder for a specific platform. I think that's a very good idea. So, with the new change in Distutils development, does this mean that my patch to automatically upload packages during the build process could get in? ;-) Suchandra's package tools are now on the same machine as the swalow stuff, so we should be able to have it update both of the systems at once. Sean -- "You're thinking of Mr. Wizard." "[Emilio Lizardo's] a top scientist, dumbkopf." "So was Mr. Wizard." -- _Buckaroo_Banzai_ Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From knight@baldmt.com Mon Dec 10 19:11:02 2001 From: knight@baldmt.com (Steven Knight) Date: Mon Dec 10 19:11:02 2001 Subject: [Distutils] installing man pages in bdist_rpm Message-ID: Distutils gurus-- In the absence of support for the commented-out "install-man" option, how can I go about arranging for bdist_rpm to install and package a man page properly? Successfull packaging in this case should result in installing a script in /usr/bin/scons, and the man page in /usr/man/man1/scons.1.gz. Here's what I've tried: data_files = [('man/man1', ["scons.1"])] This fails when the INSTALLED_FILES file lists it as /usr/man/man1/scons.1, but RPM has installed the man page as scons.1.gz. data_files = [('man/man1', ["scons.1.gz"])] This doesn't fail, but /usr/man/man1/scons.1.gz doesn't end up in the resultant RPM. doc_files = scons.1.gz ("doc_files" requires a patch to bdist_rpm to make this work.) scons.1.gz gets installed in /usr/share/doc/scons-0.01, not /usr/man/man1, because it's listed as "%doc scons.1.gz" in the .spec file. doc_files = /usr/man/man1/scons.1.gz This puts the path name on the same %doc line in the .spec file: %doc /usr/man/man1/scons.1.gz README.txt And RPM dies as follows: RPM build errors: Two files on one line: /usr/man/man1/scons.1.gz Can't mix special %doc with other forms: /usr/man/man1/scons.1.gz Same configuration, after hacking distutils to put each entry in doc_files on separate %doc lines in the .spec file: RPM dies as follows: RPM build errors: File not found: /var/tmp/scons-buildroot/usr/man/man1/scons.1.gz Okay, I'm out of ideas. Is there any other distutils magic I can try? Am I just SOL unless I hack distutils myself to support this? --SK From mal@lemburg.com Tue Dec 11 04:21:00 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue Dec 11 04:21:00 2001 Subject: [Distutils] Optimization and Auto-Upload (Any volunteers for Distutils maintainer?) References: <3C108551.B0D30114@lemburg.com> <3C10E1B8.5CD79458@lemburg.com> <20011207151930.B31059@tummy.com> <3C1487E4.F4A6E77B@lemburg.com> <20011210060434.X2209@tummy.com> Message-ID: <3C15D033.C372D157@lemburg.com> Sean Reifschneider wrote: > > On Mon, Dec 10, 2001 at 11:01:08AM +0100, M.-A. Lemburg wrote: > >Seriously, I was thinking of putting the default for the > >optimization level into the setup.cfg file which can then > >be edited by a package builder for a specific platform. > > I think that's a very good idea. > > So, with the new change in Distutils development, does this mean that my > patch to automatically upload packages during the build process could get > in? ;-) Suchandra's package tools are now on the same machine as the > swalow stuff, so we should be able to have it update both of the systems at > once. If you haven't already done so, please upload the patch to SF. We'll look into all these new features after the Python 2.2 feature freeze, then. BTW, I haven't followed your tools since IPC9 -- how is the development coming along ? -- 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 Tue Dec 11 04:34:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue Dec 11 04:34:01 2001 Subject: [Distutils] installing man pages in bdist_rpm References: Message-ID: <3C15CD58.E72854E2@lemburg.com> Steven Knight wrote: > > Distutils gurus-- > > In the absence of support for the commented-out "install-man" option, > how can I go about arranging for bdist_rpm to install and package a man > page properly? > > Successfull packaging in this case should result in installing a script > in /usr/bin/scons, and the man page in /usr/man/man1/scons.1.gz. > > Here's what I've tried: > > data_files = [('man/man1', ["scons.1"])] > > This fails when the INSTALLED_FILES file lists it as > /usr/man/man1/scons.1, but RPM has installed the man page as > scons.1.gz. If it has installed the file in man/man1 then you shouldn't have a problem. man works just fine with gzip compressed man pages (at least on my Linux machine). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From knight@baldmt.com Tue Dec 11 06:43:00 2001 From: knight@baldmt.com (Steven Knight) Date: Tue Dec 11 06:43:00 2001 Subject: [Distutils] installing man pages in bdist_rpm In-Reply-To: <3C15CD58.E72854E2@lemburg.com> Message-ID: > > In the absence of support for the commented-out "install-man" option, > > how can I go about arranging for bdist_rpm to install and package a man > > page properly? > > > > Successfull packaging in this case should result in installing a script > > in /usr/bin/scons, and the man page in /usr/man/man1/scons.1.gz. > > > > Here's what I've tried: > > > > data_files = [('man/man1', ["scons.1"])] > > > > This fails when the INSTALLED_FILES file lists it as > > /usr/man/man1/scons.1, but RPM has installed the man page as > > scons.1.gz. > > If it has installed the file in man/man1 then you shouldn't > have a problem. man works just fine with gzip compressed > man pages (at least on my Linux machine). Yes, that would be fine, except that the discrepancy causes the *rpm* kicked off by bdist_rpm to fail because rpm installs it as scons.1.gz, but then it doesn't find the file that it expects from the MANIFEST file. The problem is in this section (I've appended full build output, edited for brevity, at the end): running install_data copying scons.1 -> /var/tmp/scons-buildroot/usr/man/man1 writing list of installed files to 'INSTALLED_FILES' + /usr/lib/rpm/brp-compress + /usr/lib/rpm/brp-strip + /usr/lib/rpm/brp-strip-comment-note Processing files: scons-0.01-1 error: File not found: /var/tmp/scons-buildroot/usr/man/man1/scons.1 Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.33776 + umask 022 + cd /home/knight/scons.0.1.C258/build/scons/build/bdist.linux-i686/rpm/BUILD + cd scons-0.01 + DOCDIR=/var/tmp/scons-buildroot/usr/share/doc/scons-0.01 + export DOCDIR + rm -rf /var/tmp/scons-buildroot/usr/share/doc/scons-0.01 + /bin/mkdir -p /var/tmp/scons-buildroot/usr/share/doc/scons-0.01 + cp -pr README.txt /var/tmp/scons-buildroot/usr/share/doc/scons-0.01 + exit 0 RPM build errors: File not found: /var/tmp/scons-buildroot/usr/man/man1/scons.1 RPM build errors: File not found: /var/tmp/scons-buildroot/usr/man/man1/scons.1 ing manifest file 'MANIFEST' creating scons-0.01 If I had to guess, it looks like brp-compress turns the scons.1 into scons.1.gz, but this is out of my RPM+distutils depth. I ultimately don't care whether scons.1 or scons.1.gz get installed, so long as both RPM and distutils are happy with it... --SK rm -rf build/scons/build build/scons/dist/* build/scons/dist/scons-0.01 python build/scons/setup.py bdist sdist bdist_rpm running bdist bdist.run: format=gztar, command=bdist_dumb, rest=[] running bdist_dumb running build running build_py creating build [snip] copying engine/SCons/Sig/TimeStamp.py -> build/lib/SCons/Sig running build_scripts creating build/scripts copying script/scons -> build/scripts installing to build/bdist.linux-i686/dumb running install running install_lib creating build/bdist.linux-i686 [snip] copying build/lib/SCons/Sig/TimeStamp.py -> build/bdist.linux-i686/dumb/usr/lib/scons/SCons/Sig byte-compiling build/bdist.linux-i686/dumb/usr/lib/scons/SCons/__init__.py to __init__.pyc [snip] byte-compiling build/bdist.linux-i686/dumb/usr/lib/scons/SCons/Sig/TimeStamp.py to TimeStamp.pyc running install_scripts creating build/bdist.linux-i686/dumb/usr/bin copying build/scripts/scons -> build/bdist.linux-i686/dumb/usr/bin changing mode of build/bdist.linux-i686/dumb/usr/bin/scons to 100755 running install_data creating build/bdist.linux-i686/dumb/usr/man creating build/bdist.linux-i686/dumb/usr/man/man1 copying scons.1 -> build/bdist.linux-i686/dumb/usr/man/man1 changing into 'build/bdist.linux-i686/dumb' tar -cf /home/knight/scons.0.1.C258/build/scons/dist/scons-0.01.linux-i686.tar . gzip -f9 /home/knight/scons.0.1.C258/build/scons/dist/scons-0.01.linux-i686.tar changing back to '/home/knight/scons.0.1.C258/build/scons' removing 'build/bdist.linux-i686/dumb' (and everything under it) running sdist reading manifest file 'MANIFEST' creating scons-0.01 [snip] creating scons-0.01/script making hard links in scons-0.01... hard linking LICENSE.txt -> scons-0.01 [snip] hard linking setup.py -> scons-0.01 tar -cf dist/scons-0.01.tar scons-0.01 gzip -f9 dist/scons-0.01.tar removing 'scons-0.01' (and everything under it) running bdist_rpm creating build/bdist.linux-i686/rpm creating build/bdist.linux-i686/rpm/SOURCES creating build/bdist.linux-i686/rpm/SPECS creating build/bdist.linux-i686/rpm/BUILD creating build/bdist.linux-i686/rpm/RPMS creating build/bdist.linux-i686/rpm/SRPMS writing 'build/bdist.linux-i686/rpm/SPECS/scons.spec' running sdist readExecuting(%prep): /bin/sh -e /var/tmp/rpm-tmp.17043 + umask 022 + cd /home/knight/scons.0.1.C258/build/scons/build/bdist.linux-i686/rpm/BUILD + cd /home/knight/scons.0.1.C258/build/scons/build/bdist.linux-i686/rpm/BUILD + rm -rf scons-0.01 + /bin/gzip -dc /home/knight/scons.0.1.C258/build/scons/build/bdist.linux-i686/rpm/SOURCES/scons-0.01.tar.gz + tar -xvvf - drwxr-sr-x knight/software 0 2001-12-11 05:23:17 scons-0.01/ [snip] -rw-r--r-- knight/software 503 2001-12-11 05:23:17 scons-0.01/PKG-INFO + STATUS=0 + '[' 0 -ne 0 ']' + cd scons-0.01 ++ /usr/bin/id -u + '[' 1000 = 0 ']' ++ /usr/bin/id -u + '[' 1000 = 0 ']' + /bin/chmod -Rf a+rX,g-w,o-w . + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.17043 + umask 022 + cd /home/knight/scons.0.1.C258/build/scons/build/bdist.linux-i686/rpm/BUILD + cd scons-0.01 + python setup.py build running build running build_py creating build creating build/lib creating build/lib/SCons copying engine/SCons/Builder.py -> build/lib/SCons [snip] copying engine/SCons/Sig/__init__.py -> build/lib/SCons/Sig running build_scripts creating build/scripts copying script/scons -> build/scripts + exit 0 Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.44627 + umask 022 + cd /home/knight/scons.0.1.C258/build/scons/build/bdist.linux-i686/rpm/BUILD + cd scons-0.01 + python setup.py install --root=/var/tmp/scons-buildroot --record=INSTALLED_FILES running install running build running build_py not copying engine/SCons/Builder.py (output up-to-date) [snip] not copying engine/SCons/Sig/__init__.py (output up-to-date) running build_scripts not copying script/scons (up-to-date) running install_lib not copying build/lib/SCons/Builder.py (output up-to-date) [snip] not copying build/lib/SCons/Sig/__init__.py (output up-to-date) skipping byte-compilation of /var/tmp/scons-buildroot/usr/lib/scons/SCons/Builder.py to Builder.pyc [snip] skipping byte-compilation of /var/tmp/scons-buildroot/usr/lib/scons/SCons/Sig/__init__.py to __init__.pyc runniwarning: install: modules installed to '/var/tmp/scons-buildroot/usr/lib/python1.5/site-packages/', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself ng install_scripts not copying build/scripts/scons (output up-to-date) changing mode of /var/tmp/scons-buildroot/usr/bin/scons to 100755 running install_data copying scons.1 -> /var/tmp/scons-buildroot/usr/man/man1 writing list of installed files to 'INSTALLED_FILES' + /usr/lib/rpm/brp-compress + /usr/lib/rpm/brp-strip + /usr/lib/rpm/brp-strip-comment-note Processing files: scons-0.01-1 error: File not found: /var/tmp/scons-buildroot/usr/man/man1/scons.1 Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.33776 + umask 022 + cd /home/knight/scons.0.1.C258/build/scons/build/bdist.linux-i686/rpm/BUILD + cd scons-0.01 + DOCDIR=/var/tmp/scons-buildroot/usr/share/doc/scons-0.01 + export DOCDIR + rm -rf /var/tmp/scons-buildroot/usr/share/doc/scons-0.01 + /bin/mkdir -p /var/tmp/scons-buildroot/usr/share/doc/scons-0.01 + cp -pr README.txt /var/tmp/scons-buildroot/usr/share/doc/scons-0.01 + exit 0 RPM build errors: File not found: /var/tmp/scons-buildroot/usr/man/man1/scons.1 RPM build errors: File not found: /var/tmp/scons-buildroot/usr/man/man1/scons.1 ing manifest file 'MANIFEST' creating scons-0.01 creating scons-0.01/engine creating scons-0.01/engine/SCons creating scons-0.01/engine/SCons/Node creating scons-0.01/engine/SCons/Scanner creating scons-0.01/engine/SCons/Sig creating scons-0.01/script making hard links in scons-0.01... hard linking LICENSE.txt -> scons-0.01 [snip] hard linking setup.py -> scons-0.01 tar -cf dist/scons-0.01.tar scons-0.01 gzip -f9 dist/scons-0.01.tar removing 'scons-0.01' (and everything under it) copying dist/scons-0.01.tar.gz -> build/bdist.linux-i686/rpm/SOURCES building RPMs rpm -ba --define _topdir /home/knight/scons.0.1.C258/build/scons/build/bdist.linux-i686/rpm --clean build/bdist.linux-i686/rpm/SPECS/scons.spec error: command 'rpm' failed with exit status 1 From vanandel@atd.ucar.edu Tue Dec 11 13:22:00 2001 From: vanandel@atd.ucar.edu (Joe VanAndel) Date: Tue Dec 11 13:22:00 2001 Subject: [Distutils] python scripts installed with bad first line Message-ID: <3C164E86.2B1ADE09@atd.ucar.edu> When using 'distutils' (shipped with Python 2.1) I've found that my Python scripts installed with a first line of: #!/usr/bin/python2.1None This is caused by distutils trying to patch the first line of the python script to use the current interpreter. Here's a patch to avoid this behavior: diff -c build_scripts.py.orig build_scripts.py *** build_scripts.py.orig Tue Dec 11 10:07:45 2001 --- build_scripts.py Tue Dec 11 10:19:08 2001 *************** *** 81,86 **** --- 81,88 ---- if match: adjust = 1 post_interp = match.group(1) + if not post_interp: + post_interp = '' if adjust: self.announce("copying and adjusting %s -> %s" % From akuchlin@mems-exchange.org Tue Dec 11 13:54:01 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue Dec 11 13:54:01 2001 Subject: [Distutils] Any volunteers for Distutils maintainer? In-Reply-To: <3C108551.B0D30114@lemburg.com> References: <3C108551.B0D30114@lemburg.com> Message-ID: <20011211135326.E5352@ute.mems-exchange.org> One problem that underlies several different bugs is that file_util.copy_file() needs some reworking in some way. Bugs #479469 (File copy fails on True64 AFS file system), #425007 (Python 2.1 installs shared libs with mode 0700), and #220993 (Installation flaky with multiple installers, old versions) all seem to demonstrate problems in that function. --amk From mal@lemburg.com Tue Dec 11 15:48:00 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue Dec 11 15:48:00 2001 Subject: [Distutils] python scripts installed with bad first line References: <3C164E86.2B1ADE09@atd.ucar.edu> Message-ID: <3C167141.4E70DC3F@lemburg.com> Thanks, I've checked in a similar patch. BTW, please upload bug reports like these to the SF. That way they won't get lost. Joe VanAndel wrote: > > When using 'distutils' (shipped with Python 2.1) I've found that my > Python scripts installed with a first line of: > > #!/usr/bin/python2.1None > > This is caused by distutils trying to patch the first line of the python > script to use the current interpreter. > > Here's a patch to avoid this behavior: > diff -c build_scripts.py.orig build_scripts.py > *** build_scripts.py.orig Tue Dec 11 10:07:45 2001 > --- build_scripts.py Tue Dec 11 10:19:08 2001 > *************** > *** 81,86 **** > --- 81,88 ---- > if match: > adjust = 1 > post_interp = match.group(1) > + if not post_interp: > + post_interp = '' > > if adjust: > self.announce("copying and adjusting %s -> %s" % > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From jafo@tummy.com Wed Dec 12 03:04:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Wed Dec 12 03:04:01 2001 Subject: [Distutils] Optimization and Auto-Upload (Any volunteers for Distutils maintainer?) In-Reply-To: <3C15D033.C372D157@lemburg.com>; from mal@lemburg.com on Tue, Dec 11, 2001 at 10:21:55AM +0100 References: <3C108551.B0D30114@lemburg.com> <3C10E1B8.5CD79458@lemburg.com> <20011207151930.B31059@tummy.com> <3C1487E4.F4A6E77B@lemburg.com> <20011210060434.X2209@tummy.com> <3C15D033.C372D157@lemburg.com> Message-ID: <20011212010318.T2209@tummy.com> On Tue, Dec 11, 2001 at 10:21:55AM +0100, M.-A. Lemburg wrote: >If you haven't already done so, please upload the patch to SF. >We'll look into all these new features after the Python 2.2 >feature freeze, then. Ok. I'll have to pick up a new copy and find out if it still patches against it. >BTW, I haven't followed your tools since IPC9 -- how is the >development coming along ? Well, I initially figured that having the ability for users to easily get packages into the system was going to be necessary for people to start using it. I worked like crazy on getting it done before the 2.1 release, but it didn't make it in to distutils for whatever reason... I think only one package was ever published to the repository server by an outside user. While at Python 9, I had assigned one of our tummy.folks to work on making a .deb packaging setup for Distutils, but he left a few days after we returned from Python 9. I'm really the only other one here that can do it, and I haven't had time. So, in all, it hasn't really gone anywhere. I haven't really kept up on it. The system I showed at Python 9 was not a rigged demo -- it was fully functional. I think the biggest reason for it's failure was that I just didn't market it very well. I actually built 2 systems that were heavily based on the swalow stuff. One was a software roll-out application, the other is a system for maintaining RPM-based systems (downloading packages and associated packages, upgrading to new versions of packages you have). Both of these were fairly successful, so I think the technology behind swalow is fairly reasonable. The RPM system gave me some opportunities to play around with dependencies, and I think a simple system like RedHat has would work fine for Python. That's the story... Sean -- > Sorry in advance for the idiocy... (Paul) You don't have to give us an advance - we know you're good for it. (Mike) Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From mal@lemburg.com Thu Dec 13 07:29:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Dec 13 07:29:01 2001 Subject: [Distutils] installing man pages in bdist_rpm References: Message-ID: <3C189F25.3E6A79B@lemburg.com> Steven Knight wrote: > > > > In the absence of support for the commented-out "install-man" option, > > > how can I go about arranging for bdist_rpm to install and package a man > > > page properly? > > > > > > Successfull packaging in this case should result in installing a script > > > in /usr/bin/scons, and the man page in /usr/man/man1/scons.1.gz. > > > > > > Here's what I've tried: > > > > > > data_files = [('man/man1', ["scons.1"])] > > > > > > This fails when the INSTALLED_FILES file lists it as > > > /usr/man/man1/scons.1, but RPM has installed the man page as > > > scons.1.gz. > > > > If it has installed the file in man/man1 then you shouldn't > > have a problem. man works just fine with gzip compressed > > man pages (at least on my Linux machine). > > Yes, that would be fine, except that the discrepancy causes the *rpm* > kicked off by bdist_rpm to fail because rpm installs it as scons.1.gz, > but then it doesn't find the file that it expects from the MANIFEST > file. The problem is in this section (I've appended full build output, > edited for brevity, at the end): > > running install_data > copying scons.1 -> /var/tmp/scons-buildroot/usr/man/man1 Hmm, why didn't this report an error then ? I'd check the above dir for that file. RPM is a bit quirky about doc files; could be that you have to add a section like this to you setup.cfg file: """ [bdist_rpm] # Files listed here must also appear in the MANIFEST: doc_files = man/man1/cons.1 """ -- 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 Thu Dec 13 07:39:00 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Dec 13 07:39:00 2001 Subject: [Distutils] Optimization and Auto-Upload (Any volunteers for Distutils maintainer?) References: <3C108551.B0D30114@lemburg.com> <3C10E1B8.5CD79458@lemburg.com> <20011207151930.B31059@tummy.com> <3C1487E4.F4A6E77B@lemburg.com> <20011210060434.X2209@tummy.com> <3C15D033.C372D157@lemburg.com> <20011212010318.T2209@tummy.com> Message-ID: <3C18A191.C97DB41E@lemburg.com> Sean Reifschneider wrote: > > >BTW, I haven't followed your tools since IPC9 -- how is the > >development coming along ? > > Well, I initially figured that having the ability for users to easily > get packages into the system was going to be necessary for people to start > using it. I worked like crazy on getting it done before the 2.1 release, > but it didn't make it in to distutils for whatever reason... I think only > one package was ever published to the repository server by an outside user. > > While at Python 9, I had assigned one of our tummy.folks to work on making > a .deb packaging setup for Distutils, but he left a few days after we > returned from Python 9. I'm really the only other one here that can do it, > and I haven't had time. bdist_deb would be a cool thing to have... btw, would it run on RedHat or SuSE if I install the deb RPM packages there ? > So, in all, it hasn't really gone anywhere. I haven't really kept up on > it. The system I showed at Python 9 was not a rigged demo -- it was fully > functional. I think the biggest reason for it's failure was that I just > didn't market it very well. > > I actually built 2 systems that were heavily based on the swalow stuff. > One was a software roll-out application, the other is a system for > maintaining RPM-based systems (downloading packages and associated > packages, upgrading to new versions of packages you have). Both of these > were fairly successful, so I think the technology behind swalow is fairly > reasonable. The RPM system gave me some opportunities to play around with > dependencies, and I think a simple system like RedHat has would work fine > for Python. > > That's the story... Thanks for the summary. I believe we should actively look into this again after Python 2.2 is out the door. Does the swalow support come as new distutils command or do you need deeper integeration for it to work ? Another interesting new command would be bdist_ppm for ActiveState's PPM format. I'll have to bug Paul Prescod again about this... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From knight@baldmt.com Thu Dec 13 09:19:00 2001 From: knight@baldmt.com (Steven Knight) Date: Thu Dec 13 09:19:00 2001 Subject: [Distutils] Optimization and Auto-Upload (Any volunteers for Distutils maintainer?) In-Reply-To: <3C18A191.C97DB41E@lemburg.com> Message-ID: > > While at Python 9, I had assigned one of our tummy.folks to work on making > > a .deb packaging setup for Distutils, but he left a few days after we > > returned from Python 9. I'm really the only other one here that can do it, > > and I haven't had time. > > bdist_deb would be a cool thing to have... btw, would it run on > RedHat or SuSE if I install the deb RPM packages there ? Yes. I'm building Debian packages on RedHat, using the debhelper package. (IIRC, I didn't find a ready-made debhelper RPM, although I did find a .spec file. I had to tweak the .spec a little to get debhelper to build as an RPM for installation on my RH system.) --SK From mcfletch@geocities.com Thu Dec 13 23:56:01 2001 From: mcfletch@geocities.com (Mike C. Fletcher) Date: Thu Dec 13 23:56:01 2001 Subject: [Distutils] Data file installation locations: how to specify... Message-ID: <3C1986D3.7020804@rogers.com> I've received reports that one of my packages (OpenGLContext) installs certain data files somewhere under /usr/ on certain Unix-like systems instead of using the Package directory. I'd like to figure out if this is expected behaviour, a bug, a version-specific bug, or an expected behaviour with another option available to avoid it. I'm specifying the data files with: dataFiles = [] def nonPythonFile( file ): if string.lower( file ) == 'cvs': return 0 else: return os.path.splitext( file )[1] not in ('.py','.pyc','.pyo', '.db') for directory in ["tests","docs"]: finalFiles = [] for file in os.listdir( directory): if nonPythonFile(file): finalFiles.append (os.path.join(directory, file)) dataFiles.append ( ('OpenGLContext/%s'%(directory),finalFiles) ) setup ( name = "OpenGLContext", version = "1.0a2", description = "Demonstration and testing contexts for PyOpenGL 2.0", author = "Mike C. Fletcher", author_email = "mcfletch@geocities.com", url = "http://pyopengl.sourceforge.net/documentation/openglcontext/", license = "BSD-style, see license.txt for details", package_dir = {'OpenGLContext':'.'}, packages = [ 'OpenGLContext', 'OpenGLContext.tests', 'OpenGLContext.scenegraph', 'OpenGLContext.scenegraph.text', 'OpenGLContext.events', 'OpenGLContext.pydoc', 'OpenGLContext.loaders', ], # non python files of examples data_files = dataFiles, ) Expecting that the data_files will get copied into the OpenGLContext package's directory (which happens on Win32). Is there some other option to say "data file in the package directory"? I'm using distutils '1.0.2pre', assuming the users are using whatever came with their 2.0 or 2.1 distributions. Thoughts appreciated, Mike -- _______________________________________ Mike C. Fletcher http://members.rogers.com/mcfletch/ From jafo@tummy.com Fri Dec 14 09:07:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Fri Dec 14 09:07:01 2001 Subject: [Distutils] Optimization and Auto-Upload (Any volunteers for Distutils maintainer?) In-Reply-To: <3C18A191.C97DB41E@lemburg.com>; from mal@lemburg.com on Thu, Dec 13, 2001 at 01:39:45PM +0100 References: <3C108551.B0D30114@lemburg.com> <3C10E1B8.5CD79458@lemburg.com> <20011207151930.B31059@tummy.com> <3C1487E4.F4A6E77B@lemburg.com> <20011210060434.X2209@tummy.com> <3C15D033.C372D157@lemburg.com> <20011212010318.T2209@tummy.com> <3C18A191.C97DB41E@lemburg.com> Message-ID: <20011214070601.Z2209@tummy.com> On Thu, Dec 13, 2001 at 01:39:45PM +0100, M.-A. Lemburg wrote: >bdist_deb would be a cool thing to have... btw, would it run on >RedHat or SuSE if I install the deb RPM packages there ? I'd presume it would work, just as RPMs will work on HP-UX or whatever... It probably would have it's own package database though, so if your packages depended on, for example, Apache, it might not be happy. >Thanks for the summary. I believe we should actively look into this >again after Python 2.2 is out the door. Does the swalow support come >as new distutils command or do you need deeper integeration for it >to work ? It's an option. I'm a bit rusty on it, but IIRC you could do: setup.py --submit bdist_rpm with the important part being "--submit". The result of the bdist or sdist would be uploaded to the package server. Sean -- "If life was fair, Elvis would be alive and all the impersonators would be dead." -- Johnny Carson Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From mal@lemburg.com Fri Dec 14 12:42:02 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Dec 14 12:42:02 2001 Subject: [Distutils] Optimization and Auto-Upload (Any volunteers for Distutils maintainer?) References: <3C108551.B0D30114@lemburg.com> <3C10E1B8.5CD79458@lemburg.com> <20011207151930.B31059@tummy.com> <3C1487E4.F4A6E77B@lemburg.com> <20011210060434.X2209@tummy.com> <3C15D033.C372D157@lemburg.com> <20011212010318.T2209@tummy.com> <3C18A191.C97DB41E@lemburg.com> <20011214070601.Z2209@tummy.com> Message-ID: <3C1A3A13.A2C2685B@lemburg.com> Sean Reifschneider wrote: > > >Thanks for the summary. I believe we should actively look into this > >again after Python 2.2 is out the door. Does the swalow support come > >as new distutils command or do you need deeper integeration for it > >to work ? > > It's an option. I'm a bit rusty on it, but IIRC you could do: > > setup.py --submit bdist_rpm > > with the important part being "--submit". The result of the bdist or sdist > would be uploaded to the package server. Wouldn't it be better if you'd code this up as command ? That way the submit command could have options on its own and also be called separately from the build commands. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From spierre@isb-sib.ch Mon Dec 17 12:29:00 2001 From: spierre@isb-sib.ch (=?ISO-8859-1?Q?S=E9bastien_Pierre?=) Date: Mon Dec 17 12:29:00 2001 Subject: [Distutils] Installing third-party files in modules Message-ID: <736AE182-F313-11D5-98BA-00039344BB54@isb-sib.ch> Hi all, I have a module a module "spam" that contains the "foo.py" file,=20 plus some other files like "burps.xsl" or "bar.xml". What I want=20 to do is when making a "setup.py install" that the "burps.xsl"=20 and "bar.xml" get installed directly into the site-packages in=20 the "spam" module. Actually distutils seems to ignore non "*.py" files. How can I=20 override this? Cheers, -- S=E9bastien. -- =ABMy friends says we're like the dinosaurs, only we are doing ourselves in much faster than they ever did.=BB Porno For Pyros, Pets From mal@lemburg.com Mon Dec 17 15:58:02 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Dec 17 15:58:02 2001 Subject: [Distutils] Installing third-party files in modules References: <736AE182-F313-11D5-98BA-00039344BB54@isb-sib.ch> Message-ID: <3C1E5CBB.845DF3B7@lemburg.com> S=E9bastien Pierre wrote: >=20 > Hi all, >=20 > I have a module a module "spam" that contains the "foo.py" file, > plus some other files like "burps.xsl" or "bar.xml". What I want > to do is when making a "setup.py install" that the "burps.xsl" > and "bar.xml" get installed directly into the site-packages in > the "spam" module. >=20 > Actually distutils seems to ignore non "*.py" files. How can I > override this? You should try to install them using the data_files option. If that doesn't help, you can always subclass the various commands to better fit your needs. See mxSetup.py in egenix-mx-base for an example. --=20 Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From spierre@isb-sib.ch Tue Dec 18 03:38:00 2001 From: spierre@isb-sib.ch (=?ISO-8859-1?Q?S=E9bastien_Pierre?=) Date: Tue Dec 18 03:38:00 2001 Subject: [Distutils] Installing third-party files in modules In-Reply-To: <3C1E5CBB.845DF3B7@lemburg.com> Message-ID: <7C654D80-F392-11D5-B093-00039344BB54@isb-sib.ch> Le lundi 17 d=E9cembre 2001, =E0 09:59 PM, M.-A. Lemburg a =E9crit : > S=E9bastien Pierre wrote: >> >> Hi all, >> >> I have a module a module "spam" that contains the "foo.py" file, >> plus some other files like "burps.xsl" or "bar.xml". What I want >> to do is when making a "setup.py install" that the "burps.xsl" >> and "bar.xml" get installed directly into the site-packages in >> the "spam" module. >> >> Actually distutils seems to ignore non "*.py" files. How can I >> override this? > > You should try to install them using the data_files option. > If that doesn't help, you can always subclass the various commands > to better fit your needs. See mxSetup.py in egenix-mx-base for > an example. I have looked (quickly) into mxSetup but have not found what I=20 am looking fore. It seems like the data_files do not allow to=20 specify source and target locations in the file system. If I specify the "spam/bar.xml" in the data_files, will it we=20 outputted in sitepackages/spam/bar.xml ? Cheers -- S=E9bastien. -- =ABMy friends says we're like the dinosaurs, only we are doing ourselves in much faster than they ever did.=BB Porno For Pyros, Pets From mal@lemburg.com Tue Dec 18 03:58:18 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue Dec 18 03:58:18 2001 Subject: [Distutils] Installing third-party files in modules References: <7C654D80-F392-11D5-B093-00039344BB54@isb-sib.ch> Message-ID: <3C1F0583.676EC42A@lemburg.com> S=E9bastien Pierre wrote: >=20 > Le lundi 17 d=E9cembre 2001, =E0 09:59 PM, M.-A. Lemburg a =E9crit : >=20 > > S=E9bastien Pierre wrote: > >> > >> Hi all, > >> > >> I have a module a module "spam" that contains the "foo.py" file, > >> plus some other files like "burps.xsl" or "bar.xml". What I want > >> to do is when making a "setup.py install" that the "burps.xsl" > >> and "bar.xml" get installed directly into the site-packages in > >> the "spam" module. > >> > >> Actually distutils seems to ignore non "*.py" files. How can I > >> override this? > > > > You should try to install them using the data_files option. > > If that doesn't help, you can always subclass the various commands > > to better fit your needs. See mxSetup.py in egenix-mx-base for > > an example. >=20 > I have looked (quickly) into mxSetup but have not found what I > am looking fore. It seems like the data_files do not allow to > specify source and target locations in the file system. >=20 > If I specify the "spam/bar.xml" in the data_files, will it we > outputted in sitepackages/spam/bar.xml ? Well, you'll have to check the distutils source code for this. AFAIR, it doesn't and that's why I had to add support to distutils to enable this in mxSetup.py (in order to have the docs and license files live inside the package dirs). --=20 Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From spierre@isb-sib.ch Tue Dec 18 12:23:00 2001 From: spierre@isb-sib.ch (=?ISO-8859-1?Q?S=E9bastien_Pierre?=) Date: Tue Dec 18 12:23:00 2001 Subject: [Distutils] Data file installation locations: how to specify... Message-ID: Hi Mike, As you may have noticed, my problem is quite close to yours. I=20 have tried to put a list of couples (assuming source,dest was=20 ok) into the data_files, which has lead to copying the my files=20 (eg. "spam/foo/bar.xsl") into /sw/spam/foo/bar.xsl, creating the=20 intermediary subdirectories. /sw is the parent directory to the bin directory that contains=20 the python interpreter. So I guess specifying couples copies the=20 file in this location, which is a quite strange "feature" ;) Cheers, -- S=E9bastien. -- =ABchildren are innocent / a teenager's fucked up in the head /=20 adults are even more fucked up / and elderlies are like children=BB Porno For Pyros, Pets From R.Liebscher@gmx.de Wed Dec 19 03:03:00 2001 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Wed Dec 19 03:03:00 2001 Subject: [Distutils] Data file installation locations: how to specify... References: Message-ID: <3C2049FD.5E65120D@gmx.de> S=E9bastien Pierre wrote: >=20 > Hi Mike, >=20 > As you may have noticed, my problem is quite close to yours. I > have tried to put a list of couples (assuming source,dest was > ok) into the data_files, which has lead to copying the my files > (eg. "spam/foo/bar.xsl") into /sw/spam/foo/bar.xsl, creating the > intermediary subdirectories. >=20 > /sw is the parent directory to the bin directory that contains > the python interpreter. So I guess specifying couples copies the > file in this location, which is a quite strange "feature" ;) >=20 > Cheers, >=20 > -- S=E9bastien. >=20 You need a own install command for data files if the distutils install_data is not suitable for you.=20 See for example PyOpenGL http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyopengl/PyOpenGL1/ my_install_data.py and setup.py or pyxml http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyxml/xml/ setup.py and setupext/ (This is slightly modified version of the first.) Kind regards Rene Liebscher From pete@shinners.org Fri Dec 21 04:12:01 2001 From: pete@shinners.org (Pete Shinners) Date: Fri Dec 21 04:12:01 2001 Subject: [Distutils] bdist_wininst and winxp? Message-ID: <3C22FE26.7040008@shinners.org> i just had a user say the installer from distutils wininst crashed for him. he is using windows xp, which may or may not be a problem? the installer was also created for python2.2 using the latest rc1. his version of python was the activestate-2.2. sounds like a lot of possibilities, but i'm hoping people can rule out which of these situations are known to work fine, and perhaps which situations are known to not work? or perhaps it was a freak crash or a funky windows install? so far i've had 75 downloads of the installer and this is the only problem reported. i'm just trying to be sure if there is a problem or not out there? From pete@shinners.org Fri Dec 21 04:17:01 2001 From: pete@shinners.org (Pete Shinners) Date: Fri Dec 21 04:17:01 2001 Subject: [Distutils] distutils and objective-c Message-ID: <3C22FF68.6040001@shinners.org> in order to get my project running on OSX, it's going to need a small bootstrap in objective-c. this is to help setup the cocoa environment. everything is working fine with that, the only problem is if files with the ".m" or ".mm" extension are listed in the "Setup" file (read by the read_setup_file) it doesn't recognize these extensions. we've just hacked up the read_setup_file to treat .m and .mm as regular source files and pass them along to the compiler with the rest of the .c files. this probably can't be changed in time for the python-2.2 release, eh? From thomas.heller@ion-tof.com Fri Dec 21 07:24:16 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri Dec 21 07:24:16 2001 Subject: [Distutils] bdist_wininst and winxp? References: <3C22FE26.7040008@shinners.org> Message-ID: <01a201c18a1a$4ceb8210$e000a8c0@thomasnotebook> From: "Pete Shinners" > i just had a user say the installer from distutils wininst crashed for > him. he is using windows xp, which may or may not be a problem? the > installer was also created for python2.2 using the latest rc1. his > version of python was the activestate-2.2. > There was a bug in bdist_wininst in Python 2.2, up to version 2.2rc1. Fortunately this is fixed now, so Python 2.2 final (should be released today) should work fine. Note: This bug is not XP related. It results in a crash just before the files are actually copied. > sounds like a lot of possibilities, but i'm hoping people can rule out > which of these situations are known to work fine, and perhaps which > situations are known to not work? or perhaps it was a freak crash or a > funky windows install? > > so far i've had 75 downloads of the installer and this is the only > problem reported. i'm just trying to be sure if there is a problem or > not out there? It seems only one actually tried to install this package, the bug is still there. I would suggest you remove the pygame-1.3.win32-py2.2.exe file, and rebuild it with Python 2.2 release version (if you can't wait, you can replace distutils\command\bdist_wininst.py in 2.2rc1 with the CVS version and rebuild). Thomas From thomas.heller@ion-tof.com Fri Dec 21 07:38:01 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri Dec 21 07:38:01 2001 Subject: [Distutils] bdist_wininst and winxp? References: <3C22FE26.7040008@shinners.org> <01a201c18a1a$4ceb8210$e000a8c0@thomasnotebook> Message-ID: <025201c18a1c$3c9268f0$e000a8c0@thomasnotebook> > There was a bug in bdist_wininst in Python 2.2, up to version 2.2rc1. > Fortunately this is fixed now, so Python 2.2 final (should be released > today) should work fine. I forgot this: The bug is in the created package (pygame-1.3.win32-py22.exe int this case). You have to rebuild the package with the fixed bdist_wininst command! Thomas From akuchlin@mems-exchange.org Fri Dec 21 10:37:01 2001 From: akuchlin@mems-exchange.org (akuchlin@mems-exchange.org) Date: Fri Dec 21 10:37:01 2001 Subject: [Distutils] distutils and objective-c In-Reply-To: <3C22FF68.6040001@shinners.org>; from pete@shinners.org on Fri, Dec 21, 2001 at 01:22:48AM -0800 References: <3C22FF68.6040001@shinners.org> Message-ID: <20011221103612.B19757@mozart.mems-exchange.org> On Fri, Dec 21, 2001 at 01:22:48AM -0800, Pete Shinners wrote: >we've just hacked up the read_setup_file to treat .m and .mm as regular >source files and pass them along to the compiler with the rest of the .c >files. > >this probably can't be changed in time for the python-2.2 release, eh? Why not, since the patch is trivial? (I hope. ) I've just checked it in, marking it as a 2.2final candidate. Pete, can you please, please, *please*, grab the current 2.2cvs and check that this actually fixes the problem? --amk From s-thapa-11@alumni.uchicago.edu Fri Dec 28 20:03:01 2001 From: s-thapa-11@alumni.uchicago.edu (Suchandra Thapa) Date: Fri Dec 28 20:03:01 2001 Subject: [Distutils] bdist_rpm Message-ID: <20011228192012.C22225@hepcat> --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've been playing around with the bdist_rpm command in distutils and noticed that if a non pure module does not include a MANIFEST file then= =20 bdist_rpm fails because it doesn't include .h files (also sdist generates an unusable tar ball for the same module). =20 Some of the comments in the distutils mention that without a manifest the sdist doesn't include the header files. Was this a policy decision or was it just because no one implemented something to get the header=20 files? --=20 ------------------------------------------------------------------ Suchandra S. Thapa=20 s-thapa-11@alumni.uchicago.edu ------------------------------------------------------------------ --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjwtGksACgkQ6nShCjt5AZKmsgCgkWcRvBlLOv+obR4q3DZugHvZ SHwAn25xtXNL3qR0rwTsqLVbtn3BJJXp =3DBm -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From mal@lemburg.com Sat Dec 29 07:03:00 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat Dec 29 07:03:00 2001 Subject: [Distutils] bdist_rpm References: <20011228192012.C22225@hepcat> Message-ID: <3C2DB0F1.3C373130@lemburg.com> Suchandra Thapa wrote: > > I've been playing around with the bdist_rpm command in distutils > and noticed that if a non pure module does not include a MANIFEST file then > bdist_rpm fails because it doesn't include .h files (also sdist generates > an unusable tar ball for the same module). > Some of the comments in the distutils mention that without a manifest > the sdist doesn't include the header files. Was this a policy decision or > was it just because no one implemented something to get the header > files? I guess this is by design: How should distutils which .h files to magically include in the MANIFEST ? The Extension() objects only have information about the used .c files and the directories where the headers live. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/