[issue31077] Windows Installer Version
New submission from Damon Atkins: The Windows installer for example titles the software as Display Name:Python 3.5.3 (64-bit) Display Version: 3.5.3150.0 The default install folder is C:\Program Files\Python35 There is no consistency It looks like the 3150 been shorten to 3 If you look at Python 2.7.2 it has a display version of 2.7.13150 Suggest Display Name:Python 3.5 (64-bit) Display Version: 3.5.3150.0 C:\Program Files\Python3.5 or C:\Program Files\Python3.5.3150 OR Display Name:Python 3.5.3150 (64-bit) Display Version: 3.5.3150.0 C:\Program Files\Python3.5.3150 OR Display Name:Python 3.5.3 (64-bit) Display Version: 3.5.3.3150 C:\Program Files\Python3.5.3 Alse seems that Python 3 installer is placing one entery in the 'Users' registry for uninstall and the rest of the entries in 'System' registry for uninstall I suggest if the files are installed in C:\Program Files then their should be no 'User' registry entries. -- components: Windows messages: 299475 nosy: Damon Atkins, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows Installer Version type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue31077> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31103] Windows Installer Product Version 3.6.2150.0 Offset By 0.0.150.0
Damon Atkins added the comment: Hi Guys, The reason I raise the original is for all those configuration management tools which need the version number. In the uninstall registry is very much an inconsistent. *Anything with a Display Name in the registry (name in the GUI) will be listed. * Their are two places for version information. ** 1 "large int (DWORD) version number" called "version" store across several integers in the registry, which supports <0-255>.<0-255>.<0-65535> this is not visible in the GUI. ** display version, which is a string, and can be set to anything, this is visible in the GUI. "display version" is set most of the time. "large int version number" not always "large int (DWORD) version number" I have actual see software which as created this as a text string, which is just wrong. e.g. Google Chrome, however Google Update Helper does the right thing. People see the "display version" so this needs to match the version of python. I would expect most configuration management tools to use "display version" before "large int (DWORD) version number" The following is based on installing python 3.6.2 (3.6.2150 not sure what this means) display name should be "Python 3.6 (64-bit)" if you wish to encourage only single version of 3.6 to be installed. or "Python 3.6.2 (64-bit)" if you wish to allow many versions of 3.6 to be installed. "3.6" matches closer to what happens in the unix/linux world (/usr/lib/python2.6). display version string should 3.6.2 or 3.6.2.2150 never 3.6.2150 "large int (DWORD) version number" should not be set, but you could force it to 3.6.2 given your unlikely to go higher than 255.255.65535 the automatic builds might not like doing this, might be easier not to set it. -- ___ Python tracker <http://bugs.python.org/issue31103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31103] Windows Installer Product Version 3.6.2150.0 Offset By 0.0.150.0
Damon Atkins added the comment: The python 3.5.3 (64-bit) installer currently adds most of the components installed in the "MACHINE" Registry all but 1 item (2 entries) "python 3.5.3 (64-bit)" software entry which it places in both the 32 bit and also the 64 bit registry. It should be in the "MACHINE" Registry and only in the 64 bit registry, which is the default for 64 bit installer. For example a 32 bit installer would place "python 3.5.3 (32-bit)" only in the 32 bit part of the registry. -- ___ Python tracker <http://bugs.python.org/issue31103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31103] Windows Installer Product Version 3.6.2150.0 Offset By 0.0.150.0
Damon Atkins added the comment: Because this entry "python 3.5.3 (64-bit)" is the USER part of the registry, only the user who installs python can see that it is installed. -- ___ Python tracker <http://bugs.python.org/issue31103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31103] Windows Installer Product Version 3.6.2150.0 Offset By 0.0.150.0
Damon Atkins added the comment:
To Summaries
A)
Name/DisplayName "Python 3.X (64-bit)" or "Python 3.X.Y" (64-bit) "Python 3.X
(64-bit)" would match the install directory which is \Python3X (this should be
\Python3.X)
Display Version should start with 3.X.Y or 3.X.Y.
version DWORD in the registry does not need to be set but if set would need to
be 3.X.Y
B) Registry being placed in in the wrong location
HKU\\Software\Microsoft\Windows\CurrentVersion\Uninstall\{GUID}
should be going into
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall
C) Suggest the default install dir is
"c:\Program Files\Python3.6" instead of "c:\Program Files\Python36"
--
___
Python tracker
<http://bugs.python.org/issue31103>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows
Damon Atkins added the comment: I see from this. That this is still an issue https://github.com/python/cpython/blob/master/Lib/subprocess.py#L1146 Is it not a solution to save current directory location chdir(cwd) before calling _winapi.CreateProcess() restore the original directory. This will result in the cwd being searched for the executable, which most people would expect to happen. It seems CreateProcess does not change to cwd until after the file is checked for existence or loaded. -- nosy: +Damon Atkins ___ Python tracker <https://bugs.python.org/issue15533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows
Damon Atkins added the comment: See also https://bugs.python.org/msg262399 -- ___ Python tracker <https://bugs.python.org/issue15533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows
Damon Atkins added the comment: >From https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425.aspx Note Python is using CreateProcess(), consider using CreateProcessW() The Unicode version of this function, CreateProcessW, can modify the contents of this string. Therefore, this parameter cannot be a pointer to read-only memory (such as a const variable or a literal string). If this parameter is a constant string, the function may cause an access violation. -- ___ Python tracker <https://bugs.python.org/issue15533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
