Any volunteers for Distutils maintainer?
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
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/
"M.-A. Lemburg" <mal@lemburg.com> 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 -------------------------------------------------------------------------------
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/
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
"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/
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 -------------------------------------------------------------------------------
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 <jafo@tummy.com> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
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/
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 <jafo@tummy.com> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
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/
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 <jafo@tummy.com> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
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/
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
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 <jafo@tummy.com> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
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/
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
"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/
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
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
[...] 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
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/
participants (7)
-
Andrew Kuchling -
Konrad Hinsen -
M.-A. Lemburg -
Mark W. Alexander -
Sean Reifschneider -
Steven Knight -
Thomas Heller