Sorry, the below looks like a forwarded message but the top most level writing is mine (yay managing multiple email accounts):
> On 20/03/14 03:53, Donald Stufft wrote:
>>
>> On Mar 19, 2014, at 12:03 PM, Paul Moore <p.f....@gmail.com> wrote:
>>
>>> On 19 March 2014 15:46, Donald Stufft <don...@stufft.io> wrote:
>>>>
>>>> How would you specify that a Wheel is only viable on Python 3.2 and not
>>>> Python 3.3?
>>>
>>> You can't. The way the tags are checked simply doesn't allow that -
>>> Python 3.3 accepts a py32 tag. (This is why I was careful to say I
>>> didn't want to change how tags were checked - this is arguably the
>>> wrong way to do it, Daniel and I had a bit of a debate over it when he
>>> first implemented it, but changing it would be backward incompatible
>>> and I didn't want to go there at this point).
>>>
>>> The relevant code is at
>>> https://github.com/pypa/pip/blob/develop/pip/pep425tags.py#L51
>>
>> It would be backwards incompatible to the implementation, but not to the
>> Spec. I do think either the spec needs to be updated or the code needs
>> to be updated. Either way I don’t think there is going to be many (any?)
>> one relying not this currently. To me it feels like smell to have both
>> py30 and py3 mean the same thing *and* it feels surprising to me (having
>> read the spec multiple times but not the implementation).
>
> To me, the spec is fine - excerpt from 425:
>
> > It is recommended that installers try to choose the most feature complete built distribution available (the one most specific to the installation environment) by default before falling back to pure Python versions published for older Python releases.
>
> So a pure py32 tag should work fine for python 3.3, which is what pip should hopefully be doing. Binary packages obviously aren't pure so a python 3.3 shouldn't try to install a py3.2 tagged binary distribution.
>
>>
>> That’s not exactly the case, I’ve put errors in setup.py’s that raised an
>> error rather than installed on Pythons that I knew didn’t work.
>>
>> I think if we take the stance that the code is correct and the spec is wrong
>> then py2 and py3 should be deprecated in favor of py30 and py20. Those
>> are more accurately describing what those tags *actually* mean and are
>> going to be less confusing than having py2, py26, py27, py3, py32, py33.
>
> Naively to me, "py20" is confusing at first glance (really I imagine people will be asking "why is there a 0 there? I don't support python 2.0..."), whereas "py2" is not confusing. It just says to me that this distribution hopes to be compatible with python 2 in general. Note that "py2.py3" is really an optimistic tag at the moment, e.g there are probably many of them that are not compatible with python 3.1 or 2.4. I think it's important to ask in general whether you can be certain about python compatibility, or just optimistic. I think it can be realistic to be more certain about compatibility with binary tags any, but only really optimistic with a pure package - because you could be running on *anyone's* implementation.
> For pure packages, I can't imagine why pyMN meaning compatible with >= M.N wouldn't make sense, and it's not a problem with binary packages because they're always ==. I think the wording for the py2 != py20 is meant to take binary packages into account. E.g, if somehow you had a py4 binary package that wouldn't be a py40 binary package.
>
> --
> Matt Iversen
> PGP: 0xc046e8a874522973 // 2F04 3DCC D6E6 D5AC D262 2E0B C046 E8A8 7452 2973
That's cool. I'm happy to go with that. Do you know what the process
> After reading this, and looking at distlib (which implements it similarly to pip)
> and pip, and thinking about it some more. I think we should just update
> the current PEP to specify that pyXY (and only pyXY) is defined to be
> "or later" and we should suggest that in most situations py2 or py3 is probably
> more reasonable. I don't think there's any harm in leaving the spec more capable
> incase someone does need that ability. This could be handled as that spec
> was just underspecified.
is for updating the PEP? Presumably I'll need to create a PR against
the PEP repository. I'll have a word with Nick once the discussion
settles down.
> want to use as well as --universal which will do py2.py3.
> I think that Wheel should change to defaulting to pyX instead of pyXY but that
> there should be an easy way to specify exactly which compatibility tags you
Yeah, that's easy enough to do. Matt Iversen had a PR implementing an
option to specify the exact tag you want (although he was using the
adhoc "wheel" section of setup.cfg). I can see about creating a new PR
taking the best ideas from the current two.
One question, though. Assuming (for the sake of argument) that we go
with a syntax of --impl=py32, then what should happen if the user
specifies --impl=py32 and the project includes a C extension (for
added fun, if there's an optional speedup extension)?
I'm not quite sure if we're thinking of the same things here - I
wasn't thinking about warnings. I was thinking about users making
mistakes and ending up with wrongly-tagged wheels.
I would prefer it remain in mercurial.
The bookmarks extension seems the most promising and there are advanced history edit and changeset states features in the latest version. Unfortunately I have not used them that much.