[issue42192] Python Windows .exe Installer ignores /TargetDir if there is an existing installation
Martin Gfeller added the comment: Thanks again Steve. I will copy the installation. I require a lot of pip packaged, so the embeddable distro doesn't look right for my case. I still think the /targetdir should issue some kind of warning if used with an existing installation, but this is obviously lowest prio. -- ___ Python tracker <https://bugs.python.org/issue42192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42192] Python Windows .exe Installer ignores /TargetDir if there is an existing installation
Martin Gfeller added the comment: Thank you, Steve, for your rapid response and explanation! I would like to have my installation fully isolated in case somebody (running the machine) fiddles with the installation in the standard location. I used to do that without problems with the 2.7 .msi installer, but now I’ve finally almost finished converting to 3.8 (I know I’m late) and that approach doesn’t work any longer. I tried to reverse engineer it a bit by looking at the log files and zapping the registry entry HKLM\Software\Python\PythonCore\3.8 (for an all-users install), with no success. Modify or repair would randomly install some stuff in the target dir and other stuff into a previous installation. The Windows Installer technology seems to be rather implicit than explicit. How does it detect the previous installation’s location? Although it’s not a bug and an /isolated mode doesn’t seem to be feasible, perhaps it could check and warn that /targetdir is being ignored. The doc could mention that it’s intended only for a single installation per version per machine. And thank you again for your contributions to make Python on Windows such a joy – highly appreciated! Martin -- ___ Python tracker <https://bugs.python.org/issue42192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42192] Python Windows .exe Installer ignores /TargetDir if there is an existing installation
Martin Gfeller added the comment: Windows Version is Windows 10, version 1803 (build 17134.1726). -- ___ Python tracker <https://bugs.python.org/issue42192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42192] Python Windows .exe Installer ignores /TargetDir if there is an existing installation
New submission from Martin Gfeller : I would like to install Python in a new location, completely separate and not affecting an existing installation of the same version. Despite I use /TargetDir=newdir, the installer goes into the "Modify Setup" dialog. If I chose "Modify", it shows my TargetDir read-only in the Customize installation location, but then modifies the original installation. If I run it with /passive or /quiet, it also modifies the existing installation instead of creating a new one at /TargetDir (doing nothing, since there is nothing to modify). If I choose repair at the prompt, it installs the Debug version (only!) into the TargetDir, with no library files except venv\scripts\nt (containing the debug .exe). It seems the installer checks whether there is an existing installation based on the registry (or by other means such peeking into the default installation directory). If there is an existing installation, the /TargetDir seems to be ignored, except for the peculiar repair installation of the debug build (which I never asked for). I believe this to be a bug in the installer; however if ignoring the /TargetDir once an existing installation is found (which I do not find desirable), it should be documented. The /TARGETDIR option of the old .msi installer didn't have this problem, it would reliably install into the target dir. -- components: Installation, Windows messages: 379859 nosy: Martin.Gfeller, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python Windows .exe Installer ignores /TargetDir if there is an existing installation type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue42192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13169] Regular expressions with 0 to 65536 repetitions raises OverflowError
Martin Gfeller added the comment: Sorry for passing on my confusion, and thanks for your help! There was indeed an old python.dll lying in one of the places Windows likes to put DLLs. Deleting it resolved the problem. Thanks again and sorry to use your valuable time. Best regards, Martin -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue13169> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13169] Regular expressions with 0 to 65536 repetitions raises OverflowError
Martin Gfeller added the comment: @Georg, the referenced Debian issue (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704084) already contains the stack. -- ___ Python tracker <http://bugs.python.org/issue13169> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13169] Regular expressions with 0 to 65536 repetitions raises OverflowError
Martin Gfeller added the comment: I see (under Windows) the same symptoms as reported for Debian under http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704084. Python refuses to start. 2.7.4.rc1 Windows 32-bit. -- nosy: +Martin.Gfeller ___ Python tracker <http://bugs.python.org/issue13169> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1449496] Python should use 3GB Address Space on Windows
Martin Gfeller Martin Gfeller added the comment: Martin, we're running with this for years and with many extensions modules, without an issue. What is 64-bit safe should be 32-bit safe, not only 31-bit safe. But you're right, this is not a proof, and we have switched to 64-bit ourselves. -- ___ Python tracker <http://bugs.python.org/issue1449496> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1497532] C API to retain GIL during Python Callback
Martin Gfeller Martin Gfeller added the comment: Lukas, I'm afraid to admit you're right :-;. Assuming that the Python code called under the "not release the GIL" regime would not do anything that could be potentially blocking is probably dangerous and could result in an unstable interpreter. So I withdraw my feature request and thank you for your efforts and interest. Best regards, Martin -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue1497532> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
