Re: python-policy source

[Dmitry Shachnev]

Hi Geert!

On Sun, Jul 05, 2020 at 07:05:28PM +0200, Geert Stappers wrote:
> Hi,
>
> Where to find the source of python-policy?

I believe it is here:

https://salsa.debian.org/cpython-team/python3-defaults/-/blob/master/debian/python-policy.dbk

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Re: Python Policy: Things to consider for Stretch

[Ben Finney]

Scott Kitterman  writes:

> On Tuesday, February 02, 2016 06:44:57 AM Ben Finney wrote:
> > Ben Finney  writes:
> > > * Address all the language around Python 2 versus Python 3 versus
> > > Python general, and re-order or re-word to focus *primarily* on
> > > Python 3, with Python 2 treated as the still-supported legacy
> > > system.
>
> I've merged these changes. I have a little bit of adjustment I want to
> do on top of it, but this helps a lot. Thanks,

You're welcome, and thank you for working to get this in.

-- 
 \“All opinions are not equal. Some are a very great deal more |
  `\   robust, sophisticated, and well supported in logic and argument |
_o__) than others.” —Douglas Adams |
Ben Finney

Re: Python Policy: Things to consider for Stretch

[Barry Warsaw]

On Feb 16, 2016, at 11:54 AM, Paul Wise wrote:

>I always thought it strange to put site- in /usr/local since
>/usr/local already implies site/system-wide packages. Same for dist-
>since /usr already implies distribution packages.

For as long as I can remember, a from-source 'configure && make && make
install' always put Python in /usr/local by default.  I think it was pretty
much the defacto standard for non-vendor supplied software[*] back in the days
of IRIX, SunOS, and other early *nix OSes that Python was developed on.  So it
was therefore completely natural that you'd end up with a site-packages in
/usr/local.  It was only later that the /usr/local site-packages directory
ended up on a /usr pathed distro-provided Python, which of course led to the
previously discussed dist-packages, the location of which completely mirrors
site-packages.

>I find it weird that site- gets used in ~/ since they are clearly user
>packages not site/system-wide packages.

It's all just a big ball of cruft-on-cruft with backward compatibility
preventing most cullings.  Somewhere out there, the entire world financial
system probably still critically depends on a tiny bit of Python 1.3 that
nobody has anything but the .pyc files for any more. ;)

Cheers,
-Barry

[*] I can't even call it Free Software or Open Source because it predates
those terms.  I mean, I started out sharing split shar files on Usenet with my
UUCP address.  ObGOML.

Re: Python Policy: Things to consider for Stretch

[Paul Wise]

On Tue, Feb 16, 2016 at 11:42 AM, Barry Warsaw wrote:

> I don't remember exactly why we called it 'site-packages' ...

Thanks for the history :)

I always thought it strange to put site- in /usr/local since
/usr/local already implies site/system-wide packages. Same for dist-
since /usr already implies distribution packages. I find it weird that
site- gets used in ~/ since they are clearly user packages not
site/system-wide packages.

Any thoughts on that?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Python Policy: Things to consider for Stretch

[Barry Warsaw]

On Feb 15, 2016, at 07:42 PM, Barry Warsaw wrote:

>I don't remember exactly why we called it 'site-packages', but I believe it
>was an evolution from the earlier ni.py module, which was where dotted module
>paths first showed up in Python.

And which had a 'site-python' directory, which was kept at least for Python
1.5 also.

Cheers,
-Barry

Re: Python Policy: Things to consider for Stretch

[Ben Finney]

Ben Finney  writes:

> * Address all the language around Python 2 versus Python 3 versus
>   Python general, and re-order or re-word to focus *primarily* on Python
>   3, with Python 2 treated as the still-supported legacy system.
>
> I'm maintaining a Bazaar branch for this, feel free to get it::
>
> $ mkdir python.benfinney/ && cd python.benfinney/
> $ bzr branch --bind 
> http://vcs.whitetree.org/bzr/public/debian/python/python-defaults-debian/devel/

Ben Finney  writes:

> Thank you, Scott! I'll proceed with the semantic changes that promote
> Python 3 to the primary position.

Those changes are now in the above branch. The summary of changes from
the commit messages:

$ bzr log --log-format line --revision ancestor:..
430: Ben Finney 2016-02-02 Re-phrase version distinctions to make Python 3 
primary.
429: Ben Finney 2016-02-01 When only Python 2 is specified, just use 
literal “2” major version.
428: Ben Finney 2016-02-01 Use Python 3 examples where appropriate.
427: Ben Finney 2016-01-31 Refine some grammar and punctuation.
426: Ben Finney 2016-01-31 Distinguish “Python” the unversioned system 
versus “Python 2”.
425: Ben Finney 2016-01-30 [merge] Merge from ‘python-defaults-debian’ 
mainline.

Also attached to this message as a Bazaar patch bundle.
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ben+deb...@benfinney.id.au-20160201192807-\
#   7ux9dchggw9s8znh
# target_branch: bzr+ssh://bzr.debian.org/bzr/pkg-python/python-\
#   defaults-debian/
# testament_sha1: 6a28ebdd010851ced1dfe1087d61b9a1dbded494
# timestamp: 2016-02-02 06:36:06 +1100
# base_revision_id: sc...@kitterman.com-20160129221800-\
#   kkxuexf3v28q9ro0
# 
# Begin patch
=== modified file 'debian/python-policy.sgml'
--- debian/python-policy.sgml	revid:sc...@kitterman.com-20160129221800-kkxuexf3v28q9ro0
+++ debian/python-policy.sgml	revid:ben+deb...@benfinney.id.au-20160201192807-7ux9dchggw9s8znh
@@ -84,10 +84,12 @@
 
   On the move to Python 3
 	
-	  Debian currently supports two Python stacks, one for Python 2
-	  and one for Python 3.  The long term goal for Debian is to
+	  Debian currently supports two Python stacks, one for Python 3
+	  and one for Python 2.  The long term goal for Debian is to
 	  reduce this to one stack, dropping the Python 2 stack at some
 	  time.
+	
+	
 	  https://www.python.org/dev/peps/pep-0404/;
 	  name="PEP 404"> states that no more major Python 2 releases
 	  are planned, although the latest released minor version 2.7
@@ -112,10 +114,10 @@
 	  
 	  
 	
-	  Python libraries should be always packaged for Python 3
-	  if supported.  Python 2 libraries should be packaged, if
-	  applications found in the reverse dependencies are not
-	  yet supported by Python 3.
+	  Python libraries, if they support Python 3, should be always
+	  packaged for Python 3. If an application supports only Python
+	  2, the Python libraries for that application should also be
+	  packaged for Python 2.
 	
 	  
 	  
@@ -133,12 +135,12 @@
   
 	Versions
 	
-	  At any given time, the binary package python
-	  will represent the current default Debian Python version. The
-	  binary package python3 will represent the
-	  current Debian Python 3 version. As far as is reasonable, Python
-	  and Python 3 should be treated as separate runtime systems with
-	  minimal interdependencies.
+	  At any given time, the binary package python3
+	  will represent the current default Debian Python 3 version; the
+	  binary package python will represent the
+	  current default Debian Python 2 version. As far as is reasonable,
+	  Python 3 and Python 2 should be treated as separate runtime
+	  systems with minimal interdependencies.
 	
 	
 	  In some cases, Python policy explicitly references Python helper
@@ -150,15 +152,17 @@
 	  It is a design goal to fully specify required interfaces and
 	  functions in policy for Python 3 and to avoid enshrining specific
 	  implementation details in policy. Except as noted, policy for
-	  Python 3 is the same as Python with the addition of the version
-	  number as needed to distinguish them.
-	
-	
-	  The default Debian Python version should always be the latest
-	  stable upstream version that can be fully integrated in Debian.
+	  Python 2 is the same as Python 3 with the exception of the
+	  different major version number as needed to distinguish them.
+	
+	
+	  The default Debian Python version, for each of Python 3 and Python
+	  2, should always be the latest stable upstream version that can be
+	  fully integrated in Debian.
+	
+	
 	  There may be newer supported or unsupported versions included in
-	  the Debian if they are not fully integrated for a particular
-	  release.
+	  Debian if they are not fully integrated for a particular release.
 	
 	
 	  Apart from the default version, legacy versions of Python or beta
@@ -178,17 +182,17 @@
 	
 

Re: Python Policy: Things to consider for Stretch

[Scott Kitterman]

On Tuesday, January 26, 2016 04:46:19 PM Ben Finney wrote:
...
>   Once these non-semantic changes are accepted I will begin work on the
>   second stage of semantic changes.
...

OK.  Those are all accepted.  Barry Warsaw had done some changes in the -whl 
section so I made an attempt at merging what the two of you had done.

Thanks,

Scott K

Re: Python Policy: Things to consider for Stretch

[Ben Finney]

Scott Kitterman  writes:

> On Tuesday, January 26, 2016 04:46:19 PM Ben Finney wrote:
> ...
> >   Once these non-semantic changes are accepted I will begin work on
> >   the second stage of semantic changes.
> ...
>
> OK.  Those are all accepted.

Thank you, Scott! I'll proceed with the semantic changes that promote
Python 3 to the primary position.

> Barry Warsaw had done some changes in the -whl section so I made an
> attempt at merging what the two of you had done.

That attempt clobbered my earlier changes in that area. I'll restore
them and preserve Barry's intention.

I should have some more changes to present in a day or two.

-- 
 \  “The best mind-altering drug is truth.” —Jane Wagner, via Lily |
  `\Tomlin |
_o__)  |
Ben Finney

Re: Python Policy: Things to consider for Stretch

[Ben Finney]

Scott Kitterman  writes:

> I should be able to get it reviewed and merged no later than Saturday
> (probably Friday).

Much appreciated, thanks for the response.

-- 
 \“When I was a baby I kept a diary. Recently I was re-reading |
  `\   it, it said ‘Day 1: Still tired from the move. Day 2: Everybody |
_o__)  talks to me like I'm an idiot.’” —Steven Wright |
Ben Finney

Re: Python Policy: Things to consider for Stretch

[Scott Kitterman]

On January 26, 2016 10:32:57 PM EST, Ben Finney  
wrote:
>Dmitry Shachnev  writes:
>
>> On Tue, Jan 26, 2016 at 04:46:19PM +1100, Ben Finney wrote:
>> > I'm planning to provide changes in two bundles:
>> >
>> > * Go through the whole document and tidy it up for consistency,
>> >   source style, markup, and language style. This should not change
>> >   the meaning of anything, but will change the wording of numerous
>> >   passages.
>> >
>> >   My proposal for that is attached here as a Bazaar change bundle.
>>
>> Thanks for your work here, your changes look nice to me!
>
>Thank you. Are you in a position to do me the favour of merging the
>bundle into the repository ‘pkg-python/python-defaults-debian/’ at
>Alioth?

Only one of the package maintainers can do that.  I'm very busy with $work at 
the moment, but I should be able to get it reviewed and merged no later than 
Saturday (probably Friday).

Scott K

Re: Python Policy: Things to consider for Stretch

[Dmitry Shachnev]

Hi Ben,

On Tue, Jan 26, 2016 at 04:46:19PM +1100, Ben Finney wrote:
> I'm planning to provide changes in two bundles:
>
> * Go through the whole document and tidy it up for consistency, source
>   style, markup, and language style. This should not change the meaning
>   of anything, but will change the wording of numerous passages.
>
>   My proposal for that is attached here as a Bazaar change bundle.
>
> * Address all the language around Python 2 versus Python 3 versus Python
>   general, and re-order or re-word to focus *primarily* on Python 3,
>   with Python 2 treated as the still-supported legacy system.
>
>   Once these non-semantic changes are accepted I will begin work on the
>   second stage of semantic changes.
>
> I'm maintaining a Bazaar branch for this, feel free to get it::
>
> $ mkdir python.benfinney/ && cd python.benfinney/
> $ bzr branch --bind 
> http://vcs.whitetree.org/bzr/public/debian/python/python-defaults-debian/devel/

Thanks for your work here, your changes look nice to me!

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Re: Python Policy: Things to consider for Stretch

[Ben Finney]

Dmitry Shachnev  writes:

> On Tue, Jan 26, 2016 at 04:46:19PM +1100, Ben Finney wrote:
> > I'm planning to provide changes in two bundles:
> >
> > * Go through the whole document and tidy it up for consistency,
> >   source style, markup, and language style. This should not change
> >   the meaning of anything, but will change the wording of numerous
> >   passages.
> >
> >   My proposal for that is attached here as a Bazaar change bundle.
>
> Thanks for your work here, your changes look nice to me!

Thank you. Are you in a position to do me the favour of merging the
bundle into the repository ‘pkg-python/python-defaults-debian/’ at
Alioth?

-- 
 \ “Money is always to be found when men are to be sent to the |
  `\   frontiers to be destroyed: when the object is to preserve them, |
_o__) it is no longer so.” —Voltaire, _Dictionnaire Philosophique_ |
Ben Finney

Re: Python Policy: Things to consider for Stretch

[Ben Finney]

Ben Finney  writes:

> Scott Kitterman  writes:
>
> > At this point I think internal consistency is probably more
> > important, so if someone wants to go through and make all the
> > python's that should be python2, etc then please send in a patch.
>
> I'll take that on.

I'm planning to provide changes in two bundles:

* Go through the whole document and tidy it up for consistency, source
  style, markup, and language style. This should not change the meaning
  of anything, but will change the wording of numerous passages.

  My proposal for that is attached here as a Bazaar change bundle.

* Address all the language around Python 2 versus Python 3 versus Python
  general, and re-order or re-word to focus *primarily* on Python 3,
  with Python 2 treated as the still-supported legacy system.

  Once these non-semantic changes are accepted I will begin work on the
  second stage of semantic changes.

I'm maintaining a Bazaar branch for this, feel free to get it::

$ mkdir python.benfinney/ && cd python.benfinney/
$ bzr branch --bind 
http://vcs.whitetree.org/bzr/public/debian/python/python-defaults-debian/devel/

Currently the log of changes since the ‘pkg-python’ repository (as
included in the attached change bundle) looks like::

$ cd devel/
$ bzr log --log-format line --revision ancestor:..
424: Ben Finney 2016-01-26 Clarify what text is literal names.
423: Ben Finney 2016-01-26 Update copyright notice.
422: Ben Finney 2016-01-26 Refine markup for a compact list.
421: Ben Finney 2016-01-26 Clarify what names are filesystem paths.
420: Ben Finney 2016-01-26 Clarify what names are Debian packages.
419: Ben Finney 2016-01-26 Specify GPLv2 documents explicitly.
418: Ben Finney 2016-01-26 Update external URLs to be current, and use 
HTTPS.
417: Ben Finney 2016-01-25 Use consistent terminology for “distribution”, 
“version”, “release”.
416: Ben Finney 2016-01-25 Avoid literal ‘<’ and ‘>’, use SGML character 
entities.
415: Ben Finney 2016-01-25 Distinguish “Python” the system versus “python” 
the command.
414: Ben Finney 2016-01-25 Add myself to the document's authors.
413: Ben Finney 2016-01-25 Correct whitespace to conform to Policy style.
412: Ben Finney 2016-01-25 Add editor hints to match Debian Policy text 
style.
411: Scott Kitterman 2016-01-24 Python policy updates (draft) for Stretch 
DO NOT UPLOAD YET:wq

# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ben+deb...@benfinney.id.au-20160126051103-\
#   3zbuoy0u0vp14w5d
# target_branch: bzr+ssh://bzr.debian.org/bzr/pkg-python/python-\
#   defaults-debian/
# testament_sha1: 765dacf10bafece44db129db818e74a4d0814c0e
# timestamp: 2016-01-26 16:43:48 +1100
# source_branch: http://vcs.whitetree.org/bzr/public/debian/python\
#   /python-defaults-debian/devel/
# base_revision_id: sc...@kitterman.com-20160124060119-\
#   e07prikr3oa8bkbn
# 
# Begin patch
=== modified file 'debian/python-policy.sgml'
--- debian/python-policy.sgml	revid:sc...@kitterman.com-20160124060119-e07prikr3oa8bkbn
+++ debian/python-policy.sgml	revid:ben+deb...@benfinney.id.au-20160126051103-3zbuoy0u0vp14w5d
@@ -17,24 +17,28 @@
 	fli...@debian.org
   
   
-Josselin Mouette
+	Josselin Mouette
 	j...@debian.org
   
   
-Joe Wreschnig
+	Joe Wreschnig
 	pi...@debian.org
   
   
-Loc Minier
+	Loc Minier
 	l...@debian.org
   
   
-Scott Kitterman
+	Scott Kitterman
 	sc...@kitterman.com
   
   
-Barry Warsaw
-ba...@debian.org
+	Barry Warsaw
+	ba...@debian.org
+  
+  
+	Ben Finney
+	ben+deb...@benfinney.id.au
   
   version 0.10.1.0
 
@@ -46,7 +50,7 @@
 
   
 	
-	  Copyright  19992014 Software in the Public Interest
+	  Copyright  19992016 Software in the Public Interest
 	
 	
 	  This manual is free software; you can redistribute it and/or
@@ -61,11 +65,11 @@
 	  the GNU General Public License for more details.
 	
 	
-	  A copy of the GNU General Public License is available as
-	  /usr/share/common-licences/GPL in the Debian GNU/Linux
-	  distribution or on the World Wide Web at
-	  http://www.gnu.org/copyleft/gpl.html;
-	  name="The GNU General Public License">.
+	  A copy of the GNU General Public License version 2 is available as
+	  /usr/share/common-licences/GPL-2 in the Debian
+	  GNU/Linux system, or on the World Wide Web at
+	  https://www.gnu.org/licenses/old-licenses/gpl-2.0.html;
+	  name="GNU General Public License, version 2">.
 	
 	
 	  You can also obtain it by writing to the
@@ -83,12 +87,12 @@
 	  Debian currently supports two Python stacks, one for Python 2
 	  and one for Python 3.  The long term goal for Debian is to
 	  reduce this to one stack, dropping the Python 2 stack at some
-	  time.  
-	  http://legacy.python.org/dev/peps/pep-0404/;
+	  time.
+	  https://www.python.org/dev/peps/pep-0404/;
 	  name="PEP 404"> states that no more 

Re: Python Policy: Things to consider for Stretch

[Ben Finney]

Ben Finney  writes:

> I'm planning to provide changes in two bundles:
>
> * Go through the whole document and tidy it up for consistency, source
>   style, markup, and language style. This should not change the meaning
>   of anything, but will change the wording of numerous passages.
>
>   My proposal for that is attached here as a Bazaar change bundle.
>
> * Address all the language around Python 2 versus Python 3 versus Python
>   general, and re-order or re-word to focus *primarily* on Python 3,
>   with Python 2 treated as the still-supported legacy system.
>
>   Once these non-semantic changes are accepted I will begin work on the
>   second stage of semantic changes.

That last sentence isn't very clear. What I intended to imply is:

The first stage is done and all its changes are in the branch, the
second stage I haven't yet started.

The set of revision in the “r411–r424” patch bundle is all intended to
be non-semantic changes, and once they're accepted I'll begin on the
second, semantic-changing, stage of work.

-- 
 \“I don't accept the currently fashionable assertion that any |
  `\   view is automatically as worthy of respect as any equal and |
_o__)   opposite view.” —Douglas Adams |
Ben Finney

Re: Python Policy: Things to consider for Stretch

[Ben Finney]

Scott Kitterman  writes:

> On Sunday, January 24, 2016 04:58:26 PM Ben Finney wrote:
> > Found it; the source document is ‘python-policy.sgml’ in the source
> > VCS for ‘python3’. Currently that's a Bazaar repository at
> > .
>
> That's correct.

Hmm, apparently I've got the wrong thing. I've got changes from you,
most recently 2016-01-11; followed by later changes as recent as
2016-01-18:

=
$ bzr info
Repository checkout (format: 2a)
Location:
  repository checkout root: 
/home/bignose/Projects/debian/python3/python3-defaults-debian/trunk
checkout of branch: 
bzr+ssh://bzr.debian.org/bzr/pkg-python/python3-defaults-debian/
[…]

$ bzr log --log-format=line --limit 3
340: Matthias Klose 2016-01-18 - drop python3.4 from the defaults
339: Matthias Klose 2016-01-17 * Drop Python 3.4 as a supported python3 version.
338: Scott Kitterman 2016-01-11 {3.5.1-1} Upload to unstable
=

But the ‘debian/python-policy.sgml’ document has a version:

=
$ grep '' debian/python-policy.sgml 
  version 0.4.1.0
=

which doesn't match what you showed (containing “version 0.10.1.0”) at
.

What am I missing? Is there a different repository or branch I need to
use?

-- 
 \ “Capitalism has destroyed our belief in any effective power but |
  `\  that of self interest backed by force.” —George Bernard Shaw |
_o__)  |
Ben Finney

Re: Python Policy: Things to consider for Stretch

[Scott Kitterman]

On January 24, 2016 11:59:14 PM EST, Ben Finney  
wrote:
>Scott Kitterman  writes:
>
>> On Sunday, January 24, 2016 04:58:26 PM Ben Finney wrote:
>> > Found it; the source document is ‘python-policy.sgml’ in the source
>> > VCS for ‘python3’. Currently that's a Bazaar repository at
>> >
>.
>>
>> That's correct.
>
>Hmm, apparently I've got the wrong thing. I've got changes from you,
>most recently 2016-01-11; followed by later changes as recent as
>2016-01-18:
>
>=
>$ bzr info
>Repository checkout (format: 2a)
>Location:
>repository checkout root:
>/home/bignose/Projects/debian/python3/python3-defaults-debian/trunk
>checkout of branch:
>bzr+ssh://bzr.debian.org/bzr/pkg-python/python3-defaults-debian/
>[…]
>
>$ bzr log --log-format=line --limit 3
>340: Matthias Klose 2016-01-18 - drop python3.4 from the defaults
>339: Matthias Klose 2016-01-17 * Drop Python 3.4 as a supported python3
>version.
>338: Scott Kitterman 2016-01-11 {3.5.1-1} Upload to unstable
>=
>
>But the ‘debian/python-policy.sgml’ document has a version:
>
>=
>$ grep '' debian/python-policy.sgml 
>  version 0.4.1.0
>=
>
>which doesn't match what you showed (containing “version 0.10.1.0”) at
>.
>
>What am I missing? Is there a different repository or branch I need to
>use?

Python-defaults, not python3-defaults.

Scott K

Re: Python Policy: Things to consider for Stretch

[Barry Warsaw]

Thanks for taking this on Ben,

On Jan 24, 2016, at 04:33 PM, Ben Finney wrote:

>I think you're right that this needs a general clean-up through the
>policy document, to consistently use:
>
>* “python2” to refer to that command only;
>
>* “python3” to refer to that command only;
>
>* “python” to refer to that command (and I'd suggest deprecating it
>  where feasible);
>
>* “Python 2” referring exclusively to that language version 2.x and no
>  other versions of that language;
>
>* “Python 3” referring exclusively to that language version 3.x and no
>  other versions of that language;
>
>* “Python” referring to the language implemented either as Python 2 or
>  Python 3.

I agree with all the above, though re: Scott's feedback on deprecation of
/usr/bin/python, here's my take (note, we've had these discussions many times
before ;).

Ultimately, we should be both guided by, and drive with our opinions, PEP 394
which should help keep the situation consistent across *nix distros.

https://www.python.org/dev/peps/pep-0394/

/usr/bin/python (on Debian) should never point to anything but the latest
Python 2 version *until* Python 2.7 is EOL'd upstream, meaning binary, source,
and security-only releases.  Bug fix releases (source only) are promised until
2020, and I'd wager we'll see supported security-only releases until 2025.

I would like to see scripts that are only compatible with Python 2 to be
shebanged `/usr/bin/python2` or `/usr/bin/python2.7`.  You can think of this
mostly as documentation at this point, but it does remove any possibility of
future ambiguity.

It also begins to open the door to the often discussed launcher idea someday
landing on /usr/bin/python, enabling bilingual scripts.

I think there's zero harm in this since shebang lines are generally not
user-evident.

Then there's no change to /usr/bin/python any time soon, or the fact that
invoking `python` at the shell starts the Python 2 interpreter.

Cheers,
-Barry

Re: Python Policy: Things to consider for Stretch

[Scott Kitterman]

On Friday, January 22, 2016 05:55:19 PM Barry Warsaw wrote:
> On Jan 21, 2016, at 10:47 AM, Scott Kitterman wrote:
> >I've taken a run through the current Python Policy to see where I think it
> >needs to be updated for Stretch.
> 
> Thanks Scott for the badly needed update.
> 
> Some comments, apologies for the lack of good quoting, or if I've read the
> diff incorrectly.
> 
> 2.5 Module Path
> 
> "Public Python modules must be installed in the system Python modules
> directory, /usr/lib/python./dist-packages.  Public Python 3 modules
> must be installed in /usr/lib/python3/dist-packages."
> 
> I think this could use a bit of disambiguation, sice "system Python modules"
> could mean either Python generically, in which case the second sentence is
> in conflict.  Do you mean "system Python 2 modules"?  If so, let's say
> that. Also, since Python 2.7 is all there will be from now on, why not say
> that explicitly?

Personally I seriously dislike the trend to call Python Python 2 (and I still 
thing approving a pep to invent /usr/bin/python2 because Arch went insane was 
a horrible idea).  There's an earlier spot in the document where it says that 
everything refers to python and python3 unless it's explicit.  I'll make this 
spot /usr/lib/python2.7/dist-packages and any risk of ambiguity is, I think, 
resolved.

> A good reason not to would be because Policy needs to cover older releases
> where there can be multiple versions of Python 2.  But then later in your
> diff you seem to mention python2.7 as being associated with
> /usr/local/lib/python2./dist-packages.  So maybe say
> /usr/local/lib/python2.7/dist-packages here too?  There really won't be any
> other value for  than 7.

We only need (I think) to cover packages being developed for the release the 
policy is for.  Squeeze was the last multi-python version release, so I think 
we're safe to remove python2. where way may not always be 7.

> 3.4 Specifying Supported Versions
> 
> "The optional `X-Python-Version (preferred) or `XS-Python-Version` field..."
> 
> It's a little confusing because we're now saying we prefer not to have
> either field.  How about "(previously preferred)" or just drop the
> parenthetical?

Makes sense.  I'll do that.

> 3.6 Provides
> 
> s/substituation/substitution/

Thanks.

> B.2. dh_python2 and dh_python3
> 
> Again, I think here you want to say "Python2 and Python3" to disambiguate
> between generic Python.

If I say Python and Python3, what version can the one that's not Python3 
possibly be?  I don't think it's any less confusing than starting to call what 
we've always called "Python" "Python 2".

> Other than that, +1

Thanks for reviewing.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: Python Policy: Things to consider for Stretch

[Scott Kitterman]

On Saturday, January 23, 2016 08:50:49 PM Barry Warsaw wrote:
> On Jan 23, 2016, at 03:38 AM, Scott Kitterman wrote:
> >Personally I seriously dislike the trend to call Python Python 2 (and I
> >still thing approving a pep to invent /usr/bin/python2 because Arch went
> >insane was a horrible idea).  There's an earlier spot in the document
> >where it says that everything refers to python and python3 unless it's
> >explicit.  I'll make this spot /usr/lib/python2.7/dist-packages and any
> >risk of ambiguity is, I think, resolved.
> 
> I'll leave it to you, but my take on it is that "Python" is the generic term
> for the language and its specification.  "Python 2" v "Python 3" provides
> disambiguation when you're talking about specific major versions of the
> language.  "Python 3.5" and such usually describe specific releases of the
> CPython interpreter implementation (note how "CPython" is used to
> disambiguate between alternative implementations of the language
> specification).  Finally, python2.7, python3.4 and such are used to
> describe the executables that provide the versions (e.g. mentally prepend
> them with /usr/bin).
> 
> All of this, except the last point perhaps, is orthogonal to the
> /usr/bin/python2 issue you mention.
> 
> Back to the original point, to me saying "Python" and "Python 3" is
> confusing or misleading, given the above definitions.  It's confusing
> because "Python 3" *is* Python, so what's the difference?  It's misleading
> because it implies that somehow "Python 3" isn't "Python".
> 
> >> B.2. dh_python2 and dh_python3
> >> 
> >> Again, I think here you want to say "Python2 and Python3" to disambiguate
> >> between generic Python.
> >
> >If I say Python and Python3, what version can the one that's not Python3
> >possibly be?  I don't think it's any less confusing than starting to call
> >what we've always called "Python" "Python 2".
> 
> See above, but to rephrase, "Python" is ambiguous in this context because
> you could be talking about Python-the-language, not
> Python-some-release-version.

I don't particularly agree, but if that's correct, then there's a large amount 
of change needed throughout the policy.  These certainly aren't the only 
places this comes up.  Ambiguous or not, I think the policy is mostly 
consistent in using python and python3 vice python2 and python3.  At this 
point I think internal consistency is probably more important, so if someone 
wants to go through and make all the python's that should be python2, etc then 
please send in a patch.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: Python Policy: Things to consider for Stretch

[Barry Warsaw]

On Jan 23, 2016, at 03:38 AM, Scott Kitterman wrote:

>Personally I seriously dislike the trend to call Python Python 2 (and I still
>thing approving a pep to invent /usr/bin/python2 because Arch went insane was
>a horrible idea).  There's an earlier spot in the document where it says that
>everything refers to python and python3 unless it's explicit.  I'll make this
>spot /usr/lib/python2.7/dist-packages and any risk of ambiguity is, I think,
>resolved.

