Re: New python-defaults upload to experimental

[Scott Kitterman <debian@kitterman.com>]

On Thursday, July 07, 2011 08:43:29 AM Jakub Wilk wrote:
> * Scott Kitterman <debian@kitterman.com>, 2011-07-07, 01:30:
> >I've just uploaded 2.7.2-2 to experimental.  It's mostly about
> >dh_python2 improvements from POX, but also has some minor updates to
> >Python Policy that I think improve the currency of it a bit.  Please
> >review the changes and I'll fix them up if I got it wrong.  Diff of the
> >text version attached.
> 
> (I took my liberty to convert your diffs to wdiff output, which is more
> readable.)
> 
> >     The goal of these policies is to reduce the work necessary for Python
> >     transitions.  Python modules are internally very dependent on a
> >     specific Python version.  [-However, we want to automate recompiling
> >     modules when possible, either during the upgrade itself
> >     (re-byte-compiling pyc and pyo files) or shortly thereafter with
> >     automated rebuilds (to handle C extensions).-]  These policies
> >     encourage automated dependency generation and loose version bounds
> >     whenever possible.
> 
> I don't understand this change.
> 
> Who decided that automated re(byte)compiling is not a laudable goal
> anymore?
> 
> Or is it just you want to promote a tool that does not comply to the
> original Python Policy goals and you are worried that somebody will
> notice?

If I wanted to avoid notice, I wouldn't have posted the diff to the list.  

At the time I wrote it, I considered that we had rather given up on that goal 
and so describing it in policy would be wrong (it's my understanding that as a 
general rule in Debian policy should describe practice, not lead it), but your 
mail caused me to reconsider it.

From a user perspective automatic re(byte)compiling still happens with 
dh_python2.  What's different is not bytecompliing, but symlink shuffling.  In 
python-support and python-central (by default) symlinks got moved around at 
run time.  In dh_python2 the symlinks are moved at build time.  From a user 
perspective the difference is faster, more reliable upgrades.

I'll put it back the way it was since we still do this.

> >     Python packages are {+either files or+} directories containing at
> >     least a `__init__.py', other modules, extensions and packages (A
> >     package in the Python sense is unrelated to a Debian package). 
> >     Python packages must be packaged into the same directory (as done by
> >     upstream). Splitting components of a package across directories
> >     changes the import order and may confuse documentation tools and
> >     IDEs.
> 
> Err, this change is incorrect. Please see
> http://docs.python.org/tutorial/modules.html#packages
> for the definition of Python package.
> 
> That said, I don't quite understand what this paragraph is supposed to
> mean. I'd remove it entirely.

I'll do that.  We do have Python module packages that ship the entire package 
in one file and not in a dir with an __init__.py, so I changed it to match, but 
I agree repeating upstream definitions isn't ideal.  I'll incorporate the 
reference instead.

> >     [-The-]
> >     python-support {+is deprecated.  It was+} system [-provides-]
> >     {+intended to provide+} a simple way to byte-compile pure Python
> >     modules and manage
> >     dependencies.  It integrates with `debhelper', manages
> 
> Only intended to? Also, I don't see any reason to use past tense here.
> 
> >     python-central [-provides-] {+is deprecated.  It provided+} another
> >     way to manage Python modules.  It integrates with `debhelper',
> >     manages
> 
> I don't see any reason to use past tense here either.

I'll change those back.

Thanks for reviewing,

Scott K