Paul "TBBle" Hampson added the comment: If this is just a documentation fix, then there's two places that need it:
* https://github.com/python/cpython/blob/master/Tools/msi/README.txt contains the text I quoted in the original report. * Some kind of release note (https://docs.python.org/3/whatsnew/3.5.html) so that things that have relied on this behaviour in the past (e.g. gvim with the Python3/dynamic build option) can have all their documentation updated to tell people to... I don't know? Grab the embedded version into the gvim install directory? What _is_ the recommended approach here, to give system-wide-installed applications access to a system-wide-installed Python environment? ============================================== I don't agree that this change is correct. It's inconsistent with the Linux experience of an all-users installation (i.e. anything on the system can link against libpython2.7.so and get the expected behaviour of using the system-installed Python) and I would also consider an All-Users install to *be* a system component, since the intent is clearly to make it available to all users and applications without further effort. Unlike putting python.exe in the path, the DLLs are version-named, so you don't suffer the conflict of *which Python* you get. The Python Launcher for Windows has taken care of that nicely, and if I have to add all the Python install directories to my path to ensure the DLLs are visible to applications that link against them, that seems to be a regression in the behaviour that launcher was trying to fix. An issue I see with the embedded installation approach is that if I want to make modules available to something like gvim's Python environment, then I need to maintain those modules distinctly from the modules I maintain on the system level. It also means I need to be modifying gvim's install directory to add that embedded distribution, and that leaves a whole bunch of manual tracking of installed things I need to worry about. I have the same concerns (manual tracking of things) if I have to add extra infrastructure to manage a copy of python3.X.dll in System32. Searching Google for this issue suggests that many people are just grabbing a random DLL off the internet named python3.5.dll and putting it in System32 when they encounter this problem, because "it used to work with Python 3.2". Alternatively... Does it make sense to have a "System Component" installer version of Python for use by other applications that want to offer (optional) Python interpreter support? It would be pretty-much identical to the installer we have now, except putting the DLL entry point (python3.x.dll) into the system path, but not having python.exe in the path to confuse command-line usage. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29844> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