I'll leave it to you, but my take on it is that "Python" is the generic term
for the language and its specification.  "Python 2" v "Python 3" provides
disambiguation when you're talking about specific major versions of the
language.  "Python 3.5" and such usually describe specific releases of the
CPython interpreter implementation (note how "CPython" is used to disambiguate
between alternative implementations of the language specification).  Finally,
python2.7, python3.4 and such are used to describe the executables that
provide the versions (e.g. mentally prepend them with /usr/bin).

All of this, except the last point perhaps, is orthogonal to the
/usr/bin/python2 issue you mention.

Back to the original point, to me saying "Python" and "Python 3" is confusing
or misleading, given the above definitions.  It's confusing because "Python 3"
*is* Python, so what's the difference?  It's misleading because it implies
that somehow "Python 3" isn't "Python".

>> B.2. dh_python2 and dh_python3
>> 
>> Again, I think here you want to say "Python2 and Python3" to disambiguate
>> between generic Python.  
>
>If I say Python and Python3, what version can the one that's not Python3
>possibly be?  I don't think it's any less confusing than starting to call
>what we've always called "Python" "Python 2".

See above, but to rephrase, "Python" is ambiguous in this context because you
could be talking about Python-the-language, not Python-some-release-version.

Cheers,
-Barry


pgpy0qrLvOIdq.pgp
Description: OpenPGP digital signature

Re: Python Policy: Things to consider for Stretch

[Scott Kitterman]

On Sunday, January 24, 2016 04:46:09 PM Ben Finney wrote:
> Scott Kitterman  writes:
> > I've taken a run through the current Python Policy to see where I
> > think it needs to be updated for Stretch. The updates largely fall
> > into four categories: […]
> 
> This is great to see, thank you Scott.
> 
> Where is the Git (I assume?) repository you're using for VCS of this
> policy document?

It's in bzr, actually.  You can find the repository at 
https://alioth.debian.org/scm/loggerhead/pkg-python/python-defaults-debian/files
 (that page has a link to make a branch using bzr.

The Python Policy is in debian/python-policy.sgml

You can make a text version using:

debiandoc2text debian/python-policy.sgml

> > This is just my opinion on stuff I found. I'm interested in feedback
> > on how these changes look and what else ought to be considered
> 
> I like what I see (modulo other discussions in this thread).
> 
> 
> One small nit: the examples of what is included versus excluded of the
> “scope” of a Python version reference. It used to say:
> 
>  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.7 and 2.7.1 are sub-minor versions of the same Python version
>  2.7, but Python 2.6 and 2.7 are indeed different versions.)
> 
> The contrast “2.7 and 2.7.1 are […] the same Python version 2.7”, with
> “2.6 and 2.7 are […] different versions”, uses version “2.7” in both
> parts.
> 
> I think it's important to the example that an *identical* version is in
> *both* arms of that contrast, to be clear what is being distinguished.
> 
> So in the re-write I'd advise again using an identical version in both
> parts:
> 
>  as it seems reasonable to provide them.  (Note: For the scope of this
>  document, Python versions are synonymous to feature releases, i.e.
>  Python 3.5 and 3.5.1 are sub-minor versions of the same Python version
>  3.5, but Python 3.4 and 3.5 are indeed different versions.)
> 
> If I can know where to access the VCS repository I can make a patch for
> that, if you like.

Great.  See above.

I just pushed the edits I've proposed so what's in there now should be clean 
for you to work on top of.  Pushing them to the repository doesn't make them 
any less draft in my opinion (in case anyone was wondering).

Scott K

Re: Python Policy: Things to consider for Stretch

[Ben Finney]

Scott Kitterman  writes:

> I don't particularly agree, but if that's correct, then there's a
> large amount of change needed throughout the policy. These certainly
> aren't the only places this comes up.

Yes, that's likely because when the Debian Python policy was initially
drafted, there was no Python 3 anywhere close to entering Debian. So
“Python” and “Python 2” were less ambiguously conflated at that time.

Now that Python 2 and Python 3 are both commonly (and correctly)
referred to as “Python”, we need to take more care using the terms for
what we mean.

> Ambiguous or not, I think the policy is mostly consistent in using
> python and python3 vice python2 and python3.

Well that's another dimension of confusion :-) The term “python2” and
“python3” are named of commands, more than the names of languages.

I think you're right that this needs a general clean-up through the
policy document, to consistently use:

* “python2” to refer to that command only;

* “python3” to refer to that command only;

* “python” to refer to that command (and I'd suggest deprecating it
  where feasible);

* “Python 2” referring exclusively to that language version 2.x and no
  other versions of that language;

* “Python 3” referring exclusively to that language version 3.x and no
  other versions of that language;

* “Python” referring to the language implemented either as Python 2 or
  Python 3.

> At this point I think internal consistency is probably more important,
> so if someone wants to go through and make all the python's that
> should be python2, etc then please send in a patch.

I'll take that on. Send it to anywhere in particular? Or I can just send
it to this forum.

-- 
 \   “Pinky, are you pondering what I'm pondering?” “Well, I think |
  `\   so, but *where* do you stick the feather and call it macaroni?” |
_o__)   —_Pinky and The Brain_ |
Ben Finney

Re: Python Policy: Things to consider for Stretch

[Scott Kitterman]

On Sunday, January 24, 2016 04:58:26 PM Ben Finney wrote:
> Ben Finney  writes:
> > Where is the Git (I assume?) repository you're using for VCS of this
> > policy document?
> 
> Found it; the source document is ‘python-policy.sgml’ in the source VCS
> for ‘python3’. Currently that's a Bazaar repository at
> .

That's correct.

Scott K

Re: Python Policy: Things to consider for Stretch

[Ben Finney]

Scott Kitterman  writes:

> I've taken a run through the current Python Policy to see where I
> think it needs to be updated for Stretch. The updates largely fall
> into four categories: […]

This is great to see, thank you Scott.

Where is the Git (I assume?) repository you're using for VCS of this
policy document?

> This is just my opinion on stuff I found. I'm interested in feedback
> on how these changes look and what else ought to be considered

I like what I see (modulo other discussions in this thread).


One small nit: the examples of what is included versus excluded of the
“scope” of a Python version reference. It used to say:

 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.7 and 2.7.1 are sub-minor versions of the same Python version
 2.7, but Python 2.6 and 2.7 are indeed different versions.)

The contrast “2.7 and 2.7.1 are […] the same Python version 2.7”, with
“2.6 and 2.7 are […] different versions”, uses version “2.7” in both
parts.

I think it's important to the example that an *identical* version is in
*both* arms of that contrast, to be clear what is being distinguished.

So in the re-write I'd advise again using an identical version in both parts:

 as it seems reasonable to provide them.  (Note: For the scope of this
 document, Python versions are synonymous to feature releases, i.e.
 Python 3.5 and 3.5.1 are sub-minor versions of the same Python version
 3.5, but Python 3.4 and 3.5 are indeed different versions.)

If I can know where to access the VCS repository I can make a patch for
that, if you like.

-- 
 \   “Come on, if your religion is so vulnerable that a little bit |
  `\   of disrespect is going to bring it down, it's not worth |
_o__)   believing in, frankly.” —Terry Gilliam, 2005-01-18 |
Ben Finney

Re: Python Policy: Things to consider for Stretch

[Scott Kitterman]

On Sunday, January 24, 2016 04:33:55 PM Ben Finney wrote:
> Scott Kitterman  writes:
> > I don't particularly agree, but if that's correct, then there's a
> > large amount of change needed throughout the policy. These certainly
> > aren't the only places this comes up.
> 
> Yes, that's likely because when the Debian Python policy was initially
> drafted, there was no Python 3 anywhere close to entering Debian. So
> “Python” and “Python 2” were less ambiguously conflated at that time.
> 
> Now that Python 2 and Python 3 are both commonly (and correctly)
> referred to as “Python”, we need to take more care using the terms for
> what we mean.
> 
> > Ambiguous or not, I think the policy is mostly consistent in using
> > python and python3 vice python2 and python3.
> 
> Well that's another dimension of confusion :-) The term “python2” and
> “python3” are named of commands, more than the names of languages.
> 
> I think you're right that this needs a general clean-up through the
> policy document, to consistently use:
> 
> * “python2” to refer to that command only;
> 
> * “python3” to refer to that command only;
> 
> * “python” to refer to that command (and I'd suggest deprecating it
>   where feasible);
> 
> * “Python 2” referring exclusively to that language version 2.x and no
>   other versions of that language;
> 
> * “Python 3” referring exclusively to that language version 3.x and no
>   other versions of that language;
> 
> * “Python” referring to the language implemented either as Python 2 or
>   Python 3.
> 
> > At this point I think internal consistency is probably more important,
> > so if someone wants to go through and make all the python's that
> > should be python2, etc then please send in a patch.
> 
> I'll take that on. Send it to anywhere in particular? Or I can just send
> it to this forum.

Here or a bzr branch (per my other reply) somewhere is fine.  I agree with all 
of that except the idea of deprecating /usr/bin/python.  It'll never point to 
anything other than a Python (2) version in Debian, so there's no need to 
deprecate it faster than Python (2) in general.

Scott K

Re: Python Policy: Things to consider for Stretch

[Ben Finney]

Ben Finney  writes:

> Where is the Git (I assume?) repository you're using for VCS of this
> policy document?

Found it; the source document is ‘python-policy.sgml’ in the source VCS
for ‘python3’. Currently that's a Bazaar repository at
.

-- 
 \  “The entertainment industry calls DRM "security" software, |
  `\ because it makes them secure from their customers.” —Cory |
_o__) Doctorow, 2014-02-05 |
Ben Finney

Re: Python Policy: Things to consider for Stretch

[Barry Warsaw]

On Jan 21, 2016, at 10:47 AM, Scott Kitterman wrote:

>I've taken a run through the current Python Policy to see where I think it
>needs to be updated for Stretch.

Thanks Scott for the badly needed update.

Some comments, apologies for the lack of good quoting, or if I've read the
diff incorrectly.

2.5 Module Path

"Public Python modules must be installed in the system Python modules
directory, /usr/lib/python./dist-packages.  Public Python 3 modules must
be installed in /usr/lib/python3/dist-packages."

I think this could use a bit of disambiguation, sice "system Python modules"
could mean either Python generically, in which case the second sentence is in
conflict.  Do you mean "system Python 2 modules"?  If so, let's say that.
Also, since Python 2.7 is all there will be from now on, why not say that
explicitly?

A good reason not to would be because Policy needs to cover older releases
where there can be multiple versions of Python 2.  But then later in your diff
you seem to mention python2.7 as being associated with
/usr/local/lib/python2./dist-packages.  So maybe say
/usr/local/lib/python2.7/dist-packages here too?  There really won't be any
other value for  than 7.

3.4 Specifying Supported Versions

"The optional `X-Python-Version (preferred) or `XS-Python-Version` field..."

It's a little confusing because we're now saying we prefer not to have either
field.  How about "(previously preferred)" or just drop the parenthetical?

3.6 Provides

s/substituation/substitution/

B.2. dh_python2 and dh_python3

Again, I think here you want to say "Python2 and Python3" to disambiguate
between generic Python.

Other than that, +1

Cheers,
-Barry


pgplZMuJy6II7.pgp
Description: OpenPGP digital signature

Re: Python Policy

[Barry Warsaw]

On Oct 22, 2015, at 11:14 AM, IOhannes m zmölnig (Debian/GNU) wrote:

>thanks for gender neutral wording.  however, you missed one "his" in the
>first sentence (probably more in other paragraphs).

Got it, thanks.
-Barry


pgpm4DkniheG1.pgp
Description: OpenPGP digital signature

Re: Python Policy

[Barry Warsaw]

On Oct 22, 2015, at 11:11 AM, IOhannes m zmölnig (Debian/GNU) wrote:

>something else i wonder whether we shouldn't drop it, as i don't quite
>understand why it has to be in the policy.
>
>i *think* it's supposed to urge DDs into becoming team members, even though
>they can ("are able to") already write to the repos without asking for
>permissions.  but in fact for me it conveys the complete opposite: DDs can
>("are welcome to") add stuff to the repo, and they should only "request" if
>they want to commit themselves to the team.
>
>...which is probably a (not so) good loophole for any DD who just want their
>python packages under the DMPT umbrella without getting too involved (e.g. no
>sponsoring, maybe not even obey the the policy,...) :- (

Ultimately it reflects reality given that we won't (can't?) prohibit DDs from
write access without joining the team.

For example, if an NMU gets uploaded, I'd like for the DD to be able to commit
the change to the repo directly rather than have ask us one of us to do it for
them.  But any DD who really cares about Python should join the team, IMHO.
It's a pretty low barrier.

Cheers,
-Barry


pgpn44xbQRleU.pgp
Description: OpenPGP digital signature

Re: Python Policy

[Debian/GNU]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2015-10-20 22:53, Barry Warsaw wrote:
> +Any·Debian·developer·who·wishes·to·integrate·his·packages·in·the·team
·can·do
>
> 
+so·without·requesting·access·(as·the·repository·is·writable·by·all·DD).
·If·one
> wants·to·be·more·involved·in·the·team,·we·still·recommend·requesting_·
access
>
> 
- -so·that·he·appears·in·the·public·member·list·displayed·on·Alioth's·proj
ect·page.
> +so·that·they·appear·in·the·public·member·list·displayed·on·Alioth's·p
roject
>
> 
thanks for gender neutral wording.
however, you missed one "his" in the first sentence (probably more in
other paragraphs).

gamsdr
IOhannes

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWKKjwAAoJELZQGcR/ejb4Qj0P/0E3cTOaFvxmot2l8yGS2nyC
O2ucectYPcIPWkXscX35hm7cA6tttWbfkldifwxVVDXo2XLB8ByI1hdCzyQeEJgI
HRmJAkmCyi6e1FG6q5QgGKQCqBWz81BTIABVzfqMR3g5fL7OSqPTmA2VXmeVxUOI
e05ImbOg8fP4kTILfI+6peeiLMZ90sihrOFIO4aYUhkBKGLyGoZz6OMrd7OijwRJ
AEBAJ0MYPPqng5qYsMsVBxhjivBpjPfy8/5oseRdd0wvm6estsn3Zcfk7msymSAf
WU8DvcvWJ0GmWyGae87dLHb5olWhRH3jrKTFDTPHyiMT61RtLPrwN3YZJuxSE6zv
4mVlDJRontM+FS8jPRWL4OaurArOVzJujHiauSbJ3S1SwyjrsnD0rta7Nw06lUpV
uuRtWGNhGFc5cYJbDRdxAE0NeG2L3wwqRDpE6yXyBlwqzngoWlTA0hPWWTFhmbD3
YANWgfdB93Q6MftuEYbRXEvUYxeufqGb4pYNWykcw9xt5UfBxd0ECK4Qk9NK2bm6
Pa9yNUxt6fwezxy3N53NFCgi+6Qz2HjvrqTDtHk+3BYetPDl0DBggoB11YaiAwMd
Igm6amDC4X5NuDl0JVuNEvZsnflnNFd3UvjvnfVF52E5qyQnV2YYnliC9Ys1bGWE
49IHlnGyStuD7VddBe1S
=xhi5
-END PGP SIGNATURE-

Re: Python Policy

[Debian/GNU]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2015-10-20 22:53, Barry Warsaw wrote:
> +Any·Debian·developer·who·wishes·to·integrate·his·packages·in·the·team
·can·do
>
> 
+so·without·requesting·access·(as·the·repository·is·writable·by·all·DD).
·If·one
> wants·to·be·more·involved·in·the·team,·we·still·recommend·requesting_·
access

that's
> 
something else i wonder whether we shouldn't drop it, as i
don't quite understand why it has to be in the policy.

i *think* it's supposed to urge DDs into becoming team members, even
though they can ("are able to") already write to the repos without
asking for permissions.
but in fact for me it conveys the complete opposite: DDs can ("are
welcome to") add stuff to the repo, and they should only "request" if
they want to commit themselves to the team.

...which is probably a (not so) good loophole for any DD who just want
their python packages under the DMPT umbrella without getting too
involved (e.g. no sponsoring, maybe not even obey the the policy,...) :-
(

fgmasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWKKg0AAoJELZQGcR/ejb4GjAP/iTM+RxdQhuS9UqqnsMfLp36
f8BRMHoNm8CBnDBoWoYHGnSc3VshnL2Tzea2aSawW3KKcvf0b4/Hvta3gcqg/OHt
QHeNEJX+PPgJqo/5m+k+jbdB4QeIy5zGwcCxcLnhCdY53x1bCrQMytaMYZy3K+Qy
8eO/wRmKJHBlnoH1DF7KIBwj78bS/rmcHcCw16YzN2RuQQwpBaPwz9HmlkAK4TY/
QqjS9s7Hm80zD5VdzYsIluBoLgaIrbPfaL81YGpY98I56nVGcWd1FhP5BaRlmxyV
LDRPH7CT+AfEmUqAVKnuUWkEAKKz8vzA2imE+QTlrfZ3GAXZUgTw9FEazO9F4Asq
j+b6nSlwyt+B5iLjbjdtMtNTaZdA/OD4jwYt8DfT/aLDrgKcL1byjGjmIzSGIrS+
tX44kJSqN7Bo84Ax7rXRVfC0iAqXQiu/yNQb11dQhXjPGZuREKEXz2WS4zxM7e8Z
GAi3MT41s2zqtSxyU2u8tsV02YreI4shjPpw2PHE11xvy17rFXn678QxXS9iCxr0
tWRLWxLhxHD41UDip+Ir01UWF7LATMpBKVt34ZPUukytLCf109vmEzcX3EoiYXIT
JuYa11KYfGsHI5VkHt3JhraNfprSe/TlGQ+1V899rijpkrftlFgp2iBUi21yPxGB
ET79wfUpZkH3r5u8dHb8
=aAVW
-END PGP SIGNATURE-

Re: Python Policy

[Debian/GNU]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2015-10-21 15:54, Barry Warsaw wrote:
> Hopefully, the latest changes (see previous follow up) are both
> more concise and coherent.

maybe.

i have to admit i'm not totally used to an reviewing git patches per
mailinglists, and in this case i got lost a little bit what the
current draft is.
would it be possible to put a complete draft online somewhere (maybe
even as an r/o git), in addition to posting the patches on the ml.

fg,asdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWKKtpAAoJELZQGcR/ejb4IAoP/iawsZNZApH4TsalsLOUe2I5
HVO9N0/KpmiJZtHWLdj0kfzbdiffb7GCcpDggZgzX3sZiWzQgMJAprqi8zX66hqR
txIIPMDehm/QrxS7Gc1Ul6X/hpiaB/j4ROHjzzHoWrNsyXPaOCrOJ/I6nEwCh5Qb
BGnHkYbIYd1yqJzkPVcGRedwrWcsjOh4AiodxQMk8TDxnz/dcjc2BBQqx0cyCAIX
GW4P3RE0Tzf/K0327eQgA3hUTZnCB4IBHl1Z4Fo6Eb24MjuU0eE2LY1nOFXOwqYX
hwTNZ40X/yBjj9YI3rBNYb7Z+PThKWnP4dBHtaBUNfVeb0X+8MOlmB03RW5oVKA4
DmOCOEBWngCTcybXV7xsmyXkfa8ZxK/WE98nfNhVX2kVc5O3DAiiTAwpKTTqzLL4
3wUtbT/F7cPmju6GwyU3BVt/edazpzd6ovGJc7KVdqaDJ5YNvf1KPQNcO0PevMwF
wArJD7JH3+qdd5dpTaZYJY+Ej1SBDkKT0BYtJa2H5EsU7OVZ+XBh39lqmtzUWPIY
On1NfhmfuMQ1Zl0P1woOVvXtFv8AJQEY2uVmNzP50dyKq+4qLmFNNmocWEf3QI2I
emp16RgczBi6eiJbu+1xnGlhv3ygi4coH/QiWzgIvtjp3PmvTXBZThtrXdwQ3QMa
PX8qDp/tQqEk/MNMRpSl
=u0vU
-END PGP SIGNATURE-

PyPI wheels (was Re: Python Policy)

[Barry Warsaw]

On Oct 21, 2015, at 08:47 PM, Brian May wrote:

>in one case this is because upstream have only supplied a *.whl
>file on Pypi.

I'm *really* hoping that the PyPA will prohibit binary wheel-only uploads.
There is talk about source wheels, and if that happens we'll probably have to
adjust our tools to handle them, but in theory they shouldn't be that much
different than being able to handle a different compression or encapsulation
format.

Cheers,
-Barry

Re: PyPI wheels (was Re: Python Policy)

[Jeremy Stanley]

On 2015-10-21 09:31:04 -0500 (-0500), Ian Cordasco wrote:
> On Wed, Oct 21, 2015 at 8:58 AM, Barry Warsaw  wrote:
> > On Oct 21, 2015, at 08:47 PM, Brian May wrote:
> >
> >>in one case this is because upstream have only supplied a *.whl
> >>file on Pypi.
> >
> > I'm *really* hoping that the PyPA will prohibit binary wheel-only uploads.
> 
> I'm not sure why they should prohibit binary wheel-only uploads. A
> company may wish to publish a binary wheel of a tool and only that (a
> wheel for Windows, OS X, different supported linux distributions,
> etc.). If they do, that's their prerogative. I don't think there's
> anything that says Debian (or Ubuntu) would then have to package that.
> 
> PyPI is not just there for downstream, it's there for users too
> (although the usability of PyPI is not exactly ideal).

Yep, I'm as much a fan of free software as the next person, but PyPI
doesn't _require_ what you upload is free software. It only requires
that you grant the right to redistribute what you're uploading.
While having source code to go along with things uploaded there
(which, mind you, aren't even actually required to be usable python
packages, they could be just about anything) would be nice, I don't
have any expectation that PyPI would ever eventually make it
mandatory.
-- 
Jeremy Stanley

Re: PyPI wheels (was Re: Python Policy)

[Ian Cordasco]

On Wed, Oct 21, 2015 at 8:58 AM, Barry Warsaw  wrote:
> On Oct 21, 2015, at 08:47 PM, Brian May wrote:
>
>>in one case this is because upstream have only supplied a *.whl
>>file on Pypi.
>
> I'm *really* hoping that the PyPA will prohibit binary wheel-only uploads.

I'm not sure why they should prohibit binary wheel-only uploads. A
company may wish to publish a binary wheel of a tool and only that (a
wheel for Windows, OS X, different supported linux distributions,
etc.). If they do, that's their prerogative. I don't think there's
anything that says Debian (or Ubuntu) would then have to package that.

PyPI is not just there for downstream, it's there for users too
(although the usability of PyPI is not exactly ideal).

Re: Python Policy

[Brian May]

Vincent Bernat  writes:

> You should remove the reference to Pypi since tarballs can also be taken
> From GitHub (when upstream doesn't want to ship everything, like tests,
> in Pypi tarballs or doesn't even release tarballs on Pypi):

Have filled upstream bugs on issues that prevent me using the Pypi
source - in one case this is because upstream have only supplied a *.whl
file on Pypi. Don't expect upstream to fix them anytime soon however. So
far no response. The projects aren't very active.

https://github.com/mbi/django-simple-captcha/issues/94
https://github.com/bradleyayers/django-tables2/issues/267

I probably will end up using github source - and I suspect that is what
I have done in the past - debian/watch points to Pypi - something else I
will need to fix too, I guess.
-- 
Brian May 

Re: Python Policy

[Vincent Bernat]

 ❦ 20 octobre 2015 20:52 -0400, Barry Warsaw  :

>>I'd remove this paragraph. Releases can be made via `git archive` and I did
>>that many times (assuming pristine-tar will still keep needed data to
>>regenerate exact same tarball).  If you meant that we don't want to keep
>>complete upstream git history, then I agree completely, but I'd made it a
>>"should" rather than "must".
>
> What I'm trying to express is the team decision (a couple of debconfs ago) for
> pristine-tars rather than releasing from upstream git.  I do want to keep the
> rationale in the policy doc; it's one sentence and it seems to come up often
> enough.  Suggestions for better phrasing welcome!

You should remove the reference to Pypi since tarballs can also be taken
From GitHub (when upstream doesn't want to ship everything, like tests,
in Pypi tarballs or doesn't even release tarballs on Pypi):

> DPMT requires upstream tarballs, either released on PyPI (or any other
> place) or snapshots made from git. Tarballs are what we upload to the
> Debian archive.
-- 
Use recursive procedures for recursively-defined data structures.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Python Policy

[Debian/GNU]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2015-10-21 02:17, Ben Finney wrote:
> "IOhannes m zmölnig (Debian/GNU)"  writes:
> 
>> thanks a lot for preparing all this.
>> 
>> On 10/20/2015 10:53 PM, Barry Warsaw wrote:
>>> +DPMT requires upstream tarballs; releases cannot be made from
>>> upstream git +repositories directly.  This is because PyPI
>>> contains upstream tarballs, and +tarballs are what we upload to
>>> the Debian archive.
>> 
>> i find the justification a bit weird: "no releases can be made
>> from upstream git because some upstreams use tarballs"?
> 
> Yes, that is weird, and it's not what you quoted. I don't know how
> you get that meaning from the text you quoted

it's not what i quoted, but it's what i read in the quote.

it says "releases cannot be made from upstream git repositories
directly. This is because PyPI contains upstream tarballs [...]".

i fail to see what this "this" in the second sentence refers to if it
was not for the statement in the first sentence. thus creating a
cause-effect statement "pypi contains upstream tarballs -> releases
cannot be made from upstream git".
i think this logic is plain wrong.

for one thing, pypi - while being the most prominent source - is
probably *not* the only source for python modules. (that's why my
interpretation says "some upstreams").
furthermore, pypi is *not* upstream itself. it's a distribution
channel. an upstream (author) might as well do releases using git-tags
on github in addition to uploading the tarballs to pypi.
in this case, releases *can* (technically) be made from git tags.

it also says "[...] and tarballs are what we upload to the Debian
archive.".
which is true, but it's true for any Debian package (even those that
use upstream git or zip). so what's the point?


so: if my upstream does not use pypi (or i'm not aware of upstream
using pypi), does "tarballs required" policy still apply to me?

i think yes (but then i don't understand why there's a rationale if it
does not apply)


> This is because PyPI contains upstream tarballs, and tarballs are 
> what we upload to the Debian archive.
> 
>> in any case, i don't think that there is actually a need for the 
>> policy to justify the decision to require tarballs (let's put
>> that in the wiki for those interested).
> 
> On the contrary, I think the Policy document should document the 
> rationale for contingent decisions like this. When it is
> inevitably discussed again in the future, it is always better to
> know the intent of the authors.

that's why i said that the rationale should be documented in the wiki
(as opposed to the policy).
the policy did not contain a rationale why we chose svn.
the policy doesn't contain a rationale why we chose git.
(well, the decision for git will probably go unquestioned, but:)
the policy doesn't contain a rationale why we chose git-dpm (not even
a shallow one as "we need *a single* standard", let alone one that is
based on actual technical merits).


TL;DR

i am not a native speaker. so i might get things wrong.
but i'm not the only non-native English speaker in Debian.
therefore, i *strongly* suggest that the policy should be written in a
style that non-natives can understand it - without getting the
impression that considerable parts of the policy are only relevant for
specific setups (and not for them).

mfgsdr
IOhannes

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWJ0P+AAoJELZQGcR/ejb4XtsQAIKQXQZxlzSgJF6zOi6NTgX8
Yq/y3mgvOZkWwsgOSqZKFVEnSsPQdBDptywSqV1Fm1Dy/6MS68jy03JRP+zWBUV1
n0Hr2NiMYzQxGBOhmIIrR7WtdEvxXhOs1Z1A3Nv5Tq4lJYX0XBPfAxOus/jdii6g
w84EIACtR6unvhGEcbABx8jNAecX73azN0Uni0S4BCYpczHgSEghulBu5FK4FT1M
22ZKA40S9kvq4naLg43A/hGjXsLvd//6Bfn5Cufu3YaAXugSaqIz16cNlzTKZDRq
F3NUtUtLD6RdjkCtzpAIo4WoUMZcvprXh34EVctj7uJ+tSYDi17J1dUO8HOTq3UI
EOEDFOscQvQZ+6h//89W6QjDdK8wW2C4jnspOQx6ZD4dJKa6r0qCKvBgx/E2fnmX
rb568XMXErGcjdLRAAyJj50UYud3uqNdRvjg6mrgQdRPghSFAQXz4jjx9W0y2bh8
MrC7BaaLA9nS3XdSMVwQWGMQJ4Nn+LTrWtBhnjLAEee1pWg5x4wdamLAPGKCyWN2
NYHweYdcGuEAeoYr5T9tpEsnRZQo6kIE+jRKp0IX88JGLqdv1eyy+/gk+mYtSkTY
Qie0dvzTUs4btwI3To1g2X6oCRaBMabm0sZ4/yLZBqpSC9NdrB3YAsBRX3xWMgEg
2DCyuPCVFKHWUp1Pz++T
=sKPF
-END PGP SIGNATURE-

Re: Python Policy

[Barry Warsaw]

Thanks for the feedback Piotr.  I've made all the changes you suggest, except
one.  I'll discuss that below and include an updated diff against master.

On Oct 19, 2015, at 11:26 PM, Piotr Ożarowski wrote:

>I'm against this change. If we want all team packages to follow some
>rules, these rules need to be in policy document, not on the wiki page.
>I don't want this page to be removed, policy can even point to it, but I
>want it to be crystal clear that the binding document is the policy, not
>any other document in the internet (even if it's very helpful).
>
>What am I missing here is a set of branch/tag names and procedures
>(f.e. I didn't know that git pull is not enough and I should gbp pull or
>update pristine-tar branch by hand) and debian/patches related set of rules
>(do we require git-dpm or can one use plain quilt of some other rules
>are followed?)

Here's my concern: I don't want too much duplication of information in
multiple locations.  That's a sure recipe for bitrot, and I know no one wants
to have to edit information in more than one place.

Until now, the wiki has been the more convenient place to make these changes,
but I agree in principle with your opinion that some of that information must
be captured in policy.  So here's what I suggest.

For standards we must all adhere to, such as branch and tag names, source-full
branches, the use of git-dpm, and maybe a few other points, these should go in
policy.rst.

The wiki page points to the policy document but doesn't otherwise describe
those details.  That way, there's only one place to change when/if these
standards change.

The wiki then goes on to describe common workflows, how to create new
repositories, mr, etc.  These aren't specifically policy related but are
mostly there to help developers get started, or handle tricky situations.

If you're in agreement with that split, I'll update both the policy and wiki.

Cheers,
-Barry

diff --git a/policy.rst b/policy.rst
index c09f03a..aed57c0 100644
--- a/policy.rst
+++ b/policy.rst
@@ -1,19 +1,19 @@
-
- Python Modules Packaging Team - Policy
-
+=
+ Debian Python Modules Team - Policy
+=
 
-:Author: Gustavo Franco , Raphaël Hertzog 

+:Author: Gustavo Franco , Raphaël Hertzog 
, Barry Warsaw 
 :License: GNU GPL v2 or later
 
 :Introduction:
-  Python Modules Packaging Team aims to improve the python modules situation
-  in Debian, by packaging available modules that may be useful and providing
-  a central location for packages maintained by a team, hence improving
-  responsiveness, integration and standardization.
-
-  PMPT or just python-modules is hosted at alioth.debian.org, the Debian
-  GForge installation. We currently have a SVN repository and a mailing list
-  whose email address can be used in the Maintainer field on co-maintained
+  The Debian Python Modules Team (DPMT) aims to improve the Python modules
+  situation in Debian, by packaging available modules that may be useful and
+  providing a central location for packages maintained by a team, hence
+  improving responsiveness, integration, and standardization.
+
+  The DPMT is hosted at alioth.debian.org, the Debian GForge installation. We
+  currently have a git repository and a mailing list whose email address can
+  be used in the ``Maintainer`` or ``Uploaders`` fields on co-maintained
   packages.
 
   For more information send a message to: debian-python@lists.debian.org
@@ -24,16 +24,21 @@
 Joining the team
 
 
-The team is open to any python-related package maintainer. To be added on
-the team, please send your request on debian-python@lists.debian.org
-indicate why you want to join the team: maintain your current packages
-within the team, help maintain some specific packages, etc.
-Don't forget to indicate your Alioth login !
+The team is open to any Python-related package maintainer. To be added to
+the team, please send your request to debian-python@lists.debian.org.  Include
+the following in your request:
 
-Any Debian developer who wishes to integrate his packages in the team can do so
-without requesting access (as the repository is writable by all DD). If one
+* Why you want to join the team: e.g. maintain your current packages within
+  the team, help maintain some specific packages, etc.
+* Your Alioth login.
+* A statement that you have read
+  https://python-modules.alioth.debian.org/policy.html and that you accept it.
+
+Any Debian developer who wishes to integrate his packages in the team can do
+so without requesting access (as the repository is writable by all DD). If one
 wants to be more involved in the team, we still recommend requesting_ access
-so that he appears in the public member list displayed on Alioth's project 
page.
+so that 

Re: Python Policy

[Barry Warsaw]

On Oct 20, 2015, at 12:37 AM, Piotr Ożarowski wrote:

>should we also document that we're not OpenStack Packaging Team?

Or zope-packaging? .  Agreed that there are different teams here, but I
am hoping that we can do some consolidation.  E.g. I posted on the zope list
that I'd like to pull those packages into DPMT.  I heard *zero* responses, so
I'm honestly not sure there's still anybody who cares about that team.

(I'll post on the wider debian lists to follow up, but I will take silence as
assent at some point.)

>there is one HUGE difference, one is about packaging MODULES and the
>other one is packaging APPLICATIONS. One provides python-, python3-
>and/or pypy- packages, the other cannot do that.

Although there is often overlap.  Some packages intentionally provide both
libraries and applications.  These usually end up in DPMT, which I think is
fine.

I also think it would be fine to *eventually* merge the two teams.  I suspect
there isn't really much benefit to keeping them separate and a lot of
unnecessary cost.  Is there anybody on PAPT who doesn't want to be on DPMT?
Is there any reason why team policy couldn't be expanded to describe the few
differences between packaging libraries and pure-applications?

>> There are packages that do not provide public modules that are aimed at
>> developers. I imagine there are also packages that are end user
>> applications that do provide public modules, for end user
>> programming. These end user's may require the first group of packages
>> aimed at developers too.
>
>if something installs into dist-packages, it should (I'd make it a
>"must", but it's just me) provide python-/python3-/pypy- binary
>package. Python application should not (again, "must" is much better
>here IMO) pollute global Python namespace

I'm not sure I'd go as far as MUST, but aside from that, there's no inherent
reason IMHO why these two policies and procedures couldn't co-exist within the
same team.

Cheers,
-Barry

Re: Python Policy

[Piotr Ożarowski]

[Barry Warsaw, 2015-10-20]
> Here's my concern: I don't want too much duplication of information in
> multiple locations.  That's a sure recipe for bitrot, and I know no one wants
> to have to edit information in more than one place.
> 
> Until now, the wiki has been the more convenient place to make these changes,
> but I agree in principle with your opinion that some of that information must
> be captured in policy.  So here's what I suggest.
> 
> For standards we must all adhere to, such as branch and tag names, source-full
> branches, the use of git-dpm, and maybe a few other points, these should go in
> policy.rst.
> 
> The wiki page points to the policy document but doesn't otherwise describe
> those details.  That way, there's only one place to change when/if these
> standards change.
> 
> The wiki then goes on to describe common workflows, how to create new
> repositories, mr, etc.  These aren't specifically policy related but are
> mostly there to help developers get started, or handle tricky situations.
> 
> If you're in agreement with that split, I'll update both the policy and wiki.

if policy describes f.e. tag name convention and our tools create
correct configuration out of the box, then there's no need to mention it
on the wiki so yes, I agree with what you said. I don't even mind to
list only few things in policy now and extend it later, once we figure
out whats best for us (and work on wiki only for now), but at some point
I want a set of rules (a "standard"!) that will make my life as sponsor
easier and this is F*G important for me. I will leave this team the
moment I have to read README.sources each day when I sponsor a package.
If you want help from me, make it easier for me to review your work.

(most of RFS emails I get contain "RFS: DPMT: foo version" subject and
nothing else, it works for me, I'm lazy and I prefer to read
non-technical books rather than RFS mails :P)
-- 
evil general Piotr

Re: Python Policy

[Barry Warsaw]

Latest diff against master.  If you're happy with this, I'll merge to master,
update the web page, and trim the wiki.

Cheers,
-Barry

diff --git a/policy.rst b/policy.rst
index c09f03a..123792c 100644
--- a/policy.rst
+++ b/policy.rst
@@ -1,39 +1,44 @@
-
- Python Modules Packaging Team - Policy
-
+=
+ Debian Python Modules Team - Policy
+=
 
-:Author: Gustavo Franco , Raphaël Hertzog 

+:Author: Gustavo Franco , Raphaël Hertzog 
, Barry Warsaw 
 :License: GNU GPL v2 or later
 
 :Introduction:
-  Python Modules Packaging Team aims to improve the python modules situation
-  in Debian, by packaging available modules that may be useful and providing
-  a central location for packages maintained by a team, hence improving
-  responsiveness, integration and standardization.
-
-  PMPT or just python-modules is hosted at alioth.debian.org, the Debian
-  GForge installation. We currently have a SVN repository and a mailing list
-  whose email address can be used in the Maintainer field on co-maintained
+  The Debian Python Modules Team (DPMT) aims to improve the Python modules
+  situation in Debian, by packaging available modules that may be useful and
+  providing a central location for packages maintained by a team, hence
+  improving responsiveness, integration, and standardization.
+
+  The DPMT is hosted at alioth.debian.org, the Debian GForge installation. We
+  currently have a git repository and a mailing list whose email address can
+  be used in the ``Maintainer`` or ``Uploaders`` fields on co-maintained
   packages.
 
   For more information send a message to: debian-python@lists.debian.org
 
 .. contents::
 
-
+
 Joining the team
-
+
 
-The team is open to any python-related package maintainer. To be added on
-the team, please send your request on debian-python@lists.debian.org
-indicate why you want to join the team: maintain your current packages
-within the team, help maintain some specific packages, etc.
-Don't forget to indicate your Alioth login !
+The team is open to any Python-related package maintainer. To be added to
+the team, please send your request to debian-python@lists.debian.org.  Include
+the following in your request:
 
-Any Debian developer who wishes to integrate his packages in the team can do so
-without requesting access (as the repository is writable by all DD). If one
+* Why you want to join the team: e.g. maintain your current packages within
+  the team, help maintain some specific packages, etc.
+* Your Alioth login.
+* A statement that you have read
+  https://python-modules.alioth.debian.org/policy.html and that you accept it.
+
+Any Debian developer who wishes to integrate his packages in the team can do
+so without requesting access (as the repository is writable by all DD). If one
 wants to be more involved in the team, we still recommend requesting_ access
-so that he appears in the public member list displayed on Alioth's project 
page.
+so that they appear in the public member list displayed on Alioth's project
+page.
 
 The team accepts all contributors and is not restricted to Debian developers.
 Several Debian developers of the team will gladly sponsor packages of non-DD
@@ -43,91 +48,129 @@ discussion list or on #debian-python IRC channel (OFTC 
network).
 All team members should of course follow the main discussion list:
 debian-python@lists.debian.org
 
---
+
 Maintainership
---
+==
 
 A package maintained within the team should have the name of the team either
-in the Maintainer field or in the Uploaders field.
+in the ``Maintainer`` field or in the ``Uploaders`` field.
 
 Maintainer: Debian Python Modules Team 

 
 This enables the team to have an overview of its packages on the DDPO_website_.
 
-* Team in Maintainers is a strong statement that fully collaborative
-  maintenance is preferred. Anyone can commit to the vcs and upload as
-  needed. A courtesy email to Uploaders can be nice but not required.
+* Team in ``Maintainers`` is a strong statement that fully collaborative
+  maintenance is preferred. Anyone can commit to the git repository and upload
+  as needed. A courtesy email to ``Uploaders`` can be nice but not required.
 
-* Team in Uploaders is a weak statement of collaboration. Help in maintaining
-  the package is appreciated, commits to vcs are freely welcomed, but before
-  uploading, please contact the Maintainer for the green light.
+* Team in ``Uploaders`` is a weak statement of collaboration. Help in
+  maintaining the package is appreciated, commits to the git repository are
+  freely welcomed, but before uploading, please contact the ``Maintainer`` for
+  the 

Re: Python Policy

[Debian/GNU]

thanks a lot for preparing all this.

On 10/20/2015 10:53 PM, Barry Warsaw wrote:
> +DPMT requires upstream tarballs; releases cannot be made from upstream git
> +repositories directly.  This is because PyPI contains upstream tarballs, and
> +tarballs are what we upload to the Debian archive.

i find the justification a bit weird: "no releases can be made from
upstream git because some upstreams use tarballs"?

in any case, i don't think that there is actually a need for the policy
to justify the decision to require tarballs (let's put that in the wiki
for those interested).

gfmsadr
IOhannes



signature.asc
Description: OpenPGP digital signature

Re: Python Policy

[Barry Warsaw]

On Oct 20, 2015, at 05:16 PM, Piotr Ożarowski wrote:

>I will leave this team the moment I have to read README.sources each day when
>I sponsor a package.

Nobody wants that! (either you leaving or having to read README.source for
every package).

Cheers,
-Barry

Re: Python Policy

[Piotr Ożarowski]

[Barry Warsaw, 2015-10-20]
> Latest diff against master.  If you're happy with this, I'll merge to master,
> update the web page, and trim the wiki.

I have few comments, but even if I didn't, please wait at least until after
the weekend (or better: 7 days) so that others have time to review it and
comment / propose changes.

I removed everything that sounds fine to me.

> +DPMT requires upstream tarballs; releases cannot be made from upstream git
> +repositories directly.  This is because PyPI contains upstream tarballs, and
> +tarballs are what we upload to the Debian archive.

I'd remove this paragraph. Releases can be made via `git archive` and I
did that many times (assuming pristine-tar will still keep needed data
to regenerate exact same tarball).
If you meant that we don't want to keep complete upstream git history,
then I agree completely, but I'd made it a "should" rather than "must".

> +``gbp build-package`` is used to build the package, either as a source 
> package

s/build-package/buildpackage/

> +for use with ``pbuilder``, ``sbuild``, etc. or as a binary package directory.

gbp can use sbuild/pbuilder, here's my ~/.gbp.conf:

  [buildpackage]
  builder=sbuild

> +Use the following ``git-dpm`` tag formats for the three branches named above.
> +Put these lines at the *end* of your ``debian/.git-dpm`` file::
> +
> +debianTag="debian/%e%v"
> +patchedTag="patches/%e%v"
> +upstreamTag="upstream/%e%u"

I will update `py2dsp --profile dpmt ...` to do that out of the box, but
even then, it's better to suggest that tool in the wiki only, I guess

> +All packages which have been automatically converted from the old Subversion
> +repository should already have these lines present, but you will need to add
> +them for any new packages.

that's something for the wiki, not policy, IMO


other comment:
I'm wondering about something that bit me recently: `gbp pull` instead
of `git pull` - should we put that into policy or is wiki warning enough?
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: Python Policy

[Piotr Ożarowski]

[Barry Warsaw, 2015-10-20]
> On Oct 19, 2015, at 09:04 PM, Piotr Ożarowski wrote:
> 
> >Debian Python Policy¹ is something every single packages that extends
> >Python should follow. There are many teams (more than 4) each of them
> >can have their own policy that extends DPP.
> 
> This is an important distinction that I don't think is really captured
> anywhere.  Let me rephrase it to see if I'm capturing your sentiment.
> 
> There is Debian Python Policy which describes the standards for publishing
> Python libraries and applications within the Debian archive.  It is a Debian
> Project-wide standard, irrespective of which team, if any, is maintaining the
> Python package.
> 
> There is the DPMT, a team for co-maintaining Python libraries.  It has its own
> policy document for how those libraries are maintained, and adheres to DPP for
> publishing those libraries in the archive.

correct

> There is the PAPT, a team for co-maintaining Python applications.  While there
> may be overlap with DPMT (e.g. some upstream packages provide both libraries
> and applications), PAPT has its own policy document for how those applications
> are maintained, and adheres to DPP for publishing those applications in the
> archive.

just to make it even clearer: if package provides a tiny script that
uses library, it should go to DPMT. If package provides an app and a
tiny library (I'm thinking about real library, not just those where
maintainer forgot to set --install-lib correctly and installs app into
dist-packages) - it's a PAPT candidate.

--install-lib is the main difference between DPMT and PAPT. There are
different set of problems when you install into dist-packages and outside
this directory.
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: Python Policy

[Piotr Ożarowski]

[Barry Warsaw, 2015-10-20]
> I also think it would be fine to *eventually* merge the two teams.  I suspect
> there isn't really much benefit to keeping them separate and a lot of
> unnecessary cost.  Is there anybody on PAPT who doesn't want to be on DPMT?

/me puts his PAPT admin hat on

WHAT? You want us to learn about all these weird package name rules? All
these transitions? All these so name abi ext whatever weird tags? GO AWAY!

/me puts his DPMT admin hat on

WHAT? Do you know these guys despise our belowed dist-packages? And they
have weird package names that do not start with python-! GO AWAY!

;P

> I'm not sure I'd go as far as MUST, but aside from that, there's no inherent
> reason IMHO why these two policies and procedures couldn't co-exist within the
> same team.

DPMT is already too big, please don't add applications to make it even
more complicated

-- 
evil general Piotr

Re: Python Policy

[Barry Warsaw]

On Oct 21, 2015, at 11:17 AM, Ben Finney wrote:

>On the contrary, I think the Policy document should document the
>rationale for contingent decisions like this. When it is inevitably
>discussed again in the future, it is always better to know the intent of
>the authors.

+1

Cheers,
-Barry

Re: Python Policy

[Barry Warsaw]

On Oct 20, 2015, at 11:30 PM, Piotr Ożarowski wrote:

>I have few comments, but even if I didn't, please wait at least until after
>the weekend (or better: 7 days) so that others have time to review it and
>comment / propose changes.

Fair enough.  Of course, it's in a vcs so it's easy to change! :)

>I'd remove this paragraph. Releases can be made via `git archive` and I did
>that many times (assuming pristine-tar will still keep needed data to
>regenerate exact same tarball).  If you meant that we don't want to keep
>complete upstream git history, then I agree completely, but I'd made it a
>"should" rather than "must".

What I'm trying to express is the team decision (a couple of debconfs ago) for
pristine-tars rather than releasing from upstream git.  I do want to keep the
rationale in the policy doc; it's one sentence and it seems to come up often
enough.  Suggestions for better phrasing welcome!

>> +``gbp build-package`` is used to build the package, either as a source
>> package
>
>s/build-package/buildpackage/

Fixed, thanks.

>> +for use with ``pbuilder``, ``sbuild``, etc. or as a binary package 
>> directory.
>
>gbp can use sbuild/pbuilder, here's my ~/.gbp.conf:
>
>  [buildpackage]
>  builder=sbuild

This is the kind of thing that should go in the wiki.

>> +Use the following ``git-dpm`` tag formats for the three branches named 
>> above.
>> +Put these lines at the *end* of your ``debian/.git-dpm`` file::
>> +
>> +debianTag="debian/%e%v"
>> +patchedTag="patches/%e%v"
>> +upstreamTag="upstream/%e%u"
>
>I will update `py2dsp --profile dpmt ...` to do that out of the box, but
>even then, it's better to suggest that tool in the wiki only, I guess

I think so.  The tag format (and IMHO the mechanism to ensure it) should go in
policy though.

>> +All packages which have been automatically converted from the old
>> Subversion +repository should already have these lines present, but you
>> will need to add +them for any new packages.
>
>that's something for the wiki, not policy, IMO

Sure.  I reworded the policy docs a little bit here.

>other comment:
>I'm wondering about something that bit me recently: `gbp pull` instead
>of `git pull` - should we put that into policy or is wiki warning enough?

I think wiki is enough.  It is possible to operate with just straight `git
pull` because it will still fetch all commits, but when you switch to one of
the other branches, you'll see that its head is out of date, and git will
prompt you to pull in that branch to update it.  `gbp pull` is mostly
convenience.

Cheers,
-Barry

Re: Python Policy

[Ben Finney]

"IOhannes m zmölnig (Debian/GNU)"  writes:

> thanks a lot for preparing all this.
>
> On 10/20/2015 10:53 PM, Barry Warsaw wrote:
> > +DPMT requires upstream tarballs; releases cannot be made from upstream git
> > +repositories directly.  This is because PyPI contains upstream tarballs, 
> > and
> > +tarballs are what we upload to the Debian archive.
>
> i find the justification a bit weird: "no releases can be made from
> upstream git because some upstreams use tarballs"?

Yes, that is weird, and it's not what you quoted. I don't know how you
get that meaning from the text you quoted:

This is because PyPI contains upstream tarballs, and tarballs are
what we upload to the Debian archive.

> in any case, i don't think that there is actually a need for the
> policy to justify the decision to require tarballs (let's put that in
> the wiki for those interested).

On the contrary, I think the Policy document should document the
rationale for contingent decisions like this. When it is inevitably
discussed again in the future, it is always better to know the intent of
the authors.

-- 
 \  “Our products just aren't engineered for security.” —Brian |
  `\ Valentine, senior vice-president of Microsoft Windows |
_o__)development, 2002 |
Ben Finney

Re: Python Policy

[Piotr Ożarowski]

| diff --git a/policy.rst b/policy.rst
| index c09f03a..9a9abb4 100644
| --- a/policy.rst
| +++ b/policy.rst
| @@ -1,20 +1,19 @@
| -
| - Python Modules Packaging Team - Policy
| -
| +=
| + Debian Python Modules Team - Policy
| +=
|  
| -:Author: Gustavo Franco , Raphaël Hertzog 

| +:Author: Gustavo Franco , Raphaël Hertzog 
, Barry Warsaw 
|  :License: GNU GPL v2 or later
|  
|  :Introduction:
| -  Python Modules Packaging Team aims to improve the python modules situation
| -  in Debian, by packaging available modules that may be useful and providing
| -  a central location for packages maintained by a team, hence improving
| -  responsiveness, integration and standardization.
| +  The Debian Python Modules Team (DPMT) aims to improve the Python modules
| +  situation in Debian, by packaging available modules that may be useful and
| +  providing a central location for packages maintained by a team, hence
| +  improving responsiveness, integration, and standardization.
|  
| -  PMPT or just python-modules is hosted at alioth.debian.org, the Debian
| -  GForge installation. We currently have a SVN repository and a mailing list
| -  whose email address can be used in the Maintainer field on co-maintained
| -  packages.
| +  The DPMT is hosted at alioth.debian.org, the Debian GForge installation. We
| +  currently have a git repository and a mailing list whose email address can

+1 to all above

| +  be used in the ``Maintainer`` field on co-maintained packages.

I suggest:

s/``Maintainer`` field/``Maintainer`` or ``Uploaders`` fields/

|  
|For more information send a message to: debian-python@lists.debian.org
|  
| @@ -24,16 +23,17 @@
|  Joining the team
|  
|  
| -The team is open to any python-related package maintainer. To be added on
| +The team is open to any Python-related package maintainer. To be added on
|  the team, please send your request on debian-python@lists.debian.org
|  indicate why you want to join the team: maintain your current packages
|  within the team, help maintain some specific packages, etc.

how about adding (taken from the wiki :) this:

  In your email please state that you have read
  https://python-modules.alioth.debian.org/policy.html and
  that you accept it.

| -Don't forget to indicate your Alioth login !
| +Don't forget to indicate your Alioth login!
|  
| -Any Debian developer who wishes to integrate his packages in the team can do 
so
| -without requesting access (as the repository is writable by all DD). If one
| +Any Debian developer who wishes to integrate his packages in the team can do
| +so without requesting access (as the repository is writable by all DD). If 
one
|  wants to be more involved in the team, we still recommend requesting_ access
| -so that he appears in the public member list displayed on Alioth's project 
page.
| +so that they appear in the public member list displayed on Alioth's project
| +page.
|  
|  The team accepts all contributors and is not restricted to Debian developers.
|  Several Debian developers of the team will gladly sponsor packages of non-DD
| @@ -48,71 +48,35 @@ Maintainership
|  --
|  
|  A package maintained within the team should have the name of the team either
| -in the Maintainer field or in the Uploaders field.
| +in the ``Maintainer`` field or in the ``Uploaders`` field.
|  
|  Maintainer: Debian Python Modules Team 

|  
|  This enables the team to have an overview of its packages on the 
DDPO_website_.
|  
| -* Team in Maintainers is a strong statement that fully collaborative
| -  maintenance is preferred. Anyone can commit to the vcs and upload as
| -  needed. A courtesy email to Uploaders can be nice but not required.
| +* Team in ``Maintainers`` is a strong statement that fully collaborative
| +  maintenance is preferred. Anyone can commit to the git repository and 
upload
| +  as needed. A courtesy email to ``Uploaders`` can be nice but not required.
|  
| -* Team in Uploaders is a weak statement of collaboration. Help in maintaining
| -  the package is appreciated, commits to vcs are freely welcomed, but before
| -  uploading, please contact the Maintainer for the green light.
| +* Team in ``Uploaders`` is a weak statement of collaboration. Help in
| +  maintaining the package is appreciated, commits to the git repository are
| +  freely welcomed, but before uploading, please contact the ``Maintainer`` 
for
| +  the green light.
|  
|  Team members who have broad interest should subscribe to the mailing list
|  python-modules-t...@lists.alioth.debian.org whereas members who are only
|  interested in some packages should use the Package Tracking System to
|  follow the packages.
|  
| 

Re: Python Policy

[Piotr Ożarowski]

[Barry Warsaw, 2015-10-19]
> So we currently have several places where we have team policy described.

no.

Debian Python Policy¹ is something every single packages that extends
Python should follow. There are many teams (more than 4) each of them
can have their own policy that extends DPP.

Please do not confuse DPMT with this mythic "Python team" which doesn't
exist.

> * The Debian wiki
>   https://wiki.debian.org/Python and subpages

wiki is something everyone can edit. It's a place that can help with
various tasks, it can even be a place where policy is prepared, but it's
not a place to store official documents.

> * Another wiki page:
>   https://wiki.debian.org/Teams/PythonModulesTeam

this is wiki page, not a policy

> * https://www.debian.org/doc/packaging-manuals/python-policy/
>   which comes from the python-defaults (*not* python3-defaults!) in the bzr
>   repo at
>   http://alioth.debian.org/anonscm/bzr/pkg-python/python-defaults-debian

this it THE policy (¹)

> * "PMPT" policy
>   http://python-modules.alioth.debian.org/
>   git+ssh://git.debian.org/git/python-modules/tools/python-modules.git
>   except that that page specifically isn't represented in the git repo, only
>   policy.rst

DPMT and PAPT are two different things

> and maybe more.  This is crazy!  We really need to consolidate all this
> information.

why? again, if you want to describe common Python related things - DPP
is the place, if it's team specific, please allow each team to have
their own rules.

> That said, I did a pass through policy.rst in the git repo above and pushed
> the 'git-policy' branch for review.  `git diff master` to see the proposed
> changes.  Here's a summary:

please paste the diff here, on this mailing list

> * PMPT -> DPMT - it seems like we mostly refer to ourselves as Debian Python
>   Modules Team and rarely if ever Python Modules Packaging Team any more.
>   Another opportunity for more consistency.

+1

> * Clarified slightly the wording in policy differences between
>   team-in-Maintainer and team-in-Uploaders.

will comment later, once I have access to git repo

> * Remove all the references to Subversion and add a short blurb about Git,
>   pointing to the GitPackaging wiki page.

as above
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: Python Policy

[Scott Kitterman]

On October 19, 2015 1:31:37 PM EDT, Barry Warsaw  wrote:
>So we currently have several places where we have team policy
>described.
>
>* The Debian wiki
>  https://wiki.debian.org/Python and subpages
>
>* Another wiki page:
>  https://wiki.debian.org/Teams/PythonModulesTeam
>
>* https://www.debian.org/doc/packaging-manuals/python-policy/
>which comes from the python-defaults (*not* python3-defaults!) in the
>bzr
>  repo at
> http://alioth.debian.org/anonscm/bzr/pkg-python/python-defaults-debian
>
>* "PMPT" policy
>  http://python-modules.alioth.debian.org/
>  git+ssh://git.debian.org/git/python-modules/tools/python-modules.git
>except that that page specifically isn't represented in the git repo,
>only
>  policy.rst
>
>and maybe more.  This is crazy!  We really need to consolidate all this
>information.
>
>That said, I did a pass through policy.rst in the git repo above and
>pushed
>the 'git-policy' branch for review.  `git diff master` to see the
>proposed
>changes.  Here's a summary:
>
>* PMPT -> DPMT - it seems like we mostly refer to ourselves as Debian
>Python
>Modules Team and rarely if ever Python Modules Packaging Team any more.
>  Another opportunity for more consistency.
>
>* Clarified slightly the wording in policy differences between
>  team-in-Maintainer and team-in-Uploaders.
>
>* Remove all the references to Subversion and add a short blurb about
>Git,
>  pointing to the GitPackaging wiki page.
>
>Cheers,
>-Barry

That looks good.  The actual Python policy needs to remain separate.  That's 
something intended for the entire archive and not just the team.

Scott K

Re: Python Policy

[Piotr Ożarowski]

[Piotr Ożarowski, 2015-10-19]
> DPMT and PAPT are two different things

ups, PMPT != PAPT :)

anyway, there are only documents each DPMT should know:
* https://www.debian.org/doc/packaging-manuals/python-policy/
* https://python-modules.alioth.debian.org/policy.html

everything else can help, but if in doubt: check in above documents
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: Python Policy

[Ben Finney]

Piotr Ożarowski  writes:

> [Piotr Ożarowski, 2015-10-19]
> > DPMT and PAPT are two different things
>
> ups, PMPT != PAPT :)

So which of the following are redundant, and which names are canonical?

* Debian Python Modules Team
* Python Module Packaging Team
* Debian Python Maintainers Team

For symmetry with “Python Application Packaging Team” I was under the
impression this is the “Python Module Packaging Team”.

-- 
 \   “If you always want the latest and greatest, then you have to |
  `\  buy a new iPod at least once a year.” —Steve Jobs, MSNBC |
_o__) interview 2006-05-25 |
Ben Finney

Re: Python Policy

[Piotr Ożarowski]

[Ben Finney, 2015-10-19]
> So which of the following are redundant, and which names are canonical?
> 
> * Debian Python Modules Team
> * Python Module Packaging Team

these two are the same thing

> * Debian Python Maintainers Team

this doesn't exist AFAIK

> For symmetry with “Python Application Packaging Team” I was under the
> impression this is the “Python Module Packaging Team”.

it's completely different thing, f.e. we package applications in PAPT
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: Python Policy

[Brian May]

Barry Warsaw  writes:

> * "PMPT" policy
>   http://python-modules.alioth.debian.org/
>   git+ssh://git.debian.org/git/python-modules/tools/python-modules.git

Is policy.rst automatically kept in sync somehow in between
python-modules.git and http://python-modules.alioth.debian.org/?
-- 
Brian May 

Re: Python Policy

[Piotr Ożarowski]

[Brian May, 2015-10-20]
> Are DAPT and PAPT the same thing?

no such thing as DAPT

> This information should be documented somewhere.

should we also document that we're not OpenStack Packaging Team?

> In my words, for Debian project there is a wiki and a policy. For each
> team there is a wiki and policy that apply for that team.
> 
> The wikis are not official policy, only the policy if official policy.
> 
> I don't understand why we need two teams for Python in Debian. DPMT and
> DAPT share this mailing list. The only significant difference I see is
> one is using git and the other is using subversion.

there is one HUGE difference, one is about packaging MODULES and the
other one is packaging APPLICATIONS. One provides python-, python3-
and/or pypy- packages, the other cannot do that.

> There are packages that do not provide public modules that are aimed at
> developers. I imagine there are also packages that are end user
> applications that do provide public modules, for end user
> programming. These end user's may require the first group of packages
> aimed at developers too.

if something installs into dist-packages, it should (I'd make it a
"must", but it's just me) provide python-/python3-/pypy- binary
package. Python application should not (again, "must" is much better
here IMO) pollute global Python namespace
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: Python Policy

[Brian May]

Piotr Ożarowski  writes:

>> * The Debian wiki
>>   https://wiki.debian.org/Python and subpages
>
> wiki is something everyone can edit. It's a place that can help with
> various tasks, it can even be a place where policy is prepared, but it's
> not a place to store official documents.
>
>> * Another wiki page:
>>   https://wiki.debian.org/Teams/PythonModulesTeam
>
> this is wiki page, not a policy
>
>> * https://www.debian.org/doc/packaging-manuals/python-policy/
>>   which comes from the python-defaults (*not* python3-defaults!) in the bzr
>>   repo at
>>   http://alioth.debian.org/anonscm/bzr/pkg-python/python-defaults-debian
>
> this it THE policy (¹)
>
>> * "PMPT" policy
>>   http://python-modules.alioth.debian.org/
>>   git+ssh://git.debian.org/git/python-modules/tools/python-modules.git
>>   except that that page specifically isn't represented in the git repo, only
>>   policy.rst
>
> DPMT and PAPT are two different things

Are DAPT and PAPT the same thing?

This information should be documented somewhere.

In my words, for Debian project there is a wiki and a policy. For each
team there is a wiki and policy that apply for that team.

The wikis are not official policy, only the policy if official policy.

I don't understand why we need two teams for Python in Debian. DPMT and
DAPT share this mailing list. The only significant difference I see is
one is using git and the other is using subversion.

The description on the DAPT wiki says "We are taking care of Python
applications, i.e. end user programs written in Python that usually do
not provide public modules. We are not about packaging Python modules or
Python interpreter."

There are packages that do not provide public modules that are aimed at
developers. I imagine there are also packages that are end user
applications that do provide public modules, for end user
programming. These end user's may require the first group of packages
aimed at developers too.
-- 
Brian May 

Re: Python Policy Updates

[Jakub Wilk]

* Stefano Rivera stefa...@debian.org, 2011-03-24, 15:35:

I see we still suggest ${python:Provides}. I was encouraged in
#debian-python to never use these unless there's an existing
dependency on a versioned package name.


Correctly using python Provides is expensive. Here's why: 

“Provides: python2.X-eggs” is supposed to mean “this package provides 
module ‘eggs’ that can be imported with python2.X”. But you can claim 
that only if the package depends on the python2.X versions of all other 
modules it requires, even if some of them are arch:all! (The policy 
doesn't explain this...) Such dependencies are annoying for users and 
makes transitions harder.


Therefore, they should be avoided and used only if necessary.

Now, of course, most packages use python Provides wrongly, so it become 
essentially meaningless. I will leave as an exercise to the reader to 
check how many packages using “Provides: ${python:Provides}” has their 
dependencies correct.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110324164804.ga5...@jwilk.net

Re: Python Policy Updates

[Stefano Rivera]

Hi Jakub (2011.03.24_18:48:04_+0200)
 But you can claim that only if the package depends on the python2.X
 versions of all other modules it requires, even if some of them are
 arch:all!  (The policy doesn't explain this...)

It does say:
| Packaged modules available for one particular version of Python must
| depend on the corresponding pythonX.Y package instead. If they need
| other modules, they must depend on the corresponding pythonX.Y-foo
| packages, and must not depend on any python-foo.

which sort of covers it.

 Such dependencies are annoying for users and makes transitions harder.

More to the point, are they even necessary. When we only provide
something for python 2.6 (when 2.7 is default, before we turf 2.6), that
is a bug, and something to be fixed. If it isn't fixed, the package will
be removed when 2.6 is removed. I don't see how complex
versioned-package-names dependancies help any significant problem here.

 I will leave as an exercise to the reader to check how many packages
 using “Provides: ${python:Provides}” has their dependencies correct.

I should have made that clearer in my last e-mail. Nobody uses them
correctly. Nobody even uses them for their intended reason.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110325102450.gc24...@bach.rivera.co.za

Re: Python Policy Updates

[Stefano Rivera]

Hi Scott (2011.03.19_05:52:49_+0200)
  What else needs doing?

I suggest making it clearer in the policy that byte-compilation etc.
are best taken care of by helpers. The policy *is* probably the first
place that someone looking to create a Python module/app package will
look.

There are a few places where python-support and -central are mentioned,
but not dh_python2. Considering that -central is deprecated, dh_python2
should probably be mentioned in its place.

I'll prepare some patches.

 Comments welcome/encouraged, plus additional changes.

I see we still suggest ${python:Provides}. I was encouraged in
#debian-python to never use these unless there's an existing
dependency on a versioned package name.

There are no real packages using a name like python2.X-modulename.
I can only see 4 packages depending on one of these virtual packages.

Can we declare it deprecated?

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110324133521.ga24...@bach.rivera.co.za

Re: Python Policy Updates

[Scott Kitterman]

On Thursday, March 24, 2011 09:35:21 am Stefano Rivera wrote:
 I see we still suggest ${python:Provides}. I was encouraged in
 #debian-python to never use these unless there's an existing
 dependency on a versioned package name.
 
 There are no real packages using a name like python2.X-modulename.
 I can only see 4 packages depending on one of these virtual packages.
 
 Can we declare it deprecated?

It was my understanding that this should be used for Python extensions.  I 
think once we get to pyhton2.7 as the only supported python, it won't matter.  
I agree that ${python:Provides} is problematic, so we should consider how we 
will approach this problem in Python 3 (I don't know if we can/should handle 
it differently).

I'm interested to hear what others have to say on the topic.

Scott K


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201103240945.38085.deb...@kitterman.com

Re: Python Policy Updates

[Stefano Rivera]

Hi Scott (2011.03.24_15:45:36_+0200)
 I think once we get to pyhton2.7 as the only supported python, it
 won't matter.

As long as we handle rebuilds after every transition, it already
shouldn't matter (in Python 2 and 3). With dh_python2 we have the same
rebuild requirements, but don't suggest ${python:Provides}, I don't see
any reason to use this for extensions but not dh_python2 public modules.

 I agree that ${python:Provides} is problematic, so we should consider how we 
 will approach this problem in Python 3 (I don't know if we can/should handle 
 it differently).

And then there's PEP-384, which may negate this entirely in Python3 for
some packages...

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110324135502.gb24...@bach.rivera.co.za

Re: Python Policy Updates

[Scott Kitterman]

On Friday, March 18, 2011 10:23:05 pm Scott Kitterman wrote:
 Today's mail on XB-Python-Version motivates me to send out an overdue call
 for inputs on further changes to the Python policy.  I know that needs to
 go.
 
 What else needs doing?
 
 Personally I'd like to concentrate on getting policy for Python 3 to the
 point that it's possible to produce a correct module or extension package
 based on what's in the policy without explicitly requiring a helper of any
 kind.  I think dh_python3 is the right helper to have and it's good to use
 it, but I think policy should fully describe what someone needs to do. 
 I'd particularly appreciate inputs from everyone on this topic.
 
 Thanks,
 
 Scott K

I went through and did a bit of clarification plus added more Python 3 
specifics.  I don't think it will be controversial.  You can find the proposed 
diff here:

http://alioth.debian.org/scm/loggerhead/pkg-python/python-defaults-
debian/revision/200

Comments welcome/encouraged, plus additional changes.

Scott K


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201103182352.50329.deb...@kitterman.com

Re: Python Policy Update

[Luca Falavigna]

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

Re: python policy manual not reliable

[Matt Kraai]

On Sun, Mar 08, 2009 at 09:35:38PM -0500, Steve M. Robbins wrote:
 WWW team: how does one go about getting
 http://www.debian.org/doc/packaging-manuals/python-policy/
 removed?

I suspect what's required is to

 * modify the documentation build system to not publish this document
   and then
 * remove it from the website.

debian-doc people, does this sound right?

-- 
Matt http://ftbfs.org/


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Python Policy suggests dependencies that prevent installation

[Steve Langasek]

On Sun, Jul 23, 2006 at 07:08:52PM +0200, Loïc Minier wrote:

  Python Policy 3.2 states:

  3.2 Programs Using a Particular Python Version

  A program which requires a specific version of Python must begin with
  #!/usr/bin/pythonX.Y (or #!/usr/bin/env pythonX.Y). It must also
  specify a dependency on pythonX.Y and on any pythonX.Y-foo package
  providing necessary modules. It should not depend on any python-foo
  package, unless it requires a specific version of the package (since
  virtual packages cannot be versioned). If this is the case, it should
  depend on both the virtual package and the main package (e.g. Depends:
  python2.4-foo, python-foo (= 1.0)).

  Consider gnome-osd which depended on python2.4-pyorbit-omg before
  pyorbit was transitioned.  Now pyorbit only ships python-pyorbit-omg
  which Provides python2.4-pyorbit-omg, but users with gnome-osd
  installed -- and hence python2.4-pyorbit-omg as a real package
  installed -- won't get python-pyorbit-omg.

  Shouldn't such packages Depend on python-pyorbit-omg,
  python2.4-pyorbit-omg, even if they don't need a particular version of
  python-pyorbit-omg (contrarily to what 3.2 §2 requests)?

Are we talking about the case in which /usr/bin/python is still  2.4, or
are we talking about what such packages should do Coming Soon?

For the latter, they should obviously be fixed to not use /usr/bin/pythonX.Y
at all.

For the former, no, it's not the business of end-user packages in general to
attempt to force obsolete versions of dependencies off the system when
they're functionally compatible.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Python policy proposed changes

[Antal A. Buss]

Hi,

I don't know if it was already discussed.
If a (little) different approach is taken, such a (x)emacs or drscheme do. 

In installing time, the install script detect which version are installed (I.e. 
emacs and/or xemacs) and then compile the source for each version.

So, it's possible to install new modules to default, legacy and new version of 
Python, maintained only one package, using package dependency to know which 
Python version check.
Specific modules are installed without check installed version

Regards,

 Antal A. Buss



pgpi5TfDKk3Io.pgp
Description: PGP signature

Re: Python policy proposed changes

[Thomas Viehmann]

Antal A. Buss wrote:
 So, it's possible to install new modules to default, legacy and new version 
 of Python, maintained only one package, using package dependency to know 
 which Python version check.
 Specific modules are installed without check installed version
This is a good idea, if
- modules are compatible with the involved python versions (could be
  specified by maintainer)
- modules are pure python (i.e. compilation of C/C++.. modules at
  run-time is not an option)

Kind regards

T.

-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Python policy proposed changes

[Josselin Mouette]

Le mardi 18 octobre 2005 à 02:57 +0200, Martin v. Löwis a écrit :
 Josselin Mouette wrote:
  Apart from a typo and the FSF address, the changes are about which
  packaging variants are mandated, recommending to provide only one
  python-foo package for each module, except when depending applications
  mandate another python version.
  
  This way, we could enforce that policy during the transition, removing
  hundreds of cruft python2.X-foo packages.
 
 I don't like this policy. the python2.X-foo are not at all cruft; they
 provide a useful feature.

To what cost? How many gigabytes of mirror space and bandwidth are we
wasting with python2.X-libprout stuff nobody ever uses?

 With the multi-version build, you can support Python versions more 
 recent than the default python version, which is useful for people
 who would like to use more recent versions: they don't have to rebuild
 all their extension modules themselves.

To avoid this, as states the policy, the latest python upstream should
be the unstable version. Furthermore, is this needed that badly? It
isn't possible to use a more recent perl version, but I don't see that
many complaints from perl users.

Even in a situation like the current one, when we're stuck with 2.3 as
the default when there's 2.4 available, there are only a few python
packages which actually need the 2.4 version. In this case, the policy
states they should be built as python2.4-foo, until python2.4 becomes
the default. That's also why modules needed by a lot of binary packages
should be built as multi-binary packages, as there is a probability a
script requires both modules.

But I'm not talking about python-gtk here, I'm talking about those
hundreds of modules actually used by zero or one binary packages. Do we
need multi-binary packages for them? Compared to the waste of human and
computer resources this implies, I'm pretty sure it's not worth the
deal.

 It also simplifies the transition from one Python version to the next:
 people can build and test their packages against newer versions long
 before Debian updates the default. That way, when the default version
 changes, they just have to turn a switch in the default package. This
 reduces the amount of work necessary in the transition phase itself.

You're completely wrong. Based on the 2.2-2.3 experience, multi-binary
packages complexify the transition a lot. Instead of just a rebuild,
they require adding the new version and removing the older ones, on a
case-by-case basis, before going through the NEW queue. Believe me, it's
more work for everyone.

 Of course, supporting versions older than the default version is rarely
 needed, except when there are applications that require such older
 versions. So when 2.4 becomes the default, only 2.4 (and perhaps 2.5)
 packages should be built.

Don't you understand that it's even more added work to remove the legacy
python 2.1 to 2.3 packages in hundreds of packages ?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Python policy proposed changes

[Martin v. Löwis]

To what cost? How many gigabytes of mirror space and bandwidth are we
wasting with python2.X-libprout stuff nobody ever uses?


I don't know. What is the answer to this question? I wouldn't expect
it to be more than 1GiB per mirror, though, likely much less. On
i386, for example, the useless python2.[124]- packages for example
seem to add up to 59MiB, if I counted correctly.


Even in a situation like the current one, when we're stuck with 2.3 as
the default when there's 2.4 available, there are only a few python
packages which actually need the 2.4 version. 


What do you mean, actually need? Every python2.3-foo package actually
needs python2.4. If you have only python2.3-foo installed, and do

~$ python2.4
Python 2.4.1 (#2, May  5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
Type help, copyright, credits or license for more information.
 import foo
Traceback (most recent call last):
  File stdin, line 1, in ?
ImportError: No module named foo

This is because python2.3-foo installed into python2.3's site-packages,
so it won't be available in python2.4. You really need a separate
package for 2.4.


In this case, the policy
states they should be built as python2.4-foo, until python2.4 becomes
the default. That's also why modules needed by a lot of binary packages
should be built as multi-binary packages, as there is a probability a
script requires both modules.


This I don't understand. You mean, a script might require both
python2.3-foo and python2.4-foo if foo contains an extension module?


But I'm not talking about python-gtk here, I'm talking about those
hundreds of modules actually used by zero or one binary packages. Do we
need multi-binary packages for them? Compared to the waste of human and
computer resources this implies, I'm pretty sure it's not worth the
deal.


It's a policy decision, obviously. I wonder how many users you have
interviewed or what other criteria you have used to decide what is
best for the users. IOW, even if this policy is chosen, it lacks
rationale, IMO.


Of course, supporting versions older than the default version is rarely
needed, except when there are applications that require such older
versions. So when 2.4 becomes the default, only 2.4 (and perhaps 2.5)
packages should be built.



Don't you understand that it's even more added work to remove the legacy
python 2.1 to 2.3 packages in hundreds of packages ?


It is more work, but I don't understand why it is significantly more
work. Maintainers just have to remove all traces of 2.1, 2.2, and 2.3.
from their debian directory, and rebuild, no?

Anyway, it's hardly hundreds of. I counted 194 python2.3- packages,
82 python2.2- packages, and 46 python2.1- packages. There are also
125 python2.4- packages, so the majority of the packages has already
prepared for the transition.

Regards,
Martin


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Python policy proposed changes

[Josselin Mouette]

Le mardi 18 octobre 2005 à 10:24 +0200, Martin v. Löwis a écrit :
  Even in a situation like the current one, when we're stuck with 2.3 as
  the default when there's 2.4 available, there are only a few python
  packages which actually need the 2.4 version. 
 
 What do you mean, actually need? Every python2.3-foo package actually
 needs python2.4. If you have only python2.3-foo installed, and do
 
 ~$ python2.4
 Python 2.4.1 (#2, May  5 2005, 11:32:06)
 [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
 Type help, copyright, credits or license for more information.
   import foo
 Traceback (most recent call last):
File stdin, line 1, in ?
 ImportError: No module named foo
 
 This is because python2.3-foo installed into python2.3's site-packages,
 so it won't be available in python2.4. You really need a separate
 package for 2.4.

I don't understand your approach of the issue. The default python
version is available in the python command, and all modules should be
available when launching python, not python2.4.

  In this case, the policy
  states they should be built as python2.4-foo, until python2.4 becomes
  the default. That's also why modules needed by a lot of binary packages
  should be built as multi-binary packages, as there is a probability a
  script requires both modules.
 
 This I don't understand. You mean, a script might require both
 python2.3-foo and python2.4-foo if foo contains an extension module?

No, I mean a script using the foo module, which is only available for
python 2.4, might also require the gtk module, as the latter is widely
used. That's a reason to build a module like gtk in a multi-binary
fashion.

 It's a policy decision, obviously. I wonder how many users you have
 interviewed or what other criteria you have used to decide what is
 best for the users. IOW, even if this policy is chosen, it lacks
 rationale, IMO.

The rationale is to save mirror size, bandwidth and Packages size, and
to make things clearer to our users. It is your rationale which I wonder
about. You want all modules to be available for all python versions?
What does it bring to our users? When using python, you're using the
python binary, you don't want to ask yourself what version to use.

  Don't you understand that it's even more added work to remove the legacy
  python 2.1 to 2.3 packages in hundreds of packages ?
 
 It is more work, but I don't understand why it is significantly more
 work. Maintainers just have to remove all traces of 2.1, 2.2, and 2.3.
 from their debian directory, and rebuild, no?

It's the just that bothers me. It's not a just when you're talking
about rebuilding 200 packages.

 Anyway, it's hardly hundreds of. I counted 194 python2.3- packages,
 82 python2.2- packages, and 46 python2.1- packages. There are also
 125 python2.4- packages, so the majority of the packages has already
 prepared for the transition.

You mean that's only 3 percent of the total number of packages that
could be saved?

Regards,
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Python policy proposed changes

[Donovan Baarda]

On Tue, 2005-10-18 at 08:23, Josselin Mouette wrote:
 Le mardi 18 octobre 2005 à 02:57 +0200, Martin v. Löwis a écrit :
  Josselin Mouette wrote:
[...]
 But I'm not talking about python-gtk here, I'm talking about those
 hundreds of modules actually used by zero or one binary packages. Do we
 need multi-binary packages for them? Compared to the waste of human and
 computer resources this implies, I'm pretty sure it's not worth the
 deal.

Just because there are no Debian packages that depend on them, doesn't
mean they aren't used. A simple example is python2.1-mysqldb. I'm pretty
sure there would be no Debian packages that use it, but anyone
developing/testing for python2.1 that needs to talk to a mysql database
will need it. The fact that Ubuntu has it made my life much easier...

  It also simplifies the transition from one Python version to the next:
  people can build and test their packages against newer versions long
  before Debian updates the default. That way, when the default version
  changes, they just have to turn a switch in the default package. This
  reduces the amount of work necessary in the transition phase itself.
 
 You're completely wrong. Based on the 2.2-2.3 experience, multi-binary
 packages complexify the transition a lot. Instead of just a rebuild,
 they require adding the new version and removing the older ones, on a
 case-by-case basis, before going through the NEW queue. Believe me, it's
 more work for everyone.

This is why I suggested that the policy recommend seperate python-foo
and pythonx.y-foo source packages for multi-version support. Have the
pythonx.y-foo source package build all the pythonX.Y-foo binary
packages, and have a simple python-foo source package build the small
binary python-foo wrapper package. This way, when python transitions,
only the small python-foo source package needs to have it's dependencies
updated, so only the small python-foo binary wrapper package gets
re-built. The pythonx.y-foo source package and pythonX.Y-foo binary
packages don't need to be touched.

  Of course, supporting versions older than the default version is rarely
  needed, except when there are applications that require such older
  versions. So when 2.4 becomes the default, only 2.4 (and perhaps 2.5)
  packages should be built.
 
 Don't you understand that it's even more added work to remove the legacy
 python 2.1 to 2.3 packages in hundreds of packages ?

So why remove them? If they aren't being re-built, they are not being
updated, and hence are not being re-mirrored. Sure, they are using disk
space on the mirrors, but it's not that much, and they are not eating
bandwidth, which is the bit that really hurts.

Rather than add the burden of removing legacy packages into the
transition process, by de-coupling them Python can transition first, and
then the legacy packages can be kept or removed at the individual
package maintainers discretion later.

This only applies to multi-version supporting packages... 

-- 
Donovan Baarda [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Python policy proposed changes

[Martin v. Löwis]

Josselin Mouette wrote:

Apart from a typo and the FSF address, the changes are about which
packaging variants are mandated, recommending to provide only one
python-foo package for each module, except when depending applications
mandate another python version.

This way, we could enforce that policy during the transition, removing
hundreds of cruft python2.X-foo packages.


I don't like this policy. the python2.X-foo are not at all cruft; they
provide a useful feature.

With the multi-version build, you can support Python versions more 
recent than the default python version, which is useful for people

who would like to use more recent versions: they don't have to rebuild
all their extension modules themselves.

It also simplifies the transition from one Python version to the next:
people can build and test their packages against newer versions long
before Debian updates the default. That way, when the default version
changes, they just have to turn a switch in the default package. This
reduces the amount of work necessary in the transition phase itself.

Of course, supporting versions older than the default version is rarely
needed, except when there are applications that require such older
versions. So when 2.4 becomes the default, only 2.4 (and perhaps 2.5)
packages should be built.

Regards,
Martin


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Python policy proposed changes

[Donovan Baarda]

On Tue, 2005-10-11 at 20:23, Josselin Mouette wrote:
 Le lundi 10 octobre 2005 à 17:01 +0100, Donovan Baarda a écrit :
  In 2.2.2, I would remove the only from only supports python versions
  different from the currrent default one... You can use this for
  packages that support the current default one as well as other versions.
 
 The next section deals about such a scheme.

OK.

  In 2.2.3, part 1. I would recommend (mandate?) that the python-foo dummy
  wrapper package should have it's own tiny source package, seperate from
  the pythonX.Y-foo source package. This way, only the small python-foo
  wrapper package needs to be updated and re-built when the default python
  changes.
 
 I think the ftp-masters and/or release would object to having so many
 more source packages to deal with; I've heard it would cause problems
 when we went up with this kind of idea for GNOME metapackages.

What is worse, an extra very small source package, or a single large
source package that generates x large + 1 small binary packages (where
x=number of python versions supported) and gets upgraded more
frequently. 

As an end user on a modem I know downloading all the binary packages
again when really only the python-foo wrapper dependencies changed hurts
much more, and I suspect this hurts mirrors more too.

  For 2.2.3 part 2, I don't know what to do... there has been no progress
  in making this work for a long time, and I don't know if there ever will
  be. It's probably still worth documenting as a wish list, but I can't
  help but think it's overly complicated somehow.
 
 I agree, maybe we should remove documentation about things not working.

But it is handy to have wishlist stuff documented somewhere... perhaps a
wishlist bug?

  Another alternative for 2.2.3 part 2 is the practice adopted by some
  pure-python packages of putting modules in /usr/lib/site-python, which
  can be found on the default sys.path of all versions of python. The
  ugliness of this is the pyc's get recompiled for different versions of
  python, and will be re-written if the user has write access there. For
  all it's drawbacks, it is a much lighter alternative to the mass of
  symlinks approach...
 
 I wouldn't recommend this method, because of that possible .pyc
 autogeneration and the stale files it leaves in the filesystem.

It doesn't really leave stale pyc's, as they should still get cleaned up
when the package is removed. What it does mean is the pyc's that are
there might not be compiled for the right version. To help ensure that
they are compiled for the right version, the python.postinst should
re-compile everything in /usr/lib/site-python...

Another option would be for python.postinst to trigger
dpkg-reconfigure's for everything that has Depends: python.


-- 
Donovan Baarda [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Python policy proposed changes

[Donovan Baarda]

On Tue, 2005-10-11 at 20:29, Josselin Mouette wrote:
 Le lundi 10 octobre 2005 à 17:14 +0100, Donovan Baarda a écrit :
  The best person to decide what packages need to support which old
  versions of python are the package maintainers. They know this based on
  the requests and bug reports from the people that need them. It is up to
  them to balence the hassle of packaging them against the hassle of
  dealing with complaints.
 
 You are right, that's up to the maintainer.

BTW, at a large search engine company where I now work, it has proven
useful that Ubuntu still has legacy Python packages for v2.1 through
v2.4. If it didn't, we would be forced to build/support our own (which
we may yet need to do).

So even if Debian chooses not to support legacy versions of Python,
please keep a framework that makes it easy to add extra packages to
support it :-)

-- 
Donovan Baarda [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Python policy proposed changes

[Josselin Mouette]

Le lundi 10 octobre 2005 à 17:01 +0100, Donovan Baarda a écrit :
 In 2.2.2, I would remove the only from only supports python versions
 different from the currrent default one... You can use this for
 packages that support the current default one as well as other versions.

The next section deals about such a scheme.

 In 2.2.3, part 1. I would recommend (mandate?) that the python-foo dummy
 wrapper package should have it's own tiny source package, seperate from
 the pythonX.Y-foo source package. This way, only the small python-foo
 wrapper package needs to be updated and re-built when the default python
 changes.

I think the ftp-masters and/or release would object to having so many
more source packages to deal with; I've heard it would cause problems
when we went up with this kind of idea for GNOME metapackages.

 For 2.2.3 part 2, I don't know what to do... there has been no progress
 in making this work for a long time, and I don't know if there ever will
 be. It's probably still worth documenting as a wish list, but I can't
 help but think it's overly complicated somehow.

I agree, maybe we should remove documentation about things not working.

 Another alternative for 2.2.3 part 2 is the practice adopted by some
 pure-python packages of putting modules in /usr/lib/site-python, which
 can be found on the default sys.path of all versions of python. The
 ugliness of this is the pyc's get recompiled for different versions of
 python, and will be re-written if the user has write access there. For
 all it's drawbacks, it is a much lighter alternative to the mass of
 symlinks approach...

I wouldn't recommend this method, because of that possible .pyc
autogeneration and the stale files it leaves in the filesystem.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: This is a digitally signed message part

Re: Python policy proposed changes

[Donovan Baarda]

On Sun, 2005-10-09 at 13:36, Josselin Mouette wrote:
 Le dimanche 09 octobre 2005 à 14:30 +0200, Matthias Klose a écrit :
[...]
  I don't like the idea that maintainers of depending
  applications have to fight with maintainers of library packages,
  which versions they should provide.
 
 Maybe we could make it easier; for example only modules with more than
 $threshold (say 5) depending applications should provide several
 versions, while less widely used modules shouldn't.

I think it is up to the package maintainers... fights are how you
convice package maintainers to support older versions :-)

The best person to decide what packages need to support which old
versions of python are the package maintainers. They know this based on
the requests and bug reports from the people that need them. It is up to
them to balence the hassle of packaging them against the hassle of
dealing with complaints.

You could institute some degree of manditory legacy support, but exactly
what the degree is would be kind of hard to pin down.

By recommending 2.2.1 Support Only The Default Version, we are
recommending no legacy support. It would be interesting to see just how
many packages end up providing legacy support anyway after a period of
time. I have a feeling Zope and Mailman dependencies will end up
defining the extent of legacy support.

-- 
Donovan Baarda [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Python policy proposed changes

[Matthias Klose]

Josselin Mouette writes:
 Apart from a typo and the FSF address, the changes are about which
 packaging variants are mandated, recommending to provide only one
 python-foo package for each module, except when depending applications
 mandate another python version.
 
 This way, we could enforce that policy during the transition, removing
 hundreds of cruft python2.X-foo packages.

we should deprecate building python2.1-foo and python2.2-foo versions
of the packages, I don't like the idea that maintainers of depending
applications have to fight with maintainers of library packages,
which versions they should provide.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Python policy update

[Lars Wirzenius]

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

[Donovan Baarda]

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

[Joe Wreschnig]

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

[Josselin Mouette]

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

[Josselin Mouette]

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

[Donovan Baarda]

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/

Re: Python policy update

[Derrick 'dman' Hudson]

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

[Andreas Rottmann]

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

[Donovan Baarda]

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]

Re: python policy is unclear on whether python programs should be arch all or arch any

[Torsten Landschoff]

On Sun, Jan 13, 2002 at 10:53:53AM +0900, Junichi Uekawa wrote:
 
 During discussion in debian-devel, it was pointed out that 
 byte-compiled python code is cross-platform, and thus it should be 
 architecture: any.

I think you mean arch: all. Any means a rebuild for each architecture.

More interestingly the python policy should mention how to handle 
byte-compiled code. My packages are building them on installation
and I think this is the way how it should be. I am not sure if the 
same .pyc file runs on all systems...

Greetings

Torsten


pgpBoBWbxxENO.pgp
Description: PGP signature