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: New, updated pip coming

[Julien Cristau]

On Fri, Jan 29, 2016 at 18:28:53 -0500, Barry Warsaw wrote:

> I don't actually know whether Built-Using *does* anything useful[*], but IWBNI
> (maybe) some kind of notification or auto-rebuild happened.  I don't think it
> does, but Donald's right.  It's the same problem that Go or statically linked
> C/C++ has.
> 
ATM there's no automatic rebuild for out of date built-using.  Its main
use is to force the archive software to keep the source packages listed
as Built-Using in the archive, to comply with GPL requirements.

Cheers,
Julien
-- 
Julien Cristau  
Logilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances

Re: New, updated pip coming

[Piotr Ożarowski]

Hi Barry,

Did you consider creating whl files at install time¹ rather than pip's
build time? This way whl can be regenerated whenever one of needed
packages is updated and there's no need to rebuild pip package.

[¹] using dpkg (file) triggers (/usr/share/doc/dpkg-dev/triggers.txt.gz)
-- 
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: How to put experimental upload into git

[Barry Warsaw]

On Feb 01, 2016, at 08:10 AM, Nikolaus Rath wrote:

>Commit to a new branch that then becomes dangling, because the next upload to
>unstable descends from the most-recent unstable upload rather than from
>experimental.

I haven't done this specifically, but I have used branches w/git-dpm.  I can't
say if been particularly successful at it for more complex (long-running)
cases.  But your case sounds relatively simple so I'd probably do what you
suggest above.

Cheers,
-Barry

How to put experimental upload into git

[Nikolaus Rath]

Hello,

I'd like to upload the newest python-llfuse release to 
experimental first.


Are there any best practices for handling this on the git side? I 
could imagine:


* Don't commit anything to git at all (it would only be a single 
commit 
  for the upload), commit when uploading to unstable.


* Commit regularly, with the upload to unstable becoming a 
descendant 
  of the upload to experimental.


* Commit to a new branch that then becomes dangling, because the 
next 
  upload to unstable descends from the most-recent unstable 
  upload rather than from experimental.


Thoughts?

Thanks,
-Nikolaus

(No Cc on replies please, I'm reading the list)
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

»Time flies like an arrow, fruit flies like a Banana.«

Re: How to put experimental upload into git

[Stefano Rivera]

Hi Nikolaus (2016.02.01_18:10:28_+0200)
> I'd like to upload the newest python-llfuse release to experimental first.
> 
> * Commit regularly, with the upload to unstable becoming a descendant   of
> the upload to experimental.

I think it's perfectly reasonable to have experimental uploads like this
in master. If you need to do another unstable upload that precedes it
(which seems rare in these cases), you can always go back and start a
diverging branch.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: New, updated pip coming

[Barry Warsaw]

On Feb 01, 2016, at 03:01 PM, Piotr Ożarowski wrote:

>Did you consider creating whl files at install time¹ rather than pip's
>build time? This way whl can be regenerated whenever one of needed
>packages is updated and there's no need to rebuild pip package.
>
>[¹] using dpkg (file) triggers (/usr/share/doc/dpkg-dev/triggers.txt.gz)

I did think about it, and maybe it's where we want to end up, but I didn't go
this way right now because of the added complexity.  Well, maybe "different"
complexity, since none of this stuff is simple. ;)

What we have now is better than what we had before, but once I get virtualenv
fixed and uploaded, I think I'll come back around to looking at what you
suggest.  (Certainly, patches welcome in the meantime.)  Fortunately, I
believe we have all the tools in place (e.g. dirtbike) to generate the wheels
at install time.  It does mean some extra run-time dependencies, but that's
probably fine.

Cheers,
-Barry