Re: Specifying Supported Python Versions - Round 2
"Sandro Tosi" <morph@debian.org> wrote:
>Hi Scott,
>thanks for bringing this up (again :) ).
>
>On Wed, Jun 30, 2010 at 22:41, Scott Kitterman <debian@kitterman.com> wrote:
>> As I had said I would after the last round, I asked the release team about any
>> specific requirements they might have for Python version specification. They
>> don't. My summary of the thread is "We want it to be easy". The thread
>> starts here for those interested:
>>
>> http://lists.debian.org/debian-release/2010/06/msg00211.html
>>
>> Based on the previous discussion here and feedback on IRC, here is a revised
>> proposal:
>>
>> For Python(2):
>>
>> pyversions -r will use (in this order):
>>
>> 1. A new field called X-Python2-Version: This is identical to the current XS-
>> P-V, except it doesn't get exported to the source Packages.{gz,bz2}, and it
>> does not support lists of versions (e.g. (2.4, 2.5, 2.6) is not supported).
>> Acceptable values are a single version (e.g 2.6), greater than or equal to a
>> version (e.g. >= 2.5), or strictly less than a version (e.g. << 2.7).
>> Versions 3 or greater will raise an error.
>
>Will this make XS-P-V a sort of "Deprecate"? I find the semantic of
>X-P2-V clearer than XS-P-V, but I just want to know how hard are you
>going to push it (if we're going to migrate to it, it requires a
>change a lot of packages)
Sort of deprecated, yes. I'd rather focus on getting Python 3 packages right than retrofitting improved semantics on Python 2 packages.
If the Python 3 stuff goes well, I think we'll tend to pick this up over time. I believe it's premature to have a strong view on how hard to push it.
>> 2. XS-Python-Version: The same as it is currently, except versions 3 or
>> greater will raise an error. This will require at least two packages to have
>> to be changed. I'd appreciate it if someone could check if anything other
>> than python-apt and pyyaml are affected.
>>
>> 3. debian/pyversions: Same as XS-Python-Version.
>
>Please, pretty please, can we drop support for it? Is that really an
>hassle to remove it? Or there are some advantages of having it around
>I don't see? There should be one, and possibly only one, way to
>specify python versions.
I agree, but it's widely used by python-support. Unless Joss is supportive of moving away from it, I don't think it's manageable anytime soon.
>> 4. Implicit "all" supported Python 2 versions (currently 2.5 and 2.6).
>
>You mean not specifying any X-P2-V or XS-P-V, 'all' is implicitly used
>for 2.x supported versions? I'd rather explicit than implicit, so
>raise error if not present.
I agree on this also, but many, many packages rely on it and so I think we are stuck with it for Python 2. If we encourage people to document their X-P-V at the same time they add X-3P-V, maybe this will become tractable in the future.
>> For Python3:
>>
>> 1. A new field called X-Python3-Version: It does not support lists of
>> versions (e.g. (3.0, 3.1)). Acceptable values are a single version (e.g 3.1),
>> greater than or equal to a version (e.g. >= 3.1), or strictly less than a
>> version (e.g. << 3.2). Versions 2 or less will raise an error.
>>
>> 2. There is no #2. If your build system uses py3versions -r, then you need
>> X-P3-V, if it's not there, an error will be raised. If it doesn't use
>> py3versions -r, then it's between the maintainer and their build system. The
>> field is not mandatory.
>
>both points fine for me.
>
If you like this, please convince Piotr that implicit all is bad.
Scott K
Reply to: