On Thursday, July 07, 2011 08:43:29 AM Jakub Wilk wrote:
> * Scott Kitterman <deb...@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
--
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/201107070927.03824.deb...@kitterman.com
