[Python-Dev] runtime dlls on Windows

[Chris Angelico]

On Fri, May 27, 2016 at 2:42 AM, Chris Barker <chris.barker at noaa.gov> wrote:
> On Wed, May 25, 2016 at 1:40 PM, Chris Angelico <rosuav at gmail.com> wrote:
>>
>> But why should CPython
>> package a runtime that it doesn't use?
>
>
> Because it IS part of the "standard runtime environment" that cPython is
> providing. The cPython Windows builds are built with a particular compiler
> that expects a particular runtime. C++ is part of that runtime, even if the
> cPython code itself doesn't use that part. I'm sure there are features in
> the C runtime DLL that cPython doesn't happen to use, either. The fact that
> it's a separate dll is kind of an implementation detail.

I'm not sure that it is an implementation detail; it's indicative that
the compiler/runtime designers intended for the C runtime to be able
to be distributed without the C++ runtime. You wouldn't expect to have
to ship a Fortran runtime and a Cobol runtime, even if MSVC happened
to package up compilers for all of the above, would you?

>> Which is more common - someone
>> uses two C++ modules, or someone uses none of them?
>
>
> Irrelevant -- which is the bigger problem for users? a lot of folks getting
> an extra dll as part of a large install that they  aren't using, or folks
> getting cryptic error messages and/or every package builder of C++ packages
> having to identify and solve the problem?

I agree with you that end users getting cryptic error messages is a
problem. But the choice of solutions is:

1) CPython ships the C++ runtime that it doesn't use, in case someone
pip-installs something that needs it
2) Package authors who choose to use C++ must ship the C++ runtime.

Even apart from the DLL Hell that Steve mentioned, the second option
appears more sane. Package authors get the freedom to choose any
runtime dependencies they want, and then they package them or make it
possible to obtain them.

> BUT -- Steve Dower seems to have identified that the wonders of dll hell
> never cease, and this isn't possible anyway. Oh well.
>

I'm not entirely grasping what's happening here. There are multiple
versions of msvcp140.dll floating around out there; what happens if
one app requires one of them and another requires another? Can you
simply say "take the newer one"? Is there a way to instantly recognize
that there's a newer one available, and ignore the older one?
Versioning is a *pain*.

ChrisA