Bytecode compilation
Hello. I've read the draft python policy, and my packages follow it. There is, however, something that I think is missing. What's the policy on byte-compilation? Should there be both .pyc and .pyo files? Should the files be compiled in the postinst script or can they be distributed with the package? If I've missed something, please let me know. Regards, Martin -- Martin Sjögren [EMAIL PROTECTED] ICQ : 41245059 Phone: +46 (0)31 7710870 Cell: +46 (0)739 169191 GPG key: http://www.strakt.com/~martin/gpg.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bytecode compilation
On Thu, Jul 25, 2002 at 01:05:27PM +0200, Martin Sjögren wrote: > Hello. > > I've read the draft python policy, and my packages follow it. There is, > however, something that I think is missing. What's the policy on > byte-compilation? Should there be both .pyc and .pyo files? Should the > files be compiled in the postinst script or can they be distributed with > the package? My personal understanding is that it is not necessary to distribute the .pyc and .pyo, because this would only make the package larger. Their creation is dealt with in the postinst script. Grap any python package source package and check the postinst script, which generally does the compiling. Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bytecode compilation
On Thu, Jul 25, 2002 at 01:05:27PM +0200, Martin Sjögren wrote: > I've read the draft python policy, and my packages follow it. There is, > however, something that I think is missing. What's the policy on > byte-compilation? Should there be both .pyc and .pyo files? Should the > files be compiled in the postinst script or can they be distributed with > the package? The tradeoff decision between postinst compilation (consumes CPU) and .pyc, .pyo inclusion (consumes HD space) is up to you. I prefer postinst compilation. So long, -- .~. /V\ Bastian Kleineidam · Unleash the power. Use Linux. /( )\ ^^-^^ pgp9SplQfE4oX.pgp Description: PGP signature
Re: Bytecode compilation
On Thu, Jul 25, 2002 at 01:54:24PM +0200, Bastian Kleineidam wrote: > On Thu, Jul 25, 2002 at 01:05:27PM +0200, Martin Sjögren wrote: > > I've read the draft python policy, and my packages follow it. There is, > > however, something that I think is missing. What's the policy on > > byte-compilation? Should there be both .pyc and .pyo files? Should the > > files be compiled in the postinst script or can they be distributed with > > the package? Surely the right way to handle this is using debconf in the main python packages, and subsequently any packages check this to see if python scripts should be compiled or not. Or have I missed anything? Cheers Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bytecode compilation
Dave Swegen <[EMAIL PROTECTED]> wrote: > Surely the right way to handle this is using debconf in the main python > packages, and subsequently any packages check this to see if python > scripts should be compiled or not. Or have I missed anything? You are talking about (compiling the .py in postinst | installing them on the system without any compiled version); what was discussed previously is (compiling the .py in postinst | including the .py, .pyc and optionally .pyo in the .deb to avoid postinst byte-compilation). With the latter, a debconf question would not be very helpful since the .deb would have to ship the .pyc and/or .pyo anyway... -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bytecode compilation
On Thu, Jul 25, 2002 at 02:41:09PM +0200, Florent Rougon wrote: > Dave Swegen <[EMAIL PROTECTED]> wrote: > > > Surely the right way to handle this is using debconf in the main python > > packages, and subsequently any packages check this to see if python > > scripts should be compiled or not. Or have I missed anything? > > You are talking about (compiling the .py in postinst | installing them > on the system without any compiled version); what was discussed > previously is (compiling the .py in postinst | including the .py, .pyc > and optionally .pyo in the .deb to avoid postinst byte-compilation). > > With the latter, a debconf question would not be very helpful since the > .deb would have to ship the .pyc and/or .pyo anyway... Not having really followed the discussion, and being faaar too bone-idle to actually look it up in the archives, this is my view on it: Shipping pre-compiled really isn't an option, as the size increase would be unacceptable - not only from a debian archive/bandwidth POV, but also from an older machine/tiddy HD POV. Pre-compiling in post-inst is thus IMHO the only way to do it, and only if the user wants to do it (I can just imagine how awful it would be to install python2.2 + friends on a 486 with 16 meg'o'ram :) Maybe it would be an idea to provide a script that the user can run when he feels the machine isn't needed for anything else. Anyway, I've done my uninformed butting in, and will return to lurk mode. Cheers Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
python2.2 for sarge?
Sorry, I've not checked for existing threads on this topic... will Sarge use Python2.2 by any chance? Once this is decided, the sooner it is made official, the sooner packages will start updating, and the faster we will get a stable Sarge... Specifically, I am wondering if I should go to the trouble of compiling a python2.2-based libapache-mod-python - probably, I just thought it would be cool if I could get the maintainer to do it by filing a bug report, which I can only sensibly do once we have 2.2 by default. I need 2.2 for python2.2-dictclient, and for boost_python v2. (I've already got a "local install" of newer pygame and pyopengl). Thanks, Hugo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python2.2 for sarge?
Il gio, 2002-07-25 alle 16:04, Hugo van der Merwe ha scritto: > Sorry, I've not checked for existing threads on this topic... will Sarge > use Python2.2 by any chance? Once this is decided, the sooner it is made > official, the sooner packages will start updating, and the faster we > will get a stable Sarge... > > Specifically, I am wondering if I should go to the trouble of compiling > a python2.2-based libapache-mod-python - probably, I just thought it > would be cool if I could get the maintainer to do it by filing a bug > report, which I can only sensibly do once we have 2.2 by default. I need > 2.2 for python2.2-dictclient, and for boost_python v2. (I've already got > a "local install" of newer pygame and pyopengl). python 2.2 is stable. do we have any important modules that *don't* work with 2.2? if not we can makeit the default. -- Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] Qu'est ce que la folie? Juste un sentiment de liberté si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra signature.asc Description: PGP signature
Re: python2.2 for sarge?
Federico Di Gregorio <[EMAIL PROTECTED]>: > Il gio, 2002-07-25 alle 16:04, Hugo van der Merwe ha scritto: > > Sorry, I've not checked for existing threads on this topic... will Sarge > > use Python2.2 by any chance? Once this is decided, the sooner it is made > > official, the sooner packages will start updating, and the faster we > > will get a stable Sarge... the question is, if _want_ 2.2 the default for sarge, or if we want 2.3. we did miss the release of 2.2 by one month in woody (made the switch in Nov 2001, 2.2 was released in Dec 2001). > > Specifically, I am wondering if I should go to the trouble of compiling > > a python2.2-based libapache-mod-python - probably, I just thought it > > would be cool if I could get the maintainer to do it by filing a bug > > report, which I can only sensibly do once we have 2.2 by default. I need > > 2.2 for python2.2-dictclient, and for boost_python v2. (I've already got > > a "local install" of newer pygame and pyopengl). > > python 2.2 is stable. do we have any important modules that *don't* work > with 2.2? if not we can makeit the default. some packages do have problems to built with 2.2 (packages which are not updated for a loong time ...) My current plan is: - upload python2.3 packages soon (when 2.3alpha1 is released) - remove python1.5 from unstable - adopt python-central for 2.1, 2.2 and 2.3, hopefully with the help of the author, hint, hint - upload python2.3 beta to unstable - make it the python default - remove python2.1 from unstable I don't see much sense in making the switch to 2.2 now and then again to 2.3. But anyway, let's make unstable really unstable first by switching to gcc-3.2 as the default compiler (coming soon :-) Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bytecode compilation
Dave Swegen <[EMAIL PROTECTED]> wrote: > Not having really followed the discussion, and being faaar too bone-idle > to actually look it up in the archives, this is my view on it: Shipping > pre-compiled really isn't an option, as the size increase would be > unacceptable - not only from a debian archive/bandwidth POV, but also > from an older machine/tiddy HD POV. Agreed. > install python2.2 + friends on a 486 with 16 meg'o'ram :) Maybe it would > be an idea to provide a script that the user can run when he feels the > machine isn't needed for anything else. This doesn't sound like a bad idea, but the compiled file for python packages are currently put in /usr (not /usr/local), along with their corresponding .py. The packages create them in postinst and therefore take the responsibility of deleting them when the package is removed. If we let the admin create the compiled files in /usr with a script (à la compileall.py), he might be surprised to see them removed with the corresponding package. This can be argued about, however. > Anyway, I've done my uninformed butting in, and will return to lurk > mode. Well, noone asked you to do so (that is, to return to lurk), AFAIK. My answer wasn't meant to sound offensive. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python2.2 for sarge?
On Jul 25, Matthias Klose wrote: > My current plan is: > > - upload python2.3 packages soon (when 2.3alpha1 is released) > > - remove python1.5 from unstable > > - adopt python-central for 2.1, 2.2 and 2.3, hopefully with the > help of the author, hint, hint > > - upload python2.3 beta to unstable > > - make it the python default > > - remove python2.1 from unstable > > I don't see much sense in making the switch to 2.2 now and then again > to 2.3. But anyway, let's make unstable really unstable first by > switching to gcc-3.2 as the default compiler (coming soon :-) I don't think python2.1 should be dropped until sarge+1; keeping around the previous default Python in the next release is probably a good idea as general policy. I also wouldn't bother switching to 2.2 as the default if 2.3 is going to be the default by December. Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/ Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5765 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python2.2 for sarge?
On Thu, Jul 25, 2002 at 03:28:59PM -0500, Chris Lawrence wrote: > On Jul 25, Matthias Klose wrote: > > My current plan is: > > > > - upload python2.3 packages soon (when 2.3alpha1 is released) > > > > - remove python1.5 from unstable > > > > - adopt python-central for 2.1, 2.2 and 2.3, hopefully with the > > help of the author, hint, hint I can help with this. I'm not a Debian developer tho'. > > - upload python2.3 beta to unstable > > > > - make it the python default > > > > - remove python2.1 from unstable > > > > I don't see much sense in making the switch to 2.2 now and then again > > to 2.3. But anyway, let's make unstable really unstable first by > > switching to gcc-3.2 as the default compiler (coming soon :-) > > I don't think python2.1 should be dropped until sarge+1; keeping > around the previous default Python in the next release is probably a > good idea as general policy. agree... > I also wouldn't bother switching to 2.2 as the default if 2.3 is going > to be the default by December. If people are using the "simple wrapper" approach to supporting the default Python, then switching to 2.2 would just consist of releasing empty wrapper packages with changed dependancies... pretty easy NMU stuff. If people are screaming for 2.2, then I'd say changing now and again to 2.3 in Dec would be minimal hassle. However, it depends on demand vs effort... If people really need 2.2, then it doesn't need to be the default anyway... just use the python2.2- packages... -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
