[Python-Dev] PEP 0404 and VS 2010

[Chris Barker]

On Thu, Nov 21, 2013 at 10:53 AM, Christian Tismer <tismer at stackless.com>wrote:

> I also think having a 2.8 out there that is exactly the same as 2.7,
>> except that it was built with a different version of a compiler on one
>> particular platform is a very very bad idea.
>>
> This was not my proposal. I was seeking a way to make a version that
> produces no collisions with DLLs, and it was a question about Stackless,
> not Python. But I admit that I was not aware of a license problem.
>
>
well, as you said below, you want to keep binary compatibility between
stackless and cPython, right down to the same dll name, so yes, it is about
Python. And since we are talking about it -- it actually would be nice to
be able to have a builds of python for Windows (any version) that are
not restricted to one compiler version per python version. (Like a VS2010
py2.7, for example, but not JUST that)


>> So if a different build of 2.7 for Windows is put out there, we need to
>> make sure it reports the platform in a way that wheel and pip can make the
>> distinction.
>>
>>
> That was the reason to change the number. If other approaches like a
> different
> name for certain things is easy to do, I am fine with that, too.


well, there is precedent for that with the OS-X builds -- so reasonable
enough. However, that really only helps for binary wheels and pip -- which
haven't been widely adopted yet (to put it mildly!). So maybe a new dll
name makes sense -- honestly  while some of how Windows handles dlls makes
"dll hell" inevitable, it's made worse by really short dll names, and
re-using names even when versions change -- we're so far past the 8.3
world, I have no idea why that's still done.

so a python27_VS_2010.dll or something might make sense.

Throw some info in there about 64 vs 32 bit too? or is it enough that the
linker will let you know if there is a problem?

It might be nice to patch the win_inst too--IIRC it's still not very smart
>> about even 32 vs 64 bit builds.
>>
>> As for stackless--just to be clear--can you use extensions built with the
>> "regular" python with a stack less binary? If so, I understand the concern.
>> If not, then it seems stackless is a separate ecosystem anyway.
>>
>
> Good question, and this _is_ a problem:
> Minus a few number of things, Stackless is almost completely binary
> compatible with extensions, and people _will_ want to try Stackless for
> some
> things or might want to go back and use CPython, be it only to remove
> concerns of
> a customer.
> People do want to install binary packages which are not built for
> Stackless,
> and we always did best efforts to support that.
>
> That means: basically we want to improve the situation for Stackless-based
> project in the first place, but make it easy to go back to CPython.
> We have a compiler switch that can completely remove the stackless
> additions and create a 100 % binary identical CPython version!
>
> That implies in the end that extension modules which work with Stackless
> will also be runnable on CPython 2.7.x VS2010 or whatever name it is.
> The naming problem then comes in again through the back-door,
> and we cannot shut our eyes and pretend "hey it is Stackless",
> because that is admittedly close to a fraud.
>
> So even if VS2010 exists only in the stackless branch, it is very likely
> to get used as CPython VS 2010, and I again have the naming problem ...
>

Just to be clear here:

You want to be able to create a non-stackless, regular old CPython binary
built with VS2010. (which is also compatible with  stackless build)

OK, now:

Do you want people to be able to use extensions built by third parties for
python.org CPython with your binary builds?

If so, then there will need to be a python.org binary built with VS2010,
and a way that makes it hard for people to try to use extensions built for
a different VS-version-build.

If not, then the only problem is that users of your VS2010-built binary
will go off willy nilly and try to use extensions built for
python.orgbuilds, and they may appear to work at first glance, but may
do weird
things or crash unexpectedly.

I'd say the issue there is education as much as anything.

Or couldn't you simply install your binary somewhere other than
C:\python27? (and use different registry setting or whatever so the windows
installers will not get confused?)

The other potential route for error is a pip install -- you don't want pip
to find a binary that is incompatible with your build -- so you should
assure that whatever pip/wheel uses to identify the build is
set differently in your build (see the relevant PEPs).

Note that for OS-X we have some of the same issues -- what with Homebrew
and Macports, and Apple, and ... there are a lot of potentially binary
incompatible builds of PythonX.Y out there. I don't think the issue really
is safely resolved, but at a policy level, I THINK the conclusion on the
distutils list was to declare that we only support binary wheels on PyPi
for the python.org builds. Users of other builds should use their build
system to get binaries (much like Linux).

That policy is more or less in place already for Windows, though pretty
much defacto, as there aren't any other widely used Windows binaries out
there. (there is Cygwin though, and I think it reports itself as a
different platform).

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131121/c3c37a90/attachment.html>