[Python-Dev] Python 2.7 patch levels turning two digit

[Donald Stufft]

On Jun 23, 2014, at 5:07 PM, M.-A. Lemburg <mal at egenix.com> wrote:

> On 23.06.2014 22:20, Donald Stufft wrote:
>> 
>> On Jun 23, 2014, at 3:27 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>> 
>>> On 23.06.2014 18:09, Donald Stufft wrote:
>>>> 
>>>> On Jun 23, 2014, at 2:09 AM, Martin v. Löwis <martin at v.loewis.de> wrote:
>>>> 
>>>>>> 
>>>>>> * Should we make use of the potential breakage with 2.7.10
>>>>>> to introduce a new Windows compiler version for Python 2.7 ?
>>>>> 
>>>>> Assuming it is a good idea to continue producing Windows binaries
>>>>> for 2.7, I think it would be a bad idea to switch compilers. It will
>>>>> cause severe breakage of 2.7 installations, much more problematic
>>>>> than switching to two-digit version numbers.
>>>> 
>>>> I agree with this, we’ve just finally started getting things to the point where
>>>> it makes a lot of sense for binary distributions for Windows. Breaking all
>>>> of them on 2.7 would be very bad.
>> 
>> Err, sorry that “We” was with my pip hat on.
>> 
>>> 
>>> Not sure what you mean. We've had binary wininst distributions
>>> for Windows for more than a decade, and egg and msi distributions
>>> for 8 years :-)
>> 
>> Nonetheless, changing the compiler will not only break pip, but every
>> automated installer tool (easy_install, buildout) that i’m aware of. The
>> blow back for binary installation is going to be huge I think.
>> 
>>> But without access to the VS 2008 compiler that is needed to
>>> compile those extensions, it will become increasingly difficult
>>> for package authors to provide such binary packages, so we have to
>>> ask ourselves:
>>> 
>>> What's worse: breaking old Windows binaries for Python 2.7
>>> or not having updated and new Windows binaries for Python 2.7
>>> at all in a few years ?
>> 
>> At the risk of getting Guido to post his slide again, I still think the
>> solution to the old compiler is to just roll a 2.8 with minimal changes.
>> It could even be a good place to move to the ssl backport changes
>> too since they were the riskier set of changes in PEP466.
>> 
>> But either way, if a compiler does change in a 2.7 release we’ll need
>> to update a lot of tooling to cope with that, so any plan to do that should
>> include that and a timeline for adoption of that.
> 
> Sure, and we'd need to hash out possible solutions to minimize
> breakage, but first we'll have to see whether we want to consider
> this step or not.
> 
> 
> BTW: It's strange that I'm arguing for breaking things. I'm usually
> on the other side of such arguments :-)

Ok. I’m just making sure that any proposal to do this includes how
it plans to work around/minimize that. I agree with Martin (I think)
that trying to fix the entire ecosystem to cope with that change is
going to be far more work than folks realize and that it needs to
be an explicit part of the discussion when deciding how to solve
the problem.

Normally when I see someone suggest that switching compilers
in 2.7.x is likely to be less work than releasing a 2.8 It normally
appears to me they haven’t looked at the impact on the packaging
tooling.

> 
> -- 
> Marc-Andre Lemburg
> eGenix.com
> 
> Professional Python Services directly from the Source
>>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
> ________________________________________________________________________
> 
> ::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
> 
> 
>   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>           Registered at Amtsgericht Duesseldorf: HRB 46611
>               http://www.egenix.com/company/contact/


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140623/b8709c16/attachment.sig>