[issue41800] Python installation fails when run under system account if there is already an existing installation on the system already
Jurko Gospodnetić added the comment: Hi Steve, Thanks for a quick reply. > Yeah, this whole issue is basically because Burn (our installer tool) won't do > per-machine bundle registration even when it's only installing per-machine > packages. So the install block that it would normally throw up fails if you > use a different user account to install it the second time. Hmmm, I'm not sure this is exactly the case as this seems to happen even when we install Python using the `systemuser` user account initially and then rerun the installer using that same user account. Might I suggest adding this information to some 'known defects/limitations' Python documentation though? Together with more details on what it implies and how to deal with it? The current behaviour definitely does not seem like something one would expect as a user. > > (Python gets installed as a step in one of our installers) > > I'm intrigued by this - if Python is a dependency of your application, it's > better to repackage it yourself and install to your own directory. The > installer is basically there for end-users, but if you're not doing an > end-user kind of install there's really nothing gained. > > This whole scenario is fairly under-developed though. It comes up quite > infrequently, so we don't have any really convenient instructions on how to go > about it. Doesn't mean we can't help, but because we don't have a clear idea > of what you may be trying to achieve, we'd like to hear about it before > telling you how to approach this kind of thing. Our thinking was that if Python already wrapped up all of its installation logic to 'work correctly' (clean install, upgrade, uninstall, detecting files already in use, updating any relevant registry settings or globally installed files, etc.), we might as well use that, so we run the installer in silent mode and just process its exit code for stuff like errors, reboot required, etc. Logically the same process that Microsoft gives as the official way to install its Visual Studio run-time libraries (not saying that process is not filled with its own caveats :-D). We can of course take the installed Python distribution folder content and package that up in our installer directly, and that would avoid the official Python installer problems. We were hoping to avoid the problem of manually updating such a repackaging, e.g. Python deciding to add some more data to the Windows registry, some add-on installation copes with that and now requires that information to work correctly as well so now we have to debug/detect that also and tweak our installer to do the same, deal with any related version updating logic, etc. By embedding your installer, our 'Python version upgrade' process basically becomes: - pop the new Python installer into our 3rdparty library archive - update the used Python version configuration - run the installer build So if this bad installer behaviour is not going to get fixed, I guess we'll go and play with getting this working using Python's Windows embeddable zip file distribution instead. All suggestions welcome. :-) Thanks again! Best regards, Jurko Gospodnetić -- ___ Python tracker <https://bugs.python.org/issue41800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41800] Python installation fails when run under system account if there is already an existing installation on the system already
Change by Jurko Gospodnetić : -- versions: +Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41800] Python installation fails when run under system account if there is already an existing installation on the system already
Change by Jurko Gospodnetić : -- versions: -Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41800] Python installation fails when run under system account if there is already an existing installation on the system already
Jurko Gospodnetić added the comment: Some other potentially related issues: - https://bugs.python.org/issue25164 - https://bugs.python.org/issue32966 - https://bugs.python.org/issue37756 And some other related links: - https://docs.microsoft.com/en-us/troubleshoot/windows-server/application-management/msi-installation-error-1603 - https://superuser.com/questions/1238473/cant-uninstall-python-3-6-on-windows-10 - https://www.programmersought.com/article/41342430755/ - https://www.programmersought.com/article/41342430755/ And I'm attaching some of the Python installer logs I found from one of the debugging sessions researching this problem. It contains logs from a few installation runs and you can see there from the first log file in each batch and from the names of the other log files that the initial two failed while the last one was presumably done after an uninstall and worked. -- Added file: https://bugs.python.org/file49461/Python 3.8.3 (32-bit)_20200723053832.7z ___ Python tracker <https://bugs.python.org/issue41800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29033] Windows Python installer rolls back when run under SYSTEM account (SCCM)
Jurko Gospodnetić added the comment: This seems related to https://bugs.python.org/issue41800. -- nosy: +Jurko.Gospodnetić ___ Python tracker <https://bugs.python.org/issue29033> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41800] Python installation fails when run under system account if there is already an existing installation on the system already
Jurko Gospodnetić added the comment: This also seems related to https://bugs.python.org/issue29033. -- ___ Python tracker <https://bugs.python.org/issue41800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41800] Python installation fails when run under system account if there is already an existing installation on the system already
New submission from Jurko Gospodnetić : This issue seems to affect all Python 3 Windows installers. Reproduced on: - various Windows 10 systems - one Windows 8 system - one Windows 7 system - all tested Python 3+ installers up to and including 3.8.5 Scenario: 1. there is already an existing Python 3+ installation on a Windows system, installed for all users 2. you run a Python 3+ installer (any version, even the one matching the already installed Python version) under the `systemprofile` Windows user account, targeting all users and the same target folder that the currently existing installation is located in - example how to do this manually: - using the Microsoft/SysInternals `psexec` utility to open a command prompt running under the `systemprofile` Windows user account: `psexec -i -s cmd` - run the Python installer from that command-prompt, in our case it was the following command: `python-3.8.5.exe /passive TargetDir=C:\Python38 InstallAllUsers=1 PrependPath=1` 3. result will be any of the following at random: - failed installation with different Windows error codes, including totally opaque 0x80070643 `Fatal Error during installation` - successful installation - seemingly successful installation that does not really install all the Python components, e.g. the whole `Lib` folder may end up being empty - seemingly successful installation that then can not be uninstalled as the uninstaller reports that it can not find the existing installation on the system - this effect can often, but not always, be fixed by rerunning the installer and then running the uninstaller - you can run the uninstaller from the command-line using something like: `python-3.8.5.exe /uninstall /passive` Additional notes on produced results: - each installation seems to generate differently named log files in the `C:\Windows\Temp` folder, i.e. the `systemprofile` user account's `%TEMP%` folder - the log file names indicate whether each specific component is being installed for the current-user or all-user variants, and those seem to be chosen at random in our problematic scenario - it seems like the components whose log files are marked as being installed for the current user are not getting installed at all, or may possibly be getting installed to some other undisclosed location The same does not occur if any of the following is true: - if the installation is run from an regular end-user account - if there is no Python currently installed on the system A workaround we found in our case (Python gets installed as a step in one of our installers) is to basically do (uninstall, install) in a loop with some hand-crafted checking to see if the existing installation is ok (includes running some Python code + checking for some specific Python distribution files we've found to be missing in some scenarios). -- components: Installation messages: 377039 nosy: Jurko.Gospodnetić priority: normal severity: normal status: open title: Python installation fails when run under system account if there is already an existing installation on the system already versions: Python 3.5 ___ Python tracker <https://bugs.python.org/issue41800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38905] venv python reports wrong sys.executable in a subprocess on Windows
Jurko Gospodnetić added the comment: encountered what I believe is the same problem, so here are some more details I noticed, after checking what exactly that process name lookup does using ProcessMonitor: - when running my external process in a `venv` generated virtual environment, POpen() started subprocess executables are first looked up in the base Python executable's folder (the one used to create our virtual environment) as opposed to the one running the external Python process, if POpen() is called with `shell=False` - when doing the same and passing `shell=True` to the POpen() call, there is no such initial folder in the lookup - when doing the same on a `virtualenv` generated virtual environment, the file lookup is done in the correct folder first - the one containing the current Python executable and not in the base one -- nosy: +Jurko.Gospodnetić ___ Python tracker <https://bugs.python.org/issue38905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express
Jurko Gospodnetić added the comment: Here's another patch fixing the Visual Studio Express edition issue plus some minor related code-cleanup. See the Hg repo at: https://bitbucket.org/jurko/cpython branch: jurko/distutils_msvc_express_fix direct link: https://bitbucket.org/jurko/cpython/commits/branch/jurko/distutils_msvc_express_fix Basically - native 64-bit compiler is not available with Visual Studio Express edition, but its 32-bit to 64-bit cross-compiler is, so the fix just attempts to configure the cross-compiler if configuring the native compiler fails to set all the necessary environment variables. Tested to work correctly with Visual Studio Express edition installed, and no additional Platform SDK. I'm also directly attaching a bundle containing the same commits. I've split up the changes into cleanly separated commits so they should be real easy to review verify, and there should be no risk of breakage in use cases not explicitly attacked by the proposed changes. Hope this helps. Best regards, Jurko Gospodnetić -- hgrepos: +274 nosy: +Jurko.Gospodnetić Added file: http://bugs.python.org/file36822/CPython_msvc_express_fix_based_on_ec3077e23b7d1353af65a987d4caaef4343bdb41.hg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7511 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com: Added file: http://bugs.python.org/file36823/218ef482e1e4.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7511 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com: Removed file: http://bugs.python.org/file36823/218ef482e1e4.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7511 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22223] argparse not including '--' arguments in previous optional REMAINDER argument
New submission from Jurko Gospodnetić: If you have an optional nargs=argparse.REMAINDER argument defined then, if specified, its value should contain all the remaining command-line content. However, it seems that value does not include later '--' arguments. For example, the following works as expected: import argparse parser = argparse.ArgumentParser(prog=PROG) parser.add_argument(--args, nargs=argparse.REMAINDER) args = parser.parse_args(--args cmd --arg1 XX ZZ.split()) assert args.args == [cmd, --arg1, XX, ZZ] But the following fails with 'PROG: error: unrecognized arguments: -- ZZ': import argparse parser = argparse.ArgumentParser(prog=PROG) parser.add_argument(--args, nargs=argparse.REMAINDER) args = parser.parse_args(--args cmd --arg1 XX -- ZZ.split()) assert args.args == [cmd, --arg1, XX, --, ZZ] Note that the same code works as expected when using a positional nargs=argparse.REMAINDER arguments: import argparse parser = argparse.ArgumentParser(prog=PROG) parser.add_argument(args, nargs=argparse.REMAINDER) args = parser.parse_args(args cmd --arg1 XX ZZ.split()) assert args.args == [cmd, --arg1, XX, ZZ] args = parser.parse_args(args cmd --arg1 XX -- ZZ.split()) assert args.args == [cmd, --arg1, XX, --, ZZ] But that, of course, does not allow us to have the args value start with something like --blah that looks like an optional argument. Hope this helps. Best regards, Jurko Gospodnetić -- components: Library (Lib) messages: 225484 nosy: Jurko.Gospodnetić priority: normal severity: normal status: open title: argparse not including '--' arguments in previous optional REMAINDER argument type: behavior versions: Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22223] argparse not including '--' arguments in previous optional REMAINDER argument
Jurko Gospodnetić added the comment: Might be related to the following issues: http://bugs.python.org/issue9571 http://bugs.python.org/issue13922 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21415] Python __new__ method doc typo (it's a class and not a static method)
Jurko Gospodnetić added the comment: Thanks for the detailed response! :-( I should have tested more before reporting the issue. Sorry for the noise. :-( I saw the 'cls' argument and assumed it was a class method. Having to explicitly specify cls did not seem to be in contradiction with this since I assumed __new__ is generally invoked on the class directly. I still do not see why it had to be a static method and has not been implemented as a class method, but I guess I'll better ask that kind of a question on the python user's newsgroup. :-) Just in case it can help someone else, here's some sample code what convinced me __new__ was indeed implemented as a static method: class X: pass X.__new__() # TypeError: object.__new__(): not enough arguments X.__new__(X) # creates a new X instance x = X() x.__new__() # TypeError: object.__new__(): not enough arguments x.__new__(X) # creates a new X instance If __new__ had been a class method then calling 'x.__new__()' would have worked as well. Thanks again for the replies! Best regards, Jurko Gospodnetić -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21415 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21415] Python __new__ method doc typo (it's a class and not a static method)
New submission from Jurko Gospodnetić: Doc/reference/datamodel.rst documentation states that the __new__ method is a static method (in Python, not in C!) when it is in fact a class method. A patch has been prepared in the https://bitbucket.org/jurko/cpython repository. branch: datamodel_doc_typo_fix commit: 81c5ba188805e42292c3eb9cffa56fbd5b7c6aee But it'll probably be easier for you to just change that single word directly. :-D Hope this helps. Best regards, Jurko Gospodnetić -- assignee: docs@python components: Documentation hgrepos: 245 messages: 217748 nosy: Jurko.Gospodnetić, docs@python priority: normal severity: normal status: open title: Python __new__ method doc typo (it's a class and not a static method) type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21415 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21415] Python __new__ method doc typo (it's a class and not a static method)
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file35130/81c5ba188805.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21415 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21161] list comprehensions don't see local variables in pdb in python3
Jurko Gospodnetić added the comment: Thanks for looking into this Xavier. Could someone reopen this issue so it can gets looked at again? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21161] list comprehensions don't see local variables in pdb in python3
Jurko Gospodnetić added the comment: Just ran into this problem and it's so uncomfortable researching dynamic structures at run-time using PDB without this. :-( As a workaround, you can use a trick similar to this one to 'import' your locals into the list comprehension body: [l['r'](x) for l in (locals(),) for x in l['some_local']] assuming 'r' 'some_local' are two local variables in your surrounding scope. Ugly, but at least it can be made/forced to work if needed... Best regards, Jurko Gospodnetić -- nosy: +Jurko.Gospodnetić versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21160] incorrect comments in nturl2path.py
New submission from Jurko Gospodnetić: nturl2path.py module contains comments implying that it converts local paths to URLs with ':' characters replaced with '|'. This has not been true since Python 2.6. Commit at: http://bitbucket.org/jurko/cpython/commits/8fe56380b09e238f104ba4a4d7a67df73182bc21 updates those comments - prepared against the CPython development repo. -- components: Library (Lib), Windows hgrepos: 230 messages: 215592 nosy: Jurko.Gospodnetić priority: normal severity: normal status: open title: incorrect comments in nturl2path.py versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21160 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21034] Python docs reference the Distribute package which has been deprecated in favor of Setuptools
Jurko Gospodnetić added the comment: Or, if you do not want to get into the specifics of how to manually install setuptools/pip, it would probably be better to just refer the user to the 'ensurepip' module for the initial installation and tell him to upgrade whatever is needed from there without going in to any further details here. 'ensurepip' module itself is documented elsewhere (https://docs.python.org/3.4/library/ensurepip.html), and that documentation should perhaps be updated to include enough information (or references to external documentation containing that information) for the user to be able to perform the upgrades. Best regards, Jurko Gospodnetić -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21034 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19983] When interrupted during startup, Python should not call abort() but exit()
Jurko Gospodnetić added the comment: Anyone have an eye on this item? What are the chances of the suggested patch being applied for Python 3.5? Or the issue resolved in some other way? Anything I can do to help? P.S. I'm not sure exactly how the regular development protocol goes around here so, just for the record, please know that no offense in intended with this ping. :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19983] When interrupted during startup, Python should not call abort() but exit()
Jurko Gospodnetić added the comment: err... by Python 3.5 I meant Python 3.4.1 as well :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21034] Python docs reference the Distribute package which has been deprecated in favor of Setuptools
New submission from Jurko Gospodnetić: In the Python documentation note: http://docs.python.org/3.4/library/venv.html#venv-def the paragraph: Common installation tools such as Distribute and pip work as expected with venvs - i.e. when a venv is active, they install Python packages into the venv without needing to be told to do so explicitly. Of course, you need to install them into the venv first: this could be done by running distribute_setup.py with the venv activated, followed by running easy_install pip. Alternatively, you could download the source tarballs and run python setup.py install after unpacking, with the venv activated. refers to the Distribute package and its specifics (how it should be installed) but that package has been deprecated in favor of the setuptools package. I suggest to change it to something like: Common installation tools such as setuptools and pip work as expected with venvs - i.e. when a venv is active, they install Python packages into the venv without needing to be told to do so explicitly. Of course, you need to install them into the venv first: this could be done by running setuptools project's ez_setup.py with the venv activated, followed by running easy_install pip. Alternatively, you could download the source tarballs and run python setup.py install after unpacking, with the venv activated. I'm attaching a patch based on the current tip in CPython's development repository. Hope this helps. Best regards, Jurko Gospodnetić -- assignee: docs@python components: Documentation files: fix_Distribute_reference_in_venv_docs.patch keywords: patch messages: 214554 nosy: Jurko.Gospodnetić, docs@python priority: normal severity: normal status: open title: Python docs reference the Distribute package which has been deprecated in favor of Setuptools versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34582/fix_Distribute_reference_in_venv_docs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21034 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: Thanks Brett! :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20983] Python 3.4 'repair' Windows installation does not install pip setuptools packages
New submission from Jurko Gospodnetić: On Windows, when you repair your Python 3.4 installation, it will not reinstall pip setuptools. Here by 'repair' I mean a 'Windows Installer' based repair installation. Reproduced using: * Windows 7 SP1 x64. * Python 3.4.0 (32-bit). To reproduce do the following: * Install Python. * For example to the target installation folder: 'C:\Program Files (x32)\Python\Python340'. * This will automatically install pip setuptools Python packages. * Delete or rename your target installation folder. * Rerun your Python installation and choose to repair the current installation. * This will restore the original target installation folder and all the basic installation files under that folder, but it will not reinstall pip setuptols Python packages. -- components: Installation, Windows messages: 214113 nosy: Jurko.Gospodnetić priority: normal severity: normal status: open title: Python 3.4 'repair' Windows installation does not install pip setuptools packages versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20984] 'Add/Remove Programs' dialog missing entries for 32-bit CPython 'current user only' installations on 64-bit Windows
New submission from Jurko Gospodnetić: When you install 32-bit CPython 'for the current user only' on 64-bit Windows, the installation does not show up in the Windows 'Add/Remove Programs' dialog (a.k.a. 'Programs and Features' dialog on Windows 7). It does not show up there even for the current user. I tested this CPython installation behaviour with the following CPython versions: * 2.3.4 - works correctly * 2.5.4 - works correctly * 2.6.0 - works correctly * 2.6.2 - works correctly * 2.6.3 - does not work correctly * 2.6.4 - does not work correctly * 2.6.6 - does not work correctly * 2.7.6 - does not work correctly * 3.3.3 - does not work correctly * 3.3.5 - does not work correctly * 3.4.0 - does not work correctly All this has been tested using one Windows 7 SP1 (x64) machine and using only CPython 3.4.0 installation on another. Several related observations, indicating that this could be some sort of a Windows Installer misconfiguration issue possibly solvable in the CPython installer: * The same does not occur when you install a 64-bit CPython version - its entry is correctly displayed in the 'Add/Remove Programs' dialog. * 32-bit CPython installer still correctly detects that a specific 32-bit version has already been installed, even if that previous installation is not listed in the 'Add/Remove Programs' dialog. * When you ask Windows using its WMI interface to list all the products installed on it (e.g. by running 'wmic product list' on the command-line), all the installed CPython versions are correctly displayed, even the 32-bit versions not displayed in the 'Add/Remove Programs' dialog. I compared MSI packaging related CPython source code (Tools/msi folder) in 2.6.2 2.6.3 releases but failed to see anything suspicious there. It could be that the observed beaviour change between those two versions is a result of the final release packager changing his used Windows Installer version, but I have not rebuilt CPython, and its MSI installer to test this theory out. -- components: Installation, Windows messages: 214116 nosy: Jurko.Gospodnetić priority: normal severity: normal status: open title: 'Add/Remove Programs' dialog missing entries for 32-bit CPython 'current user only' installations on 64-bit Windows versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20984 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20984] 'Add/Remove Programs' dialog missing entries for 32-bit CPython 'current user only' installations on 64-bit Windows
Jurko Gospodnetić added the comment:
Here is a possible 'workaround' for the issue, but it
will take someone more knowledgeable about the Windows
Installer infrastructure to say if the workaround can be
applied directly as a clean solution or if it could have
hidden consequences.
Each 32-bit installation on 64-bit Windows has its own
'Uninstall' registry key under:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
named after its Windows Installer assigned GUID, e.g.:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{A37F2D73-72D1-364D-BA5D-CEA430BCC040}
In that key there is a value named 'WindowsInstaller'
which for CPython installations has the value '1' (of
type REG_DWORD).
If you change that value to '0' (again, of type REG_DWORD),
the installation's 'Add/Remove Programs' dialog entry will
get displayed correctly, and user will be able to run the
installation (reinstall/change/uninstall) from there.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20984
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20984] 'Add/Remove Programs' dialog missing entries for 32-bit CPython 'current user only' installations on 64-bit Windows
Jurko Gospodnetić added the comment: This issue can confuse a regular user in the following scenario: 1. User uses 'for current user only' Python installations. 2. User expects to be able to see all installed software listed in the 'Add/Remove Programs' dialog and does not know that the listing presented there might be incomplete, how to use WMI to get an alternative listing or have any other indication that he should look for some external software providing this listing. 3. User has 32-bit 64-bit CPython 3.4.0rc3 installed on his machine. 4. User uninstalls the 64-bit CPython 3.4.0rc3 version and installs a new 64-bit CPython 3.4.0 release. No problems there. 5. User now wants to remove the old 32-bit CPython 3.4.0rc3 installation from his computer. 6. User checks the 'Add/Remove Programs' dialog and does not see the installation listed there. 7. User checks the 32-bit CPython 3.4 related Start menu folder for an uninstall link, but all the links there are related only to the 64-bit CPython 3.4.0 installation. 8. User checks the 32-bit CPython 3.4.0rc3 installation target folder (where its python.exe and other files are located) but finds no uninstaller there either. 9. Since there is no uninstaller to be found for this CPython installation, user assumes it is ok to just delete its folder and does so. 10. User attempts to install a new 32-bit CPython 3.4.0 installation and that breaks dues to not being able to uninstall a detected previous installation. If user thinks of it - he can now work around this by finding an old installation package for the previously installed 32-bit CPython version, running that, choosing to first repair the current installation and then run the installation again to remove the current installation. Or clean up the previous installation's Windows Installer related registry entries by hand (painful error prone). Or be unable to ever install a new version. :-) And, speaking from personal experience :-D, if he does apply the workaround he can 'feel dumb' about not locating and trying out the original installation before removing the original installed data and cuss fuss about nothing around him instructing him to look into that possibility. :-D If nothing else, this could be 'patched up' by having CPython's Windows installer that fails to uninstall a previous installation, suggest manually repairing the previous installation by running its installation package directly before attempting to rerun this installation. It could also reporting the original installation's install package location on disk, as read from the registry (Windows Installer makes a copy under some random generated name which user is unlikely to find by simple trial error). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20984 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20984] 'Add/Remove Programs' dialog missing entries for 32-bit CPython 'current user only' installations on 64-bit Windows
Jurko Gospodnetić added the comment:
Here are some more Windows Installer notes taken down
when originally researching this issue on my end.
Hopefully they can be of some use to anyone researching
the issue further:
- each installation gets a GUID key identifying it
- the installation GUID key can be converted into a
corresponding product key using the following
algorithm:
def guid_to_product_key(guid):
guid = string in format {----}
parts = guid.lstrip({).rstrip(}).split(-)
key = []
# Reverse the first 3 parts.
for p in range(3):
key.extend(reversed(parts[p]))
# Swap character pairs in remaining parts.
for part in parts[3:]:
for i in range(len(part) // 2):
key.append(part[2 * i + 1])
key.append(part[2 * i])
return .join(key).upper()
- some Windows Installer registry keys related to a
specific installation:
Example installation GUID key:
{a37f2d73-72d1-364d-ba5d-cea430bcc040}
Example product key:
37D2F73A1D27D463ABD5EC4A03CB0C04
Installed for example user with SID:
S-1-5-21-2100645858-3408510361-1554613642-1000
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\{a37f2d73-72d1-364d-ba5d-cea430bcc040}
HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\37D2F73A1D27D463ABD5EC4A03CB0C04
HKEY_CURRENT_USER\Software\Microsoft\Installer\Features\37D2F73A1D27D463ABD5EC4A03CB0C04
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-21-2100645858-3408510361-1554613642-1000
\Products\37D2F73A1D27D463ABD5EC4A03CB0C04
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{A37F2D73-72D1-364D-BA5D-CEA430BCC040}
Product key listed under several different subkeys under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-21-2100645858-3408510361-1554613642-1000\Components
Product key listed under:
HKEY_CURRENT_USER\Software\Microsoft\Installer\UpgradeCodes\84ED6E56853AD434AAF4A47FD24B17F8
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UpgradeCodes\84ED6E56853AD434AAF4A47FD24B17F8
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20984
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: Step 2: Jurko can you see if the uploaded patch fixes things for you? Yup. That's exactly how we were working around the issue before reporting it here. :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: As mentioned by Anthony Tuininga at: https://bitbucket.org/anthony_tuininga/cx_freeze/issue/61/python-340-nameerror-name-__file__-is-not#comment-9077661 The value of __file__ in the problematic importlib/__init__.py module with Python 3.3. is 'frozen' while with Python 3.4 it is not defined. And this 'frozen' string seems to be something coming from Python and not cx_Freeze (I see it in 'Python/import.c' in both Python 3.3.5 3.4). Hope this helps. Best regards, Jurko Gospodnetić -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: Ask per Nick's instructions I tweaked cx_Freeze to import a dummy package as frozen. The dummy package has the following structure: gugu/ __init__.py and its __init__.py file contains only the 8 bytes '__file__' (does not include the quotes). Then running a frozen executable based on a script with the following content: import gugu results in a NameError due to the name '__file__' not being recognized. You can see more detailed information at: https://bitbucket.org/anthony_tuininga/cx_freeze/issue/61/python-340-nameerror-name-__file__-is-not#comment-9084842 Hope this helps. Best regards, Jurko Gospodnetić -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: That 'what's new' item seems relevant, except that the issue here is related to the __file__ attribute instead of __path__. Could it be that the same fix actually updated how the __file__ attribute is defined as well? The bug seems to be caused by importlib\__init__.py expecting its __file__ attribute to be defined, thus not allowing it to be frozen at all. :-( Based on my rather slim understanding of how module 'freezing' works I guess executables wanting to freeze the importlib\__init__.py module can work around the problem by adding code to the front of that module to hardcode its __file__ attribute value, before freezing it. However I'd be happier with Python not requiring that the __file__attribute be defined internally at all. Imposing a workaround such as this on anyone wanting to freeze the importlib package seems rather nasty. Best regards, Jurko Gospodnetić -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: This could possibly also have been caused by a resolution to issue 18088 (http://bugs.python.org/issue18088). See commit e873f2e67353 (http://hg.python.org/cpython/rev/e873f2e67353). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: +1 for the clean solution :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20784] 'collections.abc' is no longer defined when collections is imported
Jurko Gospodnetić added the comment: Item possibly related to this. When packaging a simple HelloWorld-like application like this: print(Hello world) import configparser using cx_Freeze and Python 3.4, you get the following error on packaged application startup: Traceback (most recent call last): File C:\Program Files\Python\Python34rc3\lib\site-packages\cx_freeze-4.3.2-py3.4-win-amd64.egg\cx_Freeze\initscripts\Console3.py, line 27, in module exec(code, m.__dict__) File hello_world.py, line 4, in module File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2214, in _find_and_load return _find_and_load_unlocked(name, import_) File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2203, in _find_and_load_unlocked module = _SpecMethods(spec)._load_unlocked() File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 1191, in _load_unlocked return self._load_backward_compatible() File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 1161, in _load_backward_compatible spec.loader.load_module(spec.name) File C:\Program Files\Python\Python34rc3\lib\configparser.py, line 121, in module from collections.abc import MutableMapping File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2214, in _find_and_load return _find_and_load_unlocked(name, import_) File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2201, in _find_and_load_unlocked raise ImportError(_ERR_MSG.format(name), name=name) ImportError: No module named 'collections.abc' As I see it, the config parser module is attempting to import 'collections.abc'. The same does not occur with Python 3.3.5 or 3.3.3. Not sure if this is due to something cx_Freeze does so it failed to collect some module in the created installation package, or if it's something to look into in Python itself. Just looked similar to this so I bring it up as additional info for anyone looking deeper into this issue. Hope this helps. Best regards, Jurko Gospodnetić -- nosy: +Jurko.Gospodnetić ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20784 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20784] 'collections.abc' is no longer defined when collections is imported
Jurko Gospodnetić added the comment: I cannot reproduce your issue Meaning you do not have the environment set up for this or that you tried it and it worked for you? If it 'worked for you', I can send you more detailed environment information when get back to my office in an hour or so. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20784 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: Here's a recipe I can use to reproduce the problem on my PC. Environment: * Windows 7 SP1 x64 * Python 3.4.0rc3 * cx_Freeze checkout from its current HEAD * repository: https://bitbucket.org/anthony_tuininga/cx_freeze * HEAD commit: 52b63b3296843cd612cfbe047a9f6529df4c0444 * I'm attaching a compressed checkout. * TortoiseHg 2.11 - just in case you're having problems using the cx_Freeze Hg sandbox I attached to this comment and want to know if it is Hg version related. * Microsoft Visual Studio 2010 C/C++ compiler. * Exact cl.exe version information: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 -- 1. prepare to build cx_Freeze -- To build the given cx_Freeze project using Python 3.4 the following tweak must first be done in Python's Lib\distutils\msvc9compiler.py module: Around line 649 replace the line: if mfinfo is not None: with: if mfinfo is not None and target_desc != executable: This is an unrelated issue that still needs to be researched. -- 2. build install cx_Freeze -- Standard Python package installation - go to your cx_Freeze sandbox project folder and run py34 setup.py install. This should result in cx_Freeze-4.3.2-py3.4-win-amd64.egg folder being added under your Python 3.4 installation's site-packages folder. -- 3. prepare a test project -- Create a new folder and add the following files to it: hello_world.py: print(Hello world) import asyncio import sys print(sys.version_info) setup.py: from cx_Freeze import setup, Executable setup(name=HelloWorld, version=0.1, description=HelloWorld, executables=[Executable(hello_world.py, base=Console)]) Note that only the 'import asyncio' line is necessary to reproduce the issue. The rest is just useful output for the user/tester. -- 4. prepare a 'frozen' test project executable -- Go to the test project folder and run the following command: py34 setup.py build_exe This should create a new executable under: build\exe.win-amd64-3.4\hello_world.exe -- 5. run the prepared executable -- You should get output looking something like: Hello world Traceback (most recent call last): File C:\Program Files\Python\Python34rc3\lib\site-packages\cx_freeze-4.3.2-py3.4-win-amd64.egg\cx_Freeze\initscripts\Cons exec(code, m.__dict__) File hello_world.py, line 8, in module import asyncio File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2214, in _find_and_load return _find_and_load_unlocked(name, import_) File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2203, in _find_and_load_unlocked module = _SpecMethods(spec)._load_unlocked() File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 1191, in _load_unlocked return self._load_backward_compatible() File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 1161, in _load_backward_compatible spec.loader.load_module(spec.name) File C:\Program Files\Python\Python34rc3\lib\asyncio\__init__.py, line 23, in module from .locks import * File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2214, in _find_and_load return _find_and_load_unlocked(name, import_) File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2203, in _find_and_load_unlocked module = _SpecMethods(spec)._load_unlocked() File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 1191, in _load_unlocked return self._load_backward_compatible() File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 1161, in _load_backward_compatible spec.loader.load_module(spec.name) File C:\Program Files\Python\Python34rc3\lib\asyncio\locks.py, line 9, in module from . import tasks File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2261, in _handle_fromlist _call_with_frames_removed(import_, from_name) File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 321, in _call_with_frames_removed return f(*args, **kwds) File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2214, in _find_and_load return _find_and_load_unlocked(name, import_) File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2203, in _find_and_load_unlocked module = _SpecMethods(spec)._load_unlocked() File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 1191, in _load_unlocked return self._load_backward_compatible() File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 1161, in _load_backward_compatible spec.loader.load_module(spec.name) File C:\Program Files\Python\Python34rc3\lib\asyncio\tasks.py, line 12, in module import inspect File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2214, in _find_and_load
[issue20883] Windows 'for current user' installation - 32/64-bit registrations overwrite each other
New submission from Jurko Gospodnetić: When running the Python Windows installer 'for all users', the 32-bit installation and the 64-bit installation each gets a separate registration in the Windows registry. E.g. under: HKEY_LOCAL_MACHINE\Software\Python\PythonCore\3.4 and: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\3.4 However, when running the installer 'for the current user only', the 32-bit and the 64-bit installation both use the same Windows registry key: HKEY_CURRENT_USER\Software\Python\PythonCore\3.4 Note that a 64-bit installation does not automatically uninstall a previous 32-bit installation in either case, or vice versa. As I understand it, whichever installation you use, you should be able to run a specific Python interpreter using the py.exe runner, as in: py.exe -3.4 py.exe -3.4-32 As it stands now - both of those run the same interpreter when they have been installed 'for the current user only', although when running 'py.exe -3.4-32' the runner will make an extra check and reject running the Python executable if the 64-bit version was installed last. So: 1. If you install the 64-bit version first and then the 32-bit version, both 'py.exe -3.4' 'py.exe -3.4-32' run the 32-bit executable. 2. If you install the 32-bit version first and then the 64-bit version, 'py.exe -3.4' runs the 64-bit version, and 'py.exe -3.4-32' exits with an error. -- components: Installation, Windows messages: 213045 nosy: Jurko.Gospodnetić priority: normal severity: normal status: open title: Windows 'for current user' installation - 32/64-bit registrations overwrite each other versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20883 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20883] Windows 'for current user' installation - 32/64-bit registrations overwrite each other
Jurko Gospodnetić added the comment: A possible solution would be to update installers and runners to use HKEY_CURRENT_USER\Software\Wow6432Node registry entries for 32-bit 'for current user only' installations on a 64-bit Windows OS. To preserve backward compatibility, runners could fall back to reading the 64-bit HKEY_CURRENT_USER\Software registry entries if their 32-bit counterparts can not be found directly. This way: - installations on 32-bit Windows are unaffected - new installations work with new runners correctly - old installations work with new runners as before - old installations work with old runners as before - new 64-bit installations work with old runners as before - new 32-bit installations do not work with old runners -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20883 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
New submission from Jurko Gospodnetić:
Python 3.4 introduced a change to Lib/importlib/__init__.py that added the
following code to it:
else:
# importlib._bootstrap is the built-in import, ensure we don't create
# a second copy of the module.
_bootstrap.__name__ = 'importlib._bootstrap'
_bootstrap.__package__ = 'importlib'
_bootstrap.__file__ = __file__.replace('__init__.py', '_bootstrap.py')
sys.modules['importlib._bootstrap'] = _bootstrap
When attempting to use cxFreeze on a project, using Python 3.4. we ran into a
problem with '__file__' identifier not being defined.
I believe this is a bug since the code expects the module loaded from
importlib/__init__.py to always have a __file__ identifier set.
Python 3.4.0rc3 documentation explicitly states:
__file__ is optional. If set, this attribute’s value must be a
string. The import system may opt to leave __file__ unset if it
has no semantic meaning (e.g. a module loaded from a database).
and:
Ultimately, the loader is what makes use of __file__ and/or
__cached__.
A possible fix would be to skip setting the _bootstrap.__file__ attribute if
the current module does not have a __file__ attribute set.
I hope this can be resolved before the 3.4 final release or it will not be
possible to use cxFreeze with Python 3.4 without additional workarounds in
cxFreeze.
Best regards,
Jurko Gospodnetić
--
components: Interpreter Core, Library (Lib)
messages: 213047
nosy: Jurko.Gospodnetić
priority: normal
severity: normal
status: open
title: importlib/__init__.py can not be loaded without __file__ - breaks
cxFreeze
type: behavior
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20884
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: David: Nope, the issue does not exist with 3.3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20883] Windows 'for current user' installation - 32/64-bit registrations overwrite each other
Jurko Gospodnetić added the comment: I'm against removing local user installation support because that is the only way Python can be installed without write access to shared system locations like the Windows system folder or the HKEY_LOCAL_MACHINE registry hive. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20883 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20883] Windows 'for current user' installation - 32/64-bit registrations overwrite each other
Jurko Gospodnetić added the comment: And as for simultaneous 64/32-bit Python installations on a single 64-bit machine - as Paul said, whichever way Microsoft implemented its automatic registry key redirection, it is up to Python to decide how its installer should behave. So the question is - should it be possible to run 32-bit 64-bit Python installations on the same machine using the standard py.exe wrapper when those installations are done for the current user only? I know I found that useful in a scenario (done using installations 'for all users' though) where I had some scripts using 64-bit Python and needed to run several scripts automating a 32-bit Python extension module. I believe the problem was in the pstools module that at the time was not available as a 64-bit build (don't know if that situation has been resolved since). Personally, I just noticed the undocumented inconsistency and decided to report it. I don't really care all that much about whether it is resolved cleanly, as in my development setup I have other problems preventing me from using the py.exe wrapper all together - I need multiple parallel patch releases in the same system and the best way I found to achieve that is to: - do a 'local user installation' - version A, - rename the target folder for version A - do a 'local user installation' - version B, - ... and have my own version specific startup scripts like py243.cmd, py244.cmd, py276_x86.cmd, py276.cmd, py340.cmd, ... I really don't like it that different Python X.Y patch releases overwrite each other's installation registrations or uninstall each other automatically. :-( Or that you can not specify more detailed Python interpreter version information like 2.4.3 to the py.exe wrapper. :-( -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20883 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20883] Windows 'for current user' installation - 32/64-bit registrations overwrite each other
Jurko Gospodnetić added the comment: Nor was Martin suggesting it as far as I can tell I'm sorry if I came across too strongly. I can assure you I meant no disrespect nor have I at any point felt affronted by anything anyone else said in this thread/issue. :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20883 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: I'll try to set up and post a reproducible use case tomorrow. Then you can decide. It could turn out that the use case we ran into has an easy workaround. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20759] unittest.mock documentation typo
New submission from Jurko Gospodnetić: Python unittest.mock documentation has typo: indvidually instead of individually Can be seen in the documentation source file at: http://hg.python.org/releasing/3.4/file/c1f9fbefb237/Doc/library/unittest.mock-examples.rst#l429 -- assignee: docs@python components: Documentation messages: 212079 nosy: Jurko.Gospodnetić, docs@python priority: normal severity: normal status: open title: unittest.mock documentation typo versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20759 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20759] unittest.mock documentation typos
Jurko Gospodnetić added the comment: Another related documentation 'bug' - the following wording: Mock doesn’t create these but instead of raises an AttributeError. should be changed to something like: Mock doesn’t create these on demand and raises an AttributeError instead. Can be seen in the documentation source file at: http://hg.python.org/releasing/3.4/file/c1f9fbefb237/Doc/library/unittest.mock.rst#l960 -- title: unittest.mock documentation typo - unittest.mock documentation typos ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20759 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20759] unittest.mock documentation typos
Jurko Gospodnetić added the comment: And another one: 'setttings' should be spelled 'settings' in: http://hg.python.org/releasing/3.4/file/c1f9fbefb237/Doc/library/unittest.mock.rst#l1512 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20759 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] It is impossible to catch sigint on startup in python code
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com: -- components: +email -Interpreter Core nosy: +Jurko.Gospodnetić, barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14228 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19983] Ctrl-C causes startup crashes on Windows
New submission from Jurko Gospodnetić: If you press Ctrl-C during Python startup on Windows you may get interpreter crashes with different Python tracebacks displayed on the standard system error output stream. Reproduced using: - Windows 7 SP1 x64 - Python 3.3.3 (64-bit) as downloaded from 'http://www.python.org/download/releases/3.3.3' (but seen with different earlier Python versions as well). - either a non-trivial Python script, one containing only a '#! python3' shabang line, or a completely empty one - default site.py To reproduce simply run the Python interpreter with a prepared Python script as input and press Ctrl-C immediately afterwards. Possible results: * Script finishes before your Ctrl-C kicks in. * You get a clean KeyboardInterrupt traceback and the script exits. * You get a KeyboardInterrupt traceback and the interpreter process crashes. I'm attaching more detailed information on specific crash instances. For some more information background see the devel mailing list thread started at: 'https://mail.python.org/pipermail/python-dev/2013-December/130750.html'. -- components: Interpreter Core, Windows files: crash-info-10.txt messages: 206212 nosy: Jurko.Gospodnetić priority: normal severity: normal status: open title: Ctrl-C causes startup crashes on Windows type: crash versions: Python 3.3 Added file: http://bugs.python.org/file33137/crash-info-10.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19983] Ctrl-C causes startup crashes on Windows
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com: Added file: http://bugs.python.org/file33138/crash-info-1-9 - Python tracebacks only.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19983] Ctrl-C causes startup crashes on Windows
Jurko Gospodnetić added the comment: I can reproduce this most easily if I run a command like: clean.cmd run.py where clean.cmd is any short batch script and run.py is a file containing only the '#! python3' shabang line. The batch script in front is not necessary, and I've originally been reproducing the issue without it, but the problem seems much easier to reproduce with it, most likely because is slightly delays the Python startup and thus makes it easier for the Ctrl-C signal to kick in early enough during Python startup. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19983] Ctrl-C causes startup crashes on Windows
Jurko Gospodnetić added the comment: I reproduced the issue about 10 more times to see if I'd get some more useful C tracebacks in Visual Studio, but they seems to be the pretty much the same every time (as seen in the attached http://bugs.python.org/file33137/crash-info-10.txt file). I'm attaching another one, just for the record. The only difference I see between crash #10 and this one is that second thread has a bit different name, but that is most likely just some internal Windows API worker thread and not something explicitly started by Python or relevant to this report. -- Added file: http://bugs.python.org/file33139/crash-info-11.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19983] Ctrl-C causes startup crashes on Windows
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com: Removed file: http://bugs.python.org/file33139/crash-info-11.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19983] Ctrl-C causes startup crashes on Windows
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com: Added file: http://bugs.python.org/file33140/crash-info-11.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] It is impossible to catch sigint on startup in python code
Jurko Gospodnetić added the comment: This issue is related to issue #19983 on Windows. Also, I do not think the suggested -z option implementation should be accepted 'as is'. On Unix it would make Ctrl-C silently terminate the process if it occurs before default Python signal handling is enabled. I do not know what effect this would have on Windows - possibly the signal would simply be ignored lost. It would also still leave a slight window between when Python sets up its default SIGINT handling and when user code has a chance to set up its own. My first instinct is to not do that and instead add an option to block SIGINT handling and allow user code to enable its own or default Python handling as it wishes and then unblock SIGINT handling. Note that by 'blocking' a signal I do not mean losing/ignoring it but delaying its handling until signal handling is unblocked. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14228 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
Jurko Gospodnetić jurko.gospodne...@gmail.com added the comment: Also this class, because it defines __del__ too simply, will display a user-unfriendly error message when cleaning up a TemporaryDirectory object whose constructor raised an exception when attempting to create its temporary folder. For example try to create a TemporaryDirectory with prefix= on Windows. That should fail as folders there can not contain '' characters and later on in the program you should get an error message something like this one: Exception AttributeError: 'TemporaryDirectory' object has no attribute '_closed' in bound method TemporaryDirectory.cleanup of tempfile.TemporaryDirectory object at 0x00CE1E10 ignored Hope this helps. [Sorry, did not know whether to add this as a separate issue as it seemed kind of related to this one.] -- nosy: +Jurko.Gospodnetić ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
Jurko Gospodnetić jurko.gospodne...@gmail.com added the comment: Clicked send too soon on the previous comment. :-( The simplest way I see you can fix the __del__ issue is to patch TemporaryDirectory.__init__() as follows: def __init__(self, suffix=, prefix=template, dir=None): self._closed = True self.name = mkdtemp(suffix, prefix, dir) self._closed = False This is based on the tempfile.py from the 3.2 beta 1 release on Windows. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
