On 25May2016 1229, Chris Barker wrote:
Hi folks,
The standard build of Py3.5 for Windows is built with VS2015 (correct??)
And it includes the runtime dlls it needs.
However, we've found that wxPython wheels for win32 (not sure about
win64) also need:
MSVCP140.DLL
There are two different versions of this DLL for each architecture (same
name).
So: wxPython could include that of course, But it looks like it's
getting included with the Matplotlib wheels already (so folks with
Matplotlib can run wx....). I'm just guessing, but this looks like the
standard run time for C++ with that compiler.
Python itself doesn't use C++, of course, but maybe we should include
that dll with Python anyway -- that way folks can build wheels of
packages with C++ extensions in the normal way, and those wheels will
"just work", and we don't have to have every individual package ship the
same dll.
Unfortunately, it won't "just work". More often than not, it will break
in weird and very difficult to diagnose ways, as the version of
msvcp140.dll changes on a regular basis (there are at least four
different version of it "in the wild" since VS 2015 released, not
counting the preview releases before mid-last year).
Importantly, it will break forward compatibility. We are already on the
hook to keep shipping vcruntime140.dll for all 3.5 (and probably 3.6)
releases, and if binary packages are built with later versions of VS
then they'll need to include a (hypothetical) vcruntime150.dll (which
distutils will already do, because I added that functionality). Other
than that, every dependency of Python 3.5+ is forwards-compatible with
new operating systems and compilers.
There's also a slippery slope argument that would legitimately justify
shipping all sorts of "common" dependencies with the core product. I
chose to draw the line at "needed by the core Python product", rather
than "created by Microsoft" or "used by many packages". (Hence
vcruntime140.dll is included, despite not having forwards-compatibility,
and I tried real hard to avoid including that one too.)
Finally, unless we demand users are administrators for every install, we
will quickly have many Python installs using versions of msvcp140.dll
(or any other dependency) with security vulnerabilities, with no way to
update them other than a full Python release. Installing the regular
runtime (which is patched automatically) or as part of a package (which
can be independently updated) is far more feasible. I really don't want
to be doing security updates for 15 years just to keep an unused DLL secure.
Hopefully that helps explain the position somewhat. I'm happy to go into
more detail on any of these issues if anyone would like (potentially
just linking to where I've previously discussed it either here, on
bugs.p.o or on my blog).
Cheers,
Steve
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
