Steve Dower added the comment:
We can't have Python run VCredist because it requires administrative privileges
and installing Python does not require those. This is actually one of the
biggest complaints about the current installer, but because it looks like the
design and not a bug it only comes up when you ask people directly what they'd
like to change. (The most common bug is pip failing to install/uninstall, which
is what you see on the issue tracker.)
The other benefits are that PYDs compiled with VS 2016+ (or whatever it's
called) with these options will work with stock Python 3.5 on a clean machine -
so if your extension links to python3.dll you can build once for all Python
versions 3.5 and later and know that it will just copy and run. If you're
building from source and only have a newer compiler than VC14, you will be able
to build successfully. Also, we could decide to build some future Python 3.5.x
with a newer compiler as it should not break any existing extensions (after
much discussion and testing, obviously, but it is only feasible if we properly
hide the VC version now).
To achieve these (apart from the last point) with VCredist, we need to be
installing the current and all future versions of the redist with Python. Hence
a time machine is required, and I haven't come up with any good way to simulate
a time machine here.
> not when even MS itself recommends against doing this.
I have separate advice (also from MS, from the same people who have been quoted
previously, but in private conversations so I can't link to it) that if we want
any chance of our plugin architecture being VC version independent, this is
what we have to do. I'm emailing again to get more specific advice, but the
official guidance has always been biased by wanting people to get the latest
tools (which is why VC9 disappeared until my team made the case that sometimes
people can't upgrade). We're still pushing hard to make this an acknowledged
use case, and don't be surprised if at some point in the future official advice
says "if you allow plugins, do what CPython did to help your users and
developers".
The "/MT" == "statically linked" equivalence is an oversimplification in the
presence of link-time code generation ("/GL" and "/LTCG" options), as we can
take .obj or .lib files compiled with /MT and still use dynamic linking. The
difference is we have to do it explicitly, which is what the
"/nodefaultlib:libucrt.lib ucrt.lib" options do. If we add concrt140, msvcp140
and vccorlib140 to that as well (and probably the rest of the versions
redistributables) then all of them will continue to be dynamically linked.
So basically, all the existing static libs could be built with /MT and still
have their dependencies dynamically linked if that's what the final linker
decides to do. In any case, they probably need to be rebuilt with VC14 unless
the authors have very carefully kept a clean API, in which case it may as well
be a DLL.
Because we're talking about a plugin architecture here, I think it's actually
advantageous to use static linking of the C++ runtime. The main difference from
the C runtime is that the C++ runtime does not have to be shared with the host
- Python - and the advantage is that state will not be shared with other
plugins that also happen to use the same version of C++ (or worse, a different
version with the same name, and now we have a conflict).
I appreciate the problems this causes when trying to link in 3rd-party
dependencies, but given a choice between making life easier for developers or
users I have to side with the users (while doing as much as I possibly can to
make developers lives easier). People installing wheels from Christoph's page
or PyPI should be able to expect it to work. When pip grows extensions I'll
certainly look into writing an extension for specifying, detecting and getting
the required VC redistributable, but I don't want core Python to be burdened
with shipping the full set of distributables.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
