[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Specifying Supported Python Versions - Round 2



On Jun 30, 2010, at 04:58 PM, Scott Kitterman wrote:

>On Wednesday, June 30, 2010 04:51:38 pm Piotr Ożarowski wrote:
>> [Scott Kitterman, 2010-06-30]
>> 
>> > 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.
>> 
>> why? If py3versions is invoked in debian/rules, then there definitely is
>> at least one python3-* binary package. Why do you want to make this
>> field required? I'd make it optional and assume all 3.X versions if
>> X-P3-V is not set.
>
>I'm trying to minimize the amount of implicit magic we do.
>
>There was strong consensus for Python 2 that "all" wasn't a great idea for XS-
>P-V and so we point people away from it.  No implicit all seem the logical 
>next step for Python 3 were we have more freedom to make things work the way 
>we want.
>
>If there's some consensus for an implicit "all" in Python 3, I won't object.

The question that comes to mind is why Python 2 and Python 3 would have
different rules?  If there's a good reason (e.g. it cleans up a backward
compatibility wart), then cool.  If not, then consistency between the two
might make a reasonable default.

-Barry

Attachment: signature.asc
Description: PGP signature


Reply to: