Re: RFC: Proposed updates to the Python Policy to reflect current practices
Hi Loïc! Loïc Minier wrote: Require the python- prefix for public modules This would mean we'd need to split e.g. python-gtk2 into five. Do we really want that? The should wording allowed one to not do it in special cases. I'm not saying we shouldn't change it, but we should make sure we're aware of all the consequences of the change... Regards, Emilio signature.asc Description: OpenPGP digital signature
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote: Require the python- prefix for public modules This would mean we'd need to split e.g. python-gtk2 into five. Do we really want that? The should wording allowed one to not do it in special cases. I'm not saying we shouldn't change it, but we should make sure we're aware of all the consequences of the change... Good point; I guess we want to require the python- prefix (at least when a dependency is involved), and a recommendation to use python-foo when shipping module foo (unless shipping multiple modules, or when the module name doens't allow so (underscores for instance). -- Loïc Minier -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Tue, Dec 08, 2009, Jakub Wilk wrote:
+ versions explicitely.
You could fix that typo if you are at it.
Thanks; I've spell checked the whole document and came up with the
attached patch, Spell check fixes.
--
Loïc Minier
From ee2c89e0b24b2deff74ad35d59a8ca4a9f936ecf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@dooz.org
Date: Fri, 11 Dec 2009 12:00:18 +0100
Subject: [PATCH 29/29] Spell check fixes
---
debian/python-policy.sgml | 52 ++--
1 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml
index 67e3d76..513200e 100644
--- a/debian/python-policy.sgml
+++ b/debian/python-policy.sgml
@@ -62,7 +62,7 @@
tt/usr/share/common-licences/GPL/tt in the Debian GNU/Linux
distribution or on the World Wide Web at
url id=http://www.gnu.org/copyleft/gpl.html;
- name=The GNU Public Licence.
+ name=The GNU Public License.
/p
p
You can also obtain it by writing to the
@@ -96,7 +96,7 @@
are needed by other packages, or as long as it seems
reasonable to provide them. (Note: For the scope of this
document, Python versions are synonymous to feature
- releases, i.e. Python 2.5 and 2.5.1 are subminor versions of
+ releases, i.e. Python 2.5 and 2.5.1 are sub-minor versions of
the same Python version 2.5, but Python 2.4 and 2.5 are
indeed different versions.)
/p
@@ -115,7 +115,7 @@
byte-compiled, old-versions which is the list of runtimes which
might still be on the system but for which should not be built
anymore, and unsupported-versions which is the list of runtimes
- which should not be supported at all, that is modules shouldn't be
+ which should not be supported at all, that is modules should not be
built or byte-compiled for these.
/p
p
@@ -186,11 +186,11 @@
p
Python scripts depending on the default Python version (see ref
id=base) or not depending on a specific Python version should
- use filepython/file (unversioned) as the interpreter name.
+ use filepython/file (without a version) as the interpreter name.
/p
p
Python scripts that only work with a specific Python version must
- explicitly use the versioned interpreter name
+ explicitly use the version-ed interpreter name
(filepythonvarX/var.varY/var/file).
/p
/sect1
@@ -285,7 +285,7 @@
There are three supported hook types which come in the form of
scripts which are invoked from the maintainer scripts of the
Python runtime packages when specific installations,
- uninstallations, or upgrades occur.
+ removals, or upgrades occur.
/p
penumlist
item
@@ -345,7 +345,7 @@
Python transitions. Python modules are internally very
dependent on a specific Python version. However, we want to
automate recompiling modules when possible, either during the
- upgrade itself (re-bytecompiling pyc and pyo files) or shortly
+ upgrade itself (re-byte-compiling pyc and pyo files) or shortly
thereafter with automated rebuilds (to handle C
extensions). These policies encourage automated dependency
generation and loose version bounds whenever possible.
@@ -378,8 +378,8 @@
modules are installed in a public directory as listed
in ref id=paths. They are accessible to any
program. Private modules are installed in a private directory such
- as file/usr/share/varpackagename/var/file
- or file/usr/lib/varpackagename/var/file. They are
+ as file/usr/share/varpackage-name/var/file
+ or file/usr/lib/varpackage-name/var/file. They are
generally only accessible to a specific program or suite of
programs included in the same package.
/p
@@ -446,7 +446,7 @@ XB-Python-Version: ${python:Versions}
yourself.) The format of the field ttXB-Python-Version/tt is
the same as the ttXS-Python-Version/tt field for packages not
containing extensions. Packages with extensions must list the
- versions explicitely.
+ versions explicitly.
/p
p
If your package is used by another module or application
@@ -489,11 +489,11 @@ XB-Python-Version: ${python:Versions}
/p
/sect
- sect id=bytecompilation
-headingModules Bytecompilation/heading
+ sect id=byte_compilation
+headingModules Byte-Compilation/heading
p
If a binary package provides any binary-independent modules
- (filefoo.py/file files), the corresponding bytecompiled
+ (filefoo.py/file files), the corresponding byte-compiled
modules (filefoo.pyc/file files) and optimized modules
(filefoo.pyo/file files) must not ship in the
package. Instead, they should be generated in the package's
@@ -534,7 +534,7 @@ XB-Python-Version: ${python:Versions}
begin with tt#!/usr/bin/python/tt or tt#!/usr/bin/env
python/tt (the former is preferred). They must also
specify a dependency on packagepython/package, with a
- versioned dependency
Recursive dependencies on pythonX.Y-foo practices
On Thu, Dec 10, 2009, Josselin Mouette wrote:
Rationale: let’s consider a package foo that uses python2.4 directly
(with a python2.4 shebang), and depends on python2.4-foo, provided by
python-foo, which in turn depends on python-bar. If python-bar is
rebuilt with XS-P-V: = 2.5, it will stop providing python2.4-bar, but
python-foo will not change, and will still provide python2.4-foo. Then
foo will simply stop working.
This is why the usage of pythonX.Y-foo dependencies should not be
recommended. Packages providing public modules should all be in one of
these cases:
* No Provides: ${python:Provides} at all.
* The package has no dependency on other Python modules.
* The package depends on all pythonX.Y-bar, for X.Y in
${python:Versions} and bar in all dependencies in other modules.
Since the last solution is very suboptimal (it requires simultaneous
uploads and testing migration for all entangled packages), it should be
avoided – and anyway we should discourage use of a specific pythonX.Y
version.
I agree that in general we want to avoid using a specific pythonX.Y
version in packages. I also agree that there is a problem with the
current situation which doesn't ensure that pythonX.Y-foo really works
when bar changes.
It would be ok to not have Provides: in python-foo when there is no
reverse dependency requiring a non-default python version. It makes it
harder to have a package depend on a non-default version of python-foo,
but this has to be balanced with requiring pythonX.Y-foo -
pythonX.Y-bar for all versions.
An entirely different approach is simply enforcing that at in
transitions or at the QA level:
* either ensure that we do rebuilds in the proper order when the
list of suppored version changes (rebuild python-foo before
python-bar)
* or simply have a debcheck-alike script which verifies that there is
no case of a pythonX.Y-foo dep where pythonX.Y-bar is missing
Another approach I can think of is to put the burden on the package
requiring a specific python version:
* either manage the recursive pythonX.Y-foo and pythonX.Y-bar deps
manually in the package
* or require installation of python-foo when this package gets built as
to allow computing its recursive dependencies
I don't quite like the latter, as it pulls more stuff than needed at
build time and is a bit fragile, but it does shift the problem on a
much smaller subset of packages, and doesn't prevent the rest of the
python packages to move on.
Another related issue is that of packages linking to libpython to embed
an interpreter. Most of them link to the library corresponding to the
default python version of the moment. Therefore all their dependencies
should be pythonX.Y-foo and not python-foo like what is (incorrectly)
done currently.
I aboslutely agree that these should depend on pythonX.Y for libpython
itself; it might make sense to expand their python-baz (= x) deps to
python2.x-baz, python2.y-baz, python-baz (= x), but it's not clear how
to express that the package will use this or that version of python at
run time.
For extensions, it might make sense to require all versions of all
depended upon packages.
But I'm very worried that any such change will tighten deps a lot,
while we might be able to simply catch these with more QA / cleaner
transitions.
One similar issue in Debian I have in mind is when we have two versions
of a library, and a complex set of dependencies load them together in
memory; we want to avoid this, but it's not easy to enforce via deps.
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote: This would mean we'd need to split e.g. python-gtk2 into five. Do we really want that? The should wording allowed one to not do it in special cases. I'm not saying we shouldn't change it, but we should make sure we're aware of all the consequences of the change... How about the new attached patch, Require the python- prefix for public modules? -- Loïc Minier From 95d0258fb8513078ccb3eb496a7867c16de4f747 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@dooz.org Date: Fri, 11 Dec 2009 11:00:24 +0100 Subject: [PATCH 28/30] Require the python- prefix for public modules Require the python- prefix for packages shipping public modules used by other packages, and recommend using python-foo for public modules in general but allow for package shipping multiple modules; thanks Luca Falavigna and Emilio Pozuelo Monfort. --- debian/python-policy.sgml | 23 +++ 1 files changed, 15 insertions(+), 8 deletions(-) diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml index e8d7e3a..bdbc541 100644 --- a/debian/python-policy.sgml +++ b/debian/python-policy.sgml @@ -387,14 +387,21 @@ sect id=package_names headingModule Package Names/heading p - Public modules should have a binary package named - packagepython-varfoo/var/package, - where varfoo/var is the name of the module. Such a - package should support the current Debian Python version, - and more if possible (there are several tools to help - implement this, see ref id=packaging_tools). For - example, if Python 2.3, 2.4, and 2.5 are supported, the - Python command + Public modules used by other packages must have their binary + package name prefixed with varpython-/var. It is recommended + to use this prefix for all packages with public modules as they be + used by other packages in the future. + + The binary package for module foo should preferably be named + packagepython-varfoo/var/package, if the module name + allows, but this is not required if the binary package ships + multiple modules. In the latter case the maintainer choses the + name of the module which represents the package the most. + + Such a package should support the current Debian Python version, + and more if possible (there are several tools to help implement + this, see ref id=packaging_tools). For example, if Python 2.3, + 2.4, and 2.5 are supported, the Python command example import foo /example -- 1.6.5
Re: RFC: Proposed updates to the Python Policy to reflect current practices
Loïc Minier wrote: On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote: This would mean we'd need to split e.g. python-gtk2 into five. Do we really want that? The should wording allowed one to not do it in special cases. I'm not saying we shouldn't change it, but we should make sure we're aware of all the consequences of the change... How about the new attached patch, Require the python- prefix for public modules? Looks fine to me, but 3.1 needs to be updated too since it currently says that a package that needs `foo' must depend on `python-foo', which may not be correct anymore with this patch. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: RFC: Proposed updates to the Python Policy to reflect current practices
* Loïc Minier l...@dooz.org, 2009-12-11, 12:34: url id=http://www.gnu.org/copyleft/gpl.html; - name=The GNU Public Licence. + name=The GNU Public License. That should read: The GNU General Public License. - explicitly use the versioned interpreter name + explicitly use the version-ed interpreter name Huh? versioned might not be recorded by dictionaries, but it is a common term in Debian-related documentation: $ zcat /usr/share/doc/debian-policy/*.txt.gz | grep -wc versioned 8 $ zcat /usr/share/doc/developers-reference/*.txt.gz | grep -wc versioned 4 Besides, version-ed is ugly as hell. -- Jakub Wilk signature.asc Description: Digital signature
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote:
Looks fine to me, but 3.1 needs to be updated too since it currently says
that a
package that needs `foo' must depend on `python-foo', which may not be correct
anymore with this patch.
Ack
--
Loïc Minier
From ef9d6552930015aec0a9cb5a0b3d6bb5d2870f96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@dooz.org
Date: Fri, 11 Dec 2009 11:00:24 +0100
Subject: [PATCH 28/30] Require the python- prefix for public modules
Require the python- prefix for packages shipping public modules used by
other packages, and recommend using python-foo for public modules in
general but allow for package shipping multiple modules; thanks Luca
Falavigna and Emilio Pozuelo Monfort.
---
debian/python-policy.sgml | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml
index c49957d..d9cf0dd 100644
--- a/debian/python-policy.sgml
+++ b/debian/python-policy.sgml
@@ -387,14 +387,21 @@
sect id=package_names
headingModule Package Names/heading
p
- Public modules should have a binary package named
- packagepython-varfoo/var/package,
- where varfoo/var is the name of the module. Such a
- package should support the current Debian Python version,
- and more if possible (there are several tools to help
- implement this, see ref id=packaging_tools). For
- example, if Python 2.3, 2.4, and 2.5 are supported, the
- Python command
+ Public modules used by other packages must have their binary
+ package name prefixed with varpython-/var. It is recommended
+ to use this prefix for all packages with public modules as they be
+ used by other packages in the future.
+
+ The binary package for module foo should preferably be named
+ packagepython-varfoo/var/package, if the module name
+ allows, but this is not required if the binary package ships
+ multiple modules. In the latter case the maintainer choses the
+ name of the module which represents the package the most.
+
+ Such a package should support the current Debian Python version,
+ and more if possible (there are several tools to help implement
+ this, see ref id=packaging_tools). For example, if Python 2.3,
+ 2.4, and 2.5 are supported, the Python command
example
import foo
/example
@@ -536,7 +543,9 @@ XB-Python-Version: ${python:Versions}
/p
p
If the program needs the python module ttfoo/tt,
- it must depend on packagepython-foo/package.
+ it must depend on the real package providing this module, usually
+ packagepython-foo/package but this name might vary when the
+ package ships multiple modules.
/p
sect1 id=current_version_progs
--
1.6.5
Re: RFC: Proposed updates to the Python Policy to reflect current practices
Loïc Minier wrote: On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote: Looks fine to me, but 3.1 needs to be updated too since it currently says that a package that needs `foo' must depend on `python-foo', which may not be correct anymore with this patch. Ack Looks good, thanks! Emilio signature.asc Description: OpenPGP digital signature
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Fri, Dec 11, 2009 at 11:04:32AM +0100, Loïc Minier wrote: On Wed, Dec 09, 2009, Luca Falavigna wrote: I entirely read the 1.9.0.0 draft, I've got some thoughts on it. Thanks for your review, I'm attaching the following new patches: s/binary/interpreter for /usr/bin/python* I think this is a policy regression, actually. The fact that /usr/bin/python2.x is a binary, and /usr/bin/python is a symlink pointing to a binary, is not irrelevant - we certainly don't want someone to get the idea that it's ok to replace either of these with a script... So I would revert the first chunk, and for the second chunk change it to: @@ -153,7 +154,8 @@ /p p At any time, the packagepython/package package must ensure - that the binary file/usr/bin/python/file is provided. + that file/usr/bin/python/file is provided as a symlink to the + current filepythonvarX/var.varY/var/file executable. The packagepython/package package must also depend on the appropriate packagepythonvarX/var.varY/var/package to -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: RFC: Proposed updates to the Python Policy to reflect current practices
2009/12/9 Loïc Minier l...@dooz.org: On Wed, Dec 09, 2009, Dmitrijs Ledkovs wrote: Where is this git repository hosted? Or where can I get the current version of the policy as seen on the debian.org website? Concerning the Python Policy, it's currently not handled in any VCS, so I created a private git repo from the uploads of the python-defaults package (which I found in the morgue) and committed the proposed changes on top of that. I can provide a copy of the repo to you, but it's not in any way an official repo for the python-defaults package or the policy. -- Loďc Minier Yes please! I'm struggling to read the patches like that I'd rather read git annotate =) which would be proposed final but with info where the words came from (patches or old stuff) Thanks. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Fri, Dec 11, 2009, Steve Langasek wrote: I think this is a policy regression, actually. The fact that /usr/bin/python2.x is a binary, and /usr/bin/python is a symlink pointing to a binary, is not irrelevant - we certainly don't want someone to get the idea that it's ok to replace either of these with a script... So I would revert the first chunk, and for the second chunk change it to: @@ -153,7 +154,8 @@ /p p At any time, the packagepython/package package must ensure - that the binary file/usr/bin/python/file is provided. + that file/usr/bin/python/file is provided as a symlink to the + current filepythonvarX/var.varY/var/file executable. The packagepython/package package must also depend on the appropriate packagepythonvarX/var.varY/var/package to Thanks, I merged something close; patch attached -- Loïc Minier From b4764801ece55036695e6d380ee5732986a0bf56 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@dooz.org Date: Fri, 11 Dec 2009 10:13:52 +0100 Subject: [PATCH 26/30] Clarify which files are provided Clarify that pythonX.Y provides a /usr/bin/pythonX.Y interpreter binary and that python provides a /usr/bin/python symlink to the current pythonX.Y executable. --- debian/python-policy.sgml |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml index 804effc..7ba6a14 100644 --- a/debian/python-policy.sgml +++ b/debian/python-policy.sgml @@ -135,8 +135,9 @@ For every Python version provided in the distribution, the package packagepythonvarX/var.varY/var/package shall provide a complete distribution for emdeployment/em of Python scripts - and applications. The package must ensure that the binary - file/usr/bin/pythonvarX/var.varY/var/file is provided. + and applications. The package must ensure that the + file/usr/bin/pythonvarX/var.varY/var/file interpreter + executable is provided. /p p Installation of packagepythonvarX/var.varY/var/package @@ -153,7 +154,8 @@ /p p At any time, the packagepython/package package must ensure - that the binary file/usr/bin/python/file is provided. + that file/usr/bin/python/file is provided as a symlink to the + current filepythonvarX/var.varY/var/file executable. The packagepython/package package must also depend on the appropriate packagepythonvarX/var.varY/var/package to -- 1.6.5
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Fri, Dec 11, 2009, Dmitrijs Ledkovs wrote: 2009/12/9 Loïc Minier l...@dooz.org: On Wed, Dec 09, 2009, Dmitrijs Ledkovs wrote: Where is this git repository hosted? Or where can I get the current version of the policy as seen on the debian.org website? Concerning the Python Policy, it's currently not handled in any VCS, so I created a private git repo from the uploads of the python-defaults package (which I found in the morgue) and committed the proposed changes on top of that. I can provide a copy of the repo to you, but it's not in any way an official repo for the python-defaults package or the policy. -- Loďc Minier Yes please! I'm struggling to read the patches like that I'd rather read git annotate =) which would be proposed final but with info where the words came from (patches or old stuff) Pushed as git.debian.org:~lool/public_git/python-defaults.git if you want to use ssh with an alioth account, or git://git.debian.org/~lool/python-defaults.git otherwise -- Loïc Minier -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Final updates for this Python Policy revision
I think we are at the point where the proposed update to the Python Policy is clearly more relevant and better than what is currently published. Once this is done, we can work on refinements. Loïc Minier (lool) did attempt to send the proposed final patch set to the list and it has gotten stuck somewhere and didn't make it to the list. Rather than wait to get that resolved, I'll point you at the git repository Loïc mentioned earlier: Pushed as git.debian.org:~lool/public_git/python-defaults.git if you want to use ssh with an alioth account, or git://git.debian.org/~lool/python-defaults.git otherwise The only other change I've made is to revert the first hunk of 0026-Clarify- which-files-are-provided.patch. Once we hit a time where we are both awake, I'll get git updated. I'm preparing an upload of python-defaults to publish this and unless I hear screams will do it as soon as I can get the package assembled and the maintainer's blessing (I have worked on this already and don't anticipate a problem). Scott K signature.asc Description: This is a digitally signed message part.
