[issue36441] Cannot create venv with debug binaries installed
New submission from Christian Ullrich : Creating a venv using "py -m venv" fails when the debug binaries are installed in the system-wide installation. Note the below uses the 32-bit installation, but that is probably not significant. C:\Daten\pyv>py -3.7-32 -m venv v37-32 Error: [Errno 2] No such file or directory: 'C:\\Program Files (x86)\\Python37-32\\lib\\venv\\scripts\\nt\\python_d.exe' The same command line works fine when using a Python installation that does not have the debug binaries installed. -- components: Windows messages: 338904 nosy: chrullrich, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Cannot create venv with debug binaries installed type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue36441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36441] Cannot create venv with debug binaries installed
Christian Ullrich added the comment: Python version is 3.7.3. -- ___ Python tracker <https://bugs.python.org/issue36441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35797] concurrent.futures.ProcessPoolExecutor does not work in venv on Windows
Christian Ullrich added the comment: I have two ideas, but no idea if either is remotely feasible: 1. Replicate the launcher's selection logic in multiprocessing and avoid the intermediate step via sys.executable. Perhaps put it into pythonXX.dll or export it from the launcher executable so the C implementation can be shared by both users. 2. Handle the command line argument(s) that control how multiprocessing pulls the handle from the parent process in the launcher and perform the operation so the sub-subprocess can in turn get it from the launcher. I had a third one, but it was so crazy I must have preemptively forgotten it. Finally, I do not think this is a regression in 3.7 (although I have not tested it with anything earlier), but unless the implementation of multiprocessing has changed radically in 3.7 I cannot see how it could have (not) worked any differently before. On the other hand, venv is essentially the "official" way of installing Python applications these days, so the issue should have a high priority for fixing anyway. -- ___ Python tracker <https://bugs.python.org/issue35797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35797] concurrent.futures.ProcessPoolExecutor does not work in venv on Windows
New submission from Christian Ullrich : Using concurrent.futures.ProcessPoolExecutor on Windows fails immediately with a lot of exceptions of the "access denied", "file not found", and "invalid handle" varieties. Running the script that creates the ProcessPoolExecutor from the main system-wide installation works correctly. Due to Windows' infamous lack of fork(), ProcessPoolExecutor launches its worker processes by setting up an inheritable handle to a pipe and passing the handle on the command line. In a venv situation, it appears that the venv's python.exe internally launches the parent environment's python.exe and passes on its command line, but not its handle table. This sub-subprocess therefore does not have the original handle, and may have a different handle at the same index. Output of the ProcessPoolExecutor example program from the docs when run with the main installation: C:\Daten>py cft.py 112272535095293 is prime: True 112582705942171 is prime: True 112272535095293 is prime: True 115280095190773 is prime: True 115797848077099 is prime: True 1099726899285419 is prime: False Output when run using a venv: C:\Daten>pyv\v37\Scripts\python.exe cft.py Process SpawnProcess-4: Traceback (most recent call last): File "C:\Program Files\Python37\lib\multiprocessing\process.py", line 297, in _bootstrap self.run() File "C:\Program Files\Python37\lib\multiprocessing\process.py", line 99, in run self._target(*self._args, **self._kwargs) File "C:\Program Files\Python37\lib\concurrent\futures\process.py", line 226, in _process_worker call_item = call_queue.get(block=True) File "C:\Program Files\Python37\lib\multiprocessing\queues.py", line 93, in get with self._rlock: File "C:\Program Files\Python37\lib\multiprocessing\synchronize.py", line 95, in __enter__ return self._semlock.__enter__() PermissionError: [WinError 5] Access is denied Process SpawnProcess-5: Traceback (most recent call last): File "C:\Program Files\Python37\lib\multiprocessing\process.py", line 297, in _bootstrap self.run() File "C:\Program Files\Python37\lib\multiprocessing\process.py", line 99, in run self._target(*self._args, **self._kwargs) File "C:\Program Files\Python37\lib\concurrent\futures\process.py", line 226, in _process_worker call_item = call_queue.get(block=True) File "C:\Program Files\Python37\lib\multiprocessing\queues.py", line 93, in get with self._rlock: File "C:\Program Files\Python37\lib\multiprocessing\synchronize.py", line 95, in __enter__ return self._semlock.__enter__() PermissionError: [WinError 5] Access is denied Traceback (most recent call last): File "cft.py", line 28, in main() File "cft.py", line 24, in main for number, prime in zip(PRIMES, executor.map(is_prime, PRIMES)): File "C:\Program Files\Python37\lib\concurrent\futures\process.py", line 476, in _chain_from_iterable_of_lists for element in iterable: File "C:\Program Files\Python37\lib\concurrent\futures\_base.py", line 586, in result_iterator yield fs.pop().result() File "C:\Program Files\Python37\lib\concurrent\futures\_base.py", line 432, in result return self.__get_result() File "C:\Program Files\Python37\lib\concurrent\futures\_base.py", line 384, in __get_result raise self._exception concurrent.futures.process.BrokenProcessPool: A process in the process pool was terminated abruptly while the future was running or pending. -- assignee: docs@python components: Documentation, Library (Lib), Windows messages: 334142 nosy: chrullrich, docs@python, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: concurrent.futures.ProcessPoolExecutor does not work in venv on Windows type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35374] Windows doc build does not find autodetected hhc.exe
Change by Christian Ullrich : -- keywords: +patch pull_requests: +10084 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35374] Windows doc build does not find autodetected hhc.exe
New submission from Christian Ullrich : If hhc.exe is on the PATH when HTML Help is being built, the build fails because make.bat does not correctly remember the fact. The set command is very finicky with trailing spaces, leading to this: '"hhc "' is not recognized as an internal or external command, operable program or batch file. I suppose the "official" build does not rely on autodetection. In that case, a better fix would be to require setting HTMLHELP explicitly. PR (for the single-character fix) incoming. -- assignee: docs@python components: Documentation messages: 330872 nosy: chrullrich, docs@python priority: normal severity: normal status: open title: Windows doc build does not find autodetected hhc.exe type: compile error ___ Python tracker <https://bugs.python.org/issue35374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35228] Index search in CHM help crashes viewer
Christian Ullrich added the comment: Ma Lin, thanks for the suggestion! Yes, it looks like this option fixes the problem. I can reproduce the crash at will with a .chm built without this option, and not at all with one that has it on. If the .chm's directory is not writable, the .chw will be created, and later reused from, %APPDATA%\Microsoft\HTML Help. Unfortunately, sphinx apparently has no facility for setting this option to Yes in the generated .hhp file, so it will have to be modified before compilation. -- ___ Python tracker <https://bugs.python.org/issue35228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35228] Index search in CHM help crashes viewer
New submission from Christian Ullrich : Typing into the index keyword field frequently crashes the CHM viewer with the first or second character. The Python CHMs are the only ones that I see this crash with; it started around 3.6 or so. >From event log: Faulting application name: hh.exe, version: 10.0.17134.1, time stamp: 0xa0eff942 Faulting module name: hhctrl.ocx, version: 10.0.17134.48, time stamp: 0x412ce02a Exception code: 0xc005 Fault offset: 0x000387b2 Faulting process ID: 0x3558 Faulting application start time: 0x01d47b3f8db53eef Faulting application path: C:\Windows\hh.exe Faulting module path: C:\Windows\System32\hhctrl.ocx Report ID: 53f84d38-adb4-4c0b-bd45-9bce02406e6f Faulting package full name: Faulting package-relative application ID: This particular crash involved the file from 3.7.1: sha1(doc\python371.chm) = 1c0e2d861cadc759436bfac0a767c5bb633423f9 -- assignee: docs@python components: Documentation, Windows messages: 329824 nosy: chrullrich, docs@python, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Index search in CHM help crashes viewer type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31349] Embedded initialization ignores Py_SetProgramName()
Christian Ullrich added the comment: Not quite. Looking a bit further down get_progname()'s weird logic, we see that it works like this: 1. prog = Py_GetProgramName() 2. progpath = GetModuleFileNameW() 3. if (prog is empty): prog = "python" 4. if (slash in prog): # Or backslash, of course progpath = prog So it uses the host process name from step 2 (i.e. progpath) whenever Py_SetProgramName() has not been used and step 3 has set prog to a value not containing a directory separator (or if it *has* been used to set something with no such separator in it). The logic makes sense, I think, but it is quite impenetrable. Any chance of PEP 432 ("Restructuring the CPython startup sequence") happening this century? -- ___ Python tracker <http://bugs.python.org/issue31349> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31349] Embedded initialization ignores Py_SetProgramName()
Christian Ullrich added the comment: That should have been diff --git a/PC/getpathp.c b/PC/getpathp.c index e7be704a9a..abb5e54c9f 100644 --- a/PC/getpathp.c +++ b/PC/getpathp.c @@ -443,8 +443,7 @@ get_progpath(void) #else dllpath[0] = 0; #endif -if (GetModuleFileNameW(NULL, progpath, MAXPATHLEN)) -return; +GetModuleFileNameW(NULL, progpath, MAXPATHLEN); if (prog == NULL || *prog == '\0') prog = L"python"; instead, of course, without the negation. -- ___ Python tracker <http://bugs.python.org/issue31349> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31349] Embedded initialization ignores Py_SetProgramName()
New submission from Christian Ullrich: I'm trying to do something that may be slightly tricky, and I think I just found a vintage 1997 bug. Please correct me if I'm wrong. This is PC/getpathp.c from current master: 430: static void 431: get_progpath(void) 432: { 433: extern wchar_t *Py_GetProgramName(void); 434: wchar_t *path = _wgetenv(L"PATH"); 435: wchar_t *prog = Py_GetProgramName(); 436: 437: #ifdef Py_ENABLE_SHARED 438: extern HANDLE PyWin_DLLhModule; 439: /* static init of progpath ensures final char remains \0 */ 440: if (PyWin_DLLhModule) 441: if (!GetModuleFileNameW(PyWin_DLLhModule, dllpath, MAXPATHLEN)) 442: dllpath[0] = 0; 443: #else 444: dllpath[0] = 0; 445: #endif 446: if (GetModuleFileNameW(NULL, progpath, MAXPATHLEN)) 447: return; 448: if (prog == NULL || *prog == '\0') 449: prog = L"python"; Lines 446-447 have been like this ever since Guido wrote them twenty years ago. I think the logic is the wrong way around. As it is now, the function always returns on line 447 because GetModuleFileNameW() *always* succeeds (returns nonzero). Hence, everything below line 447 is dead code. GetModuleFileNameW(NULL, ...) fills the buffer with the path to the executable the current process was created from. It returns the number of characters put into the buffer, or zero on error. However, the only way *this* call could fail is if the code was being executed outside of any process, something that clearly cannot happen. Prior to August 1997, the relevant bit of code looked like this: 156:if (!GetModuleFileName(NULL, progpath, MAXPATHLEN)) 157:progpath[0] = '\0'; /* failure */ This bug, if it is one, would only manifest when initializing an embedded interpreter using a different argv[0] than that of the actual host process, because if the host process is a python.exe, it very likely runs inside a standard installation or venv anyway. What I am trying is to make an interpreter running in a third-party host process take site-packages from a venv. Doing this (argv[0] different from actual host process) may not be entirely proper itself, but then again, why would Py_SetProgramName() even exist otherwise? Suggested fix: diff --git a/PC/getpathp.c b/PC/getpathp.c index 8380e1bcfa..abb5e54c9f 100644 --- a/PC/getpathp.c +++ b/PC/getpathp.c @@ -443,8 +443,7 @@ get_progpath(void) #else dllpath[0] = 0; #endif -if (!GetModuleFileNameW(NULL, progpath, MAXPATHLEN)) -return; +GetModuleFileNameW(NULL, progpath, MAXPATHLEN); if (prog == NULL || *prog == '\0') prog = L"python"; Since the call to GetModuleFileNameW() cannot possibly fail, there is no real point in checking its return value. -- components: Windows messages: 301306 nosy: Christian.Ullrich, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Embedded initialization ignores Py_SetProgramName() type: behavior versions: Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue31349> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30611] Windows HTML Help always opens maximized
Christian Ullrich added the comment: I'll have to start with the ceterae again, won't I? OK, since you asked: Ceterum censeo: This behavior could have been easily adapted to differing local requirements if MSI had been used as the distribution package format by appropriately transforming the Shortcut table at install time, but burn bundles do not expose an interface to apply transforms to individual component MSIs, needlessly disabling this unique advantage of the Windows Installer technology. (Apologies to people who know Latin. Unless I'm really lucky here.) Not sure if the tracker will let me close the bug myself; if it doesn't, know that I have tried. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue30611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30612] Unusual Windows registry path syntax
Christian Ullrich added the comment: Out of curiosity, can you point me to an example or two? I have been living with, though not in, Win32 for quite a few years myself, and I can say with certainty that I have never seen this notation before in my life. Other than that, PR on the way soonish. -- ___ Python tracker <http://bugs.python.org/issue30612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30612] Unusual Windows registry path syntax
New submission from Christian Ullrich: In 3.6.1, the manual, section 3.1.3, has this to say: "Your administrator will need to activate the “Enable Win32 long paths” group policy, or set the registry value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem@LongPathsEnabled to 1." Separating a value name from the key path with an @-sign, which is what the above is doing, is something I have never before seen anywhere. I suggest changing it by either: - replacing the instructions for the manual change with a link to <https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath> or a more suitable reference (I could not find a KB article when I looked) - rewording it as, e.g., ... in the registry key HKEY_...FileSystem, set the REG_DWORD value LongPathsEnabled to 1 The value type could be left out; the value is predefined on all platforms where it will be effective. -- assignee: docs@python components: Documentation messages: 295505 nosy: Christian.Ullrich, docs@python priority: normal severity: normal status: open title: Unusual Windows registry path syntax type: enhancement versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue30612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30611] Windows HTML Help always opens maximized
New submission from Christian Ullrich: The CHM help files on Windows always open maximized. I would prefer they opened in a regular window instead, because the current behavior is annoying. Fix: In Tools/msi/doc/doc.wxs line 34, change 'Show="maximized"' to 'Show="normal"'. -- assignee: docs@python components: Documentation, Windows messages: 295503 nosy: Christian.Ullrich, docs@python, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows HTML Help always opens maximized type: behavior versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue30611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29911] Uninstall command line in Windows registry does not uninstall
Christian Ullrich added the comment: Thank you. As for the pointing out: It worked for Cato, didn't it? He may not have lived to see it, but his perseverance in the face of rejection eventually brought about the years-long bloody war he had dreamed about. (Any historical inaccuracies in the above are the property of the author.) -- ___ Python tracker <http://bugs.python.org/issue29911> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29911] Uninstall command line in Windows registry does not uninstall
New submission from Christian Ullrich: The Windows installation package registers a command line for uninstalling the package. Running this command line does not uninstall the package. The command line ends with "/modify". For uninstallation, it should be "/passive /uninstall". Windows provides for separate command lines for modifying and uninstalling packages to be set in the "Uninstall" subkey: - ModifyPath: Command line for modifying the package - UninstallString: Command line for removing the package By setting both keys, the ARP control panel will display separate buttons for the two operations. Having an uninstallation command line that does not do what it says, and in fact causes modal UI to be presented, also interferes with automated package management. Ceterum censeo: This bug would have been avoided by using MSI as the distribution package format, because "msiexec /qn /x [ProductCode]" would have been correct regardless of what the registry says, and even if the registry does not say anything because the Uninstall key (as well as the uninstaller executable itself) were actually deleted months ago as part of some expired user profile. See bug #25166. -- components: Windows messages: 290544 nosy: Christian.Ullrich, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Uninstall command line in Windows registry does not uninstall type: behavior versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue29911> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25166] Windows AllUsers installation places uninstaller in user profile
Christian Ullrich added the comment: This bug has been open for over a year and two subsequent releases, and its planned resolution depends on a change to WiX. The related WiX bug (see comment above) is scheduled to be implemented in WiX 4.0, which has no prospective release date. According to <https://github.com/wixtoolset/issues/milestone/4>, only 27 percent of the issues currently planned for this release are resolved. In my opinion, this is an important bug that cannot wait indefinitely. Ceterum censeo (yes, there had to be one): This is particularly true when considering that a (relatively) simple fix exists that can be done by the Python project alone, with no external dependencies. I am referring, of course, to dropping the burn bundle entirely and shipping a single MSI package again, rather than 43 (!) of them (across x86 and amd64) with an average of ~190 and a median of 8 (eight) installed files per package in 3.5.2, counting pip. -- ___ Python tracker <http://bugs.python.org/issue25166> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27410] DLL hijacking vulnerability in Python 3.5.2 installer
Changes by Christian Ullrich : -- nosy: +Christian.Ullrich ___ Python tracker <http://bugs.python.org/issue27410> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25636] Let launcher autoselect best 32-bit Python on 64-bit system
New submission from Christian Ullrich: As described in PEP 397, the launcher can autoselect the "best" Python version available on a system, or a full version number (major.minor) can be specified. In the latter case, optionally a "-32" suffix can be given to select a 32-bit version, which is useful on 64-bit systems where a 64-bit Python is also present. By default it will select the highest (native) version. I have an application that runs unmodified on Python 3.[345], but only with the 32-bit version because it loads a DLL (this is on Windows, but I think the basic issue applies to other systems as well) that has no 64-bit version available. I would like to run it on any system that has *any* suitable Python installed. However, with the version selection syntax supported by the launcher, I can only demand a 32-bit version if I also specify the Python minor version I want, and I do not necessarily know that in advance. What I would like the launcher to support is a version specification that allows using the "-32" suffix in all possible combinations with version numbers: py -3.5-32 (same as today, 32-bit Python 3.5) py -3-32 (highest 32-bit Python 3) py -32 (highest 32-bit Python available) The last form above, with no major version given, would look for the highest minor version in the default major version. The syntax might have to be different for compatibility reasons, although both incomplete specifications would result in an error message in all released versions. I have been looking for a reason this limited syntax was chosen, but there has not to my knowledge been any discussion of this change on python-dev, and the May 2011 revision to PEP 397 ("based on python-dev feedback") in which it was introduced over the original, more flexible syntax also gives no further hint about its reasoning. Solving this in application code could be done, of course, but both apparent solutions are incredibly ugly: - Reimplementing the version autoselection by listing the available 32-bit versions. - "Shooting blind", invoking every possible version from the top down until one works. "3.5-32? Nope. 3.4-32? Nope. 3.3-32? Yes!" This approach has the added downside that the launcher may not be in the $PATH at all. That is improbable, but possible. I would much rather leave the work to the launcher, where the required knowledge is obviously available. Thanks for hearing me out :-) -- messages: 254742 nosy: Christian.Ullrich priority: normal severity: normal status: open title: Let launcher autoselect best 32-bit Python on 64-bit system type: enhancement ___ Python tracker <http://bugs.python.org/issue25636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25166] Windows AllUsers installation places uninstaller in user profile
New submission from Christian Ullrich: A system-wide installation on Windows (using InstallAllUsers=1) still places the uninstall executable into the profile (%LOCALAPPDATA%) of the installing user. If that user profile is deleted, the (system-wide) installation cannot be removed anymore. Ceterum censeo: This bug would have been avoided by using MSI as the distribution package format. -- components: Installation, Windows messages: 250962 nosy: Christian.Ullrich, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows AllUsers installation places uninstaller in user profile versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue25166> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25165] Windows uninstallation should not remove launcher if other versions remain
New submission from Christian Ullrich: Uninstalling 3.5 on Windows removes the py.exe launcher. If it was installed in the system-wide path (%SYSTEMROOT%), it may have replaced an existing copy from an earlier version. In this case, removing the launcher will break this remaining installation, requiring a repair. Instead, the launcher should not be deleted. It uses the static CRT, hence has no DLL dependencies that would be removed by the uninstallation, and it will -- as PEP 397 demands -- select the Python version it starts based on the command line and the available installations. Ceterum censeo: This bug could have been avoided by using MSI as the distribution package format and using the same component code for the launcher file in all supporting versions. Even if the file itself is different, the identical component code would have ensured through reference counting that it would only have been removed with the last referencing installation. Upward compatibility of older launchers could have become a problem, though. -- components: Installation, Windows messages: 250957 nosy: Christian.Ullrich, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows uninstallation should not remove launcher if other versions remain type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue25165> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25164] Windows default installation path is inconsistent between per-user and system-wide installation
New submission from Christian Ullrich: On Windows, a per-user installation uses %LOCALAPPDATA%\Programs\Python\Python35 as the default target directory. A system-wide (InstallAllUsers=1) installation, however, goes into "%PROGRAMFILES%\Python 3.5" instead. The two directory names should be consistent with each other (and with earlier versions), that is, should be "Python35" in all cases. -- components: Installation, Windows messages: 250956 nosy: Christian.Ullrich, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows default installation path is inconsistent between per-user and system-wide installation type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue25164> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25163] Windows installer in AllUsers mode presents wrong installation path
New submission from Christian Ullrich: When run with InstallAllUsers=1, the Windows installer displays (%LOCALAPPDATA%)\Programs\Python\Python35 as the installation target directory, but actually installs into the path for a system-wide installation, "%PROGRAMFILES%\Python 3.5". Ceterum censeo: This bug could have been avoided, and would certainly have been detected in time, by using MSI as the distribution package format. Because most MSI UI will display TARGETDIR as the target directory, an accidental override (or missing override) of this path would have been obvious. -- components: Installation, Windows messages: 250955 nosy: Christian.Ullrich, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows installer in AllUsers mode presents wrong installation path type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue25163> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25162] Windows installation does not appear in list of installed applications
New submission from Christian Ullrich: The new Windows installer always places the uninstallation registry key into HKCU of the executing user. This is correct for a per-user installation, but when run with InstallAllUsers=1, the key should go into HKLM instead. The "Programs and Features" list of installed applications is assembled from the HKLM and HKCU keys. In many cases, a system-wide installation will be performed by temporarily elevating the installer to a user account with administrator privileges on the local system. However, since Vista, the "Programs and Features" list is always run in the logged-on user's Explorer process, even when started by a different user (such as in an elevated command prompt). With the uninstallation key going into HKCU of some administrative account, the Python installation will not appear in this list, hence, cannot easily be removed. Ceterum censeo: This bug would have been avoided by using MSI as the distribution package format. -- components: Installation, Windows messages: 250954 nosy: Christian.Ullrich, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows installation does not appear in list of installed applications type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue25162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25124] No single .msi available for 3.5 release
New submission from Christian Ullrich: The item "A new installer for Windows has replaced the old MSI" appears on the "What's new" page as an "improvement". It is not. I disagree strongly with the decision to abandon MSI packages for Windows distribution in 3.5. This decision should be reversed immediately, if not sooner. The .msi package format was introduced well over ten years ago. Since that day, there has been *no* excuse at all to distribute software for Windows in any other form (except "a simple ZIP will do"). The MSI file format's main advantage over ad-hoc executable installers or wrappers is in automated installation. There are several ways to deploy software in a corporate network, such as SCCM/SMS and GPO. While the former can deal with .exe packages, using MSIs is much simpler. In an MSI, the Feature table offers clear information about how to install only part of a product (ADDLOCAL=x,y,z either works as intended or fails cleanly). An .exe wrapper does not provide this information in an obvious way, instead, the user has to rely on external documentation to discover the installable features. Python's Windows packages have been exemplary for years. This change needlessly gives up this reputation. As far as the Universal CRT is concerned, for which there are no redist MSIs available, it should be clear that Python is not responsible for installing it, as it is a system component now. If ucrtbase.dll/KB2999226 is not present on the target system, the Python installation should simply abort and inform the user about the missing prerequisite. (Also, as Microsoft is pushing it into the market at seemingly any cost, the market share of Windows 10 with included UCRT is likely to increase quickly, making the wrapper ever more unnecessary. Servers are, of course, another story.) Finally, just in case there were any plans on display for the last several months: I do not usually venture into basements to check for leopards. Python's Windows packaging was perfectly fine, and there was no reason to assume that this would change, rather the opposite, in fact. -- components: Installation messages: 250756 nosy: Christian.Ullrich priority: normal severity: normal status: open title: No single .msi available for 3.5 release versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue25124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21030] pip usable only by administrators on Windows and SELinux
Christian Ullrich added the comment: Actually, this appears to be fixed in pip 1.5.6 (and 1.5.5, commit 79408cbc6fa5d61b74b046105aee61f12311adc9, AFAICT), which is included in 3.4.1; I cannot reproduce the problem in 3.4.1. That makes this bug obsolete. -- ___ Python tracker <http://bugs.python.org/issue21030> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21030] pip usable only by administrators on Windows
Christian Ullrich added the comment: Unprivileged users cannot install into the global site-packages, but they might want to use the global pip to install with --user. Also, this issue affects not only pip, but also the other bundled packages, i.e. setuptools and pkg_resources. -- ___ Python tracker <http://bugs.python.org/issue21030> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21030] pip usable only by administrators on Windows
Christian Ullrich added the comment: According to procmon, ensurepip first installs the bundled packages in $TEMP, then moves the resulting files to the Python installation directory. According to http://support.microsoft.com/kb/310316, a file that is moved within the same volume keeps its original ACL and does not inherit permissions from its new parent directory. I can think of two ways to fix this: 1. Instead of moving the files, copy them (and delete the originals) 2. Reset the ACLs after the move. The icacls commands I posted earlier will work, but icacls may not be available with the same option set on all supported Windows versions. Of the two, #1 is probably more reliable. -- ___ Python tracker <http://bugs.python.org/issue21030> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21030] pip usable only by administrators on Windows
New submission from Christian Ullrich: After installing python-3.4.0.amd64.msi on Windows 8.1 x64, the "pip" command (and the versioned ones as well) only work for administrators. Regular users get this: Traceback (most recent call last): File "C:\Program Files\Python34\lib\runpy.py", line 171, in _run_module_as_main "__main__", mod_spec) File "C:\Program Files\Python34\lib\runpy.py", line 86, in _run_code exec(code, run_globals) File "C:\Program Files\Python34\Scripts\pip.exe\__main__.py", line 5, in ImportError: cannot import name 'main' The immediate reason is that the files in the site-packages/pip directory are created with no access permissions for non-administrators: C:\Program Files\Python34\Lib\site-packages\pip>icacls __main__.py __main__.py NT-AUTHORITY\SYSTEM:(F) BUILTIN\Administrators:(F) abc\Admin:(F) Why that is, I have no idea. It can be fixed by running: icacls path\to\site-packages\pip /inheritance:e /t icacls path\to\site-packages\pip /reset /t The /reset may be unnecessary. -- components: Installation, Windows messages: 214527 nosy: Christian.Ullrich priority: normal severity: normal status: open title: pip usable only by administrators on Windows type: behavior versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue21030> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com