Re: Python Policy Update
Scott Kitterman ha scritto: doko uploaded the new policy in python-defaults, so we can consider this edition complete. Certainly it's not perfect and I'll be keeping an eye on bug submissions. I've also been added to uploaders for python-defaults and will continue to work on this. Thanks for that, to all involved parties. I'd like to refresh [1] too, it currently states policy is not up-to-date, together with some other inaccuracies. Also, what to do with [2]? This is nor the new policy, nor the best practice nowadays, what about renaming it to avoid misunderstandings? I know a lot of effort has been made to get the archive ready for Python 2.6. Either before or with the Python 2.6 upload, we are going to have to drop Python 2.4 as a supported Python version. Any work that could be done now to ease that transition would be beneficial. We moved towards completing Python 2.6 transition bugs [3], now only a few of them are still open. Many py2.6-isms are yet to come, though. I believe defining a roadmap for the days to come would be appreciated, so interested parties can start to work on issues raised and help Matthias to perform the transition. [1] http://wiki.debian.org/DebianPython [2] http://wiki.debian.org/DebianPython/NewPolicy [3] http://tiny.pl/hqwjz Regards, -- .''`. : :' : Luca Falavigna dktrkr...@debian.org `. `' `- signature.asc Description: OpenPGP digital signature
Python Policy Update
doko uploaded the new policy in python-defaults, so we can consider this edition complete. Certainly it's not perfect and I'll be keeping an eye on bug submissions. I've also been added to uploaders for python-defaults and will continue to work on this. I know a lot of effort has been made to get the archive ready for Python 2.6. Either before or with the Python 2.6 upload, we are going to have to drop Python 2.4 as a supported Python version. Any work that could be done now to ease that transition would be beneficial. Scott K signature.asc Description: This is a digitally signed message part.
Re: Python policy update
On su, 2003-08-24 at 08:38, Joe Wreschnig wrote: On Sat, 2003-08-23 at 23:54, Donovan Baarda wrote: The problem is, run pydance as any user with write permissions to /usr/share/games/pydance, and the *.py's there will be compiled and saved as *.pyc's using whatever version of python was used at the time. When you de-install or purge pydance, the *.pyc's will be left behind. The only such user should be root, who shouldn't be running pydance anyway... Not pydance in particular, perhaps, but this is a more general problem with Python programs packaged in this way. My own package, enemies-of-carlotta, has a program that root might very well want to run (e.g., to list the users on a mailing list), and it would be bad for the .pyc to be regenerated in this case for the wrong python version. I haven't a solution for this right now. -- http://liw.iki.fi/liw/photos/swordmaiden/
Re: Python policy update
On Sun, 2003-08-24 at 09:38, Joe Wreschnig wrote: [...] pydance comes with a number of modules, which are actually its core source code split into managable files. It installs these to /usr/share/games/pydance, and doesn't byte compile these. Based on my reading of this section, this is now not allowed anymore. However, I don't see a good reason for disallowing this. By not bytecompiling the modules, it means that the package works on any version of Python and Pygame meeting its minimum requirements, which is both 2.2 and 2.3. It is entirely platform-independent data, which means it can go into /usr/share, and be replicated across platforms more easily (although this doesn't matter much in the case of pydance specifically, I can see it mattering for other programs). Is there a reason that programs should bytecompile their modules? The startup time reduction, at least in pydance's case (6800 lines, 27 files) is unmeasurable, it takes up more space, and means backporting the package becomes necessary for testing users. The problem is, run pydance as any user with write permissions to /usr/share/games/pydance, and the *.py's there will be compiled and saved as *.pyc's using whatever version of python was used at the time. When you de-install or purge pydance, the *.pyc's will be left behind. When the default python changes version, the useless *.pyc's compiled with the old version of python will stay there until pydance is again run by someone with write access. While the old pyc's hang around, they take up space and add slightly more overhead than no pyc's at all (python will try them first before realising they were compiled with the wrong version). -- Donovan Baarda [EMAIL PROTECTED] http://minkirri.apana.org.au/~abo/
Re: Python policy update
On Wed, 2003-08-20 at 07:09, Josselin Mouette wrote: In order to make it up to date, and to match current packaging practices, I have prepared a draft for a python policy update. It is available at: http://people.debian.org/~joss/python/ It includes clarifications, a new section on bytecompilation, treats the case of private modules, and appendix B now describes a transition like the current one (which is likely to happen again in the future). 3.1.1: A program using /usr/bin/python as interpreter can come up with private python modules. These modules should be installed in /usr/lib/site-python/module, /usr/lib/pythonX.Y/site-packages/module (where pythonX.Y is the current python version) or /usr/lib/package. In the latter case, this directory should be added to sys.path at the program startup. Such a package must depend on python (= X.Y), python ( X.Y+1). pydance comes with a number of modules, which are actually its core source code split into managable files. It installs these to /usr/share/games/pydance, and doesn't byte compile these. Based on my reading of this section, this is now not allowed anymore. However, I don't see a good reason for disallowing this. By not bytecompiling the modules, it means that the package works on any version of Python and Pygame meeting its minimum requirements, which is both 2.2 and 2.3. It is entirely platform-independent data, which means it can go into /usr/share, and be replicated across platforms more easily (although this doesn't matter much in the case of pydance specifically, I can see it mattering for other programs). Is there a reason that programs should bytecompile their modules? The startup time reduction, at least in pydance's case (6800 lines, 27 files) is unmeasurable, it takes up more space, and means backporting the package becomes necessary for testing users. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Python policy update
Le jeu 21/08/2003 à 04:24, Donovan Baarda a écrit : --- 1.4 Module Path, a question; Do we really want /usr/local/ on the python path before /usr/lib/? This makes us vulnerable to busted local installs of python modules, in the same way that #!/usr/bin/env python makes us vulnerable to busted local installs of python. Interesting question. The problem is then how to deal with a user/admin wanting to use a specific version of a single module and puts it in /usr/local. --- 2.2.1 Support Only The Default Version, questions and typo on last paragraph I think Build-Depends: python-dev (= X.Y) should be Build-Depends: python-dev (=X.Y), python-dev (X.Y+1), or doesn't Build-Depends support that. In any case, =X.Y is not sufficient to nail it down. I happen not to agree for the build-depends. Having them set at python-dev (=X.Y) allows for lazy rebuilding at the next python transition. The = X.Y is here mostly for the autobuilders, as in fact the package could build with earlier python versions if it uses dh_python. --- 2.2.3 Support All/Most Versions (Including Default), regarding 2. Part 2. still includes the unsupported stuff about using /usr/lib/python/site-packages. There was some discussion about using /usr/lib/site-python for this instead... should this be updated? The two cases are different: /usr/lib/site-python is meant for the default python version, while /usr/lib/python/site-packages was meant for all python versions at a time. But maybe this should be completely removed or commented out as it is not likely to be supported in the near future. --- 3.1 Version Independent Programs, comments The last para about private modules should also apply against anything that goes in /usr/lib/site-python and is only true because currently there is no mechanism to re-compile version independent packages when python (X.Y) upgrades. The moment python (X.Y) (and perhaps pythonX.Y) is capable of identifying dependent packages and re-compiling them, then there is nothing stopping dependencies like python (=2.0), python (2.4). Well, do you think the wording makes it unclear it is also true for stuff in /usr/lib/site-python? Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Python policy update
Le mer 20/08/2003 à 14:09, Josselin Mouette a écrit : In order to make it up to date, and to match current packaging practices, I have prepared a draft for a python policy update. It is available at: http://people.debian.org/~joss/python/ I have updated this draft using suggestions from first replies. I have also clarified the dependencies on python modules, I think it must be made really clear so that no breakage can occur. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Python policy update
On Fri, 2003-08-22 at 08:02, Josselin Mouette wrote: Le mer 20/08/2003 à 14:09, Josselin Mouette a écrit : In order to make it up to date, and to match current packaging practices, I have prepared a draft for a python policy update. It is available at: http://people.debian.org/~joss/python/ I have updated this draft using suggestions from first replies. I have also clarified the dependencies on python modules, I think it must be made really clear so that no breakage can occur. Nice work... some other things I noticed; 1.2. Main package, last paragraph The line; Its version must be greater than X.Y and smaller than X.Y+1. confused me a bit...till I figured out what you meant. Perhaps something like the following would be clearer; The version of the 'python' package must be greater than or equal to X.Y and less than X.Y+1. It's pretty good. The only other minor nitpick is I think that 3.1. Version Independent Programs should be changed to 3.1. Programs Using the Default Python. Also para 3.2 should probably be renumbered to para 3.1.1 as it applies specifically to programs using the default python. -- Donovan Baarda [EMAIL PROTECTED] http://minkirri.apana.org.au/~abo/
Python policy update
In order to make it up to date, and to match current packaging practices, I have prepared a draft for a python policy update. It is available at: http://people.debian.org/~joss/python/ It includes clarifications, a new section on bytecompilation, treats the case of private modules, and appendix B now describes a transition like the current one (which is likely to happen again in the future). Please comment. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Python policy update
On Wed, Aug 20, 2003 at 02:09:48PM +0200, Josselin Mouette wrote: | In order to make it up to date, and to match current packaging | practices, I have prepared a draft for a python policy update. | It is available at: http://people.debian.org/~joss/python/ | | It includes clarifications, a new section on bytecompilation, treats the | case of private modules, and appendix B now describes a transition like | the current one (which is likely to happen again in the future). | | Please comment. Bullet 5 in Appendix B refers to the wrong section. -D -- Many are the plans in a man's heart, but it is the Lord's purpose that prevails. Proverbs 19:21 http://dman13.dyndns.org/~dman/ pgpqY8JgCVCbN.pgp Description: PGP signature
Re: Python policy update
Josselin Mouette [EMAIL PROTECTED] writes: In order to make it up to date, and to match current packaging practices, I have prepared a draft for a python policy update. It is available at: http://people.debian.org/~joss/python/ It includes clarifications, a new section on bytecompilation, Maybe a pointer to dh_python would be good in this section. Regards -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 It's *GNU*/Linux dammit!
Re: Python policy update
On Wed, 2003-08-20 at 22:09, Josselin Mouette wrote: In order to make it up to date, and to match current packaging practices, I have prepared a draft for a python policy update. It is available at: http://people.debian.org/~joss/python/ It includes clarifications, a new section on bytecompilation, treats the case of private modules, and appendix B now describes a transition like the current one (which is likely to happen again in the future). Please comment. Nice work... have some contributions to make; --- 1.2 Main Package, last paragraph At any time, exactly one package must contain a binary /usr/bin/python. That package must either be python or a dependency of that package. At any time, the python (X.Y) package must contain a symlink /usr/bin/python to the the appropriate binary /usr/bin/pythonX.Y. The python package must also depend on the appropriate pythonX.Y to ensure this binary is installed. --- 1.2.3 Interpreter location, last paragraph The preferred specification for the Python interpreter is /usr/bin/python or /usr/bin/pythonX.Y. If a maintainer would like to provide the user with the possibility to override the Debian Python interpreter, he may want to use /usr/bin/env python or /usr/bin/env pythonX.Y. The preferred specification for the Python interpreter is /usr/bin/python or /usr/bin/pythonX.Y. This ensures that a Debian installation of python is used and all dependencies are met. If a maintainer would like to provide the user with the possibility to override the Debian Python interpreter, he may want to use /usr/bin/env python or /usr/bin/env pythonX.Y. However this is not advisable as it bypasses Debian's dependency checking and makes the package vulnerable to broken local installations of python. --- 1.4 Module Path, a question; Do we really want /usr/local/ on the python path before /usr/lib/? This makes us vulnerable to busted local installs of python modules, in the same way that #!/usr/bin/env python makes us vulnerable to busted local installs of python. --- 2.2.1 Support Only The Default Version, questions and typo on last paragraph We should mention programs should use #!/usr/bin/python. I think Build-Depends: python-dev (= X.Y) should be Build-Depends: python-dev (=X.Y), python-dev (X.Y+1), or doesn't Build-Depends support that. In any case, =X.Y is not sufficient to nail it down. last TODO should have pythonX.Y-foo, not python-fooX.Y --- 2.2.3 Support All/Most Versions (Including Default), regarding 2. Part 2. still includes the unsupported stuff about using /usr/lib/python/site-packages. There was some discussion about using /usr/lib/site-python for this instead... should this be updated? --- 3.1 Version Independent Programs, comments This strikes me as a mix of a few different alternatives. perhaps these should be separated out and explained a bit better. Anything that puts stuff in /usr/lib/pythonX.Y or depends on python (=X.Y), python (X.Y+1) is not really version independent. Perhaps this should be re-titled Programs using the default python, and the following section should be called Programs using a particular version of python The last para about private modules should also apply against anything that goes in /usr/lib/site-python and is only true because currently there is no mechanism to re-compile version independent packages when python (X.Y) upgrades. The moment python (X.Y) (and perhaps pythonX.Y) is capable of identifying dependent packages and re-compiling them, then there is nothing stopping dependencies like python (=2.0), python (2.4). -- Donovan Baarda [EMAIL PROTECTED]
