[issue36441] Cannot create venv with debug binaries installed

2019-03-26 Thread Christian Ullrich


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

2019-03-26 Thread Christian Ullrich


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

2019-01-21 Thread Christian Ullrich


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

2019-01-21 Thread Christian Ullrich


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

2018-12-02 Thread Christian Ullrich


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

2018-12-02 Thread Christian Ullrich


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

2018-12-02 Thread Christian Ullrich


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

2018-11-13 Thread Christian Ullrich


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()

2017-09-05 Thread Christian Ullrich

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 <rep...@bugs.python.org>
<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()

2017-09-05 Thread Christian Ullrich

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 <rep...@bugs.python.org>
<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()

2017-09-05 Thread Christian Ullrich

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 <rep...@bugs.python.org>
<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

2017-06-09 Thread Christian Ullrich

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 <rep...@bugs.python.org>
<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

2017-06-09 Thread Christian Ullrich

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 <rep...@bugs.python.org>
<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

2017-06-09 Thread Christian Ullrich

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 <rep...@bugs.python.org>
<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

2017-06-09 Thread Christian Ullrich

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 <rep...@bugs.python.org>
<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

2017-03-26 Thread Christian Ullrich

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 <rep...@bugs.python.org>
<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

2017-03-26 Thread Christian Ullrich

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 <rep...@bugs.python.org>
<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

2016-10-25 Thread Christian Ullrich

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 <rep...@bugs.python.org>
<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

2016-06-29 Thread Christian Ullrich

Changes by Christian Ullrich <ch...@chrullrich.net>:


--
nosy: +Christian.Ullrich

___
Python tracker <rep...@bugs.python.org>
<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

2015-11-16 Thread Christian Ullrich

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 <rep...@bugs.python.org>
<http://bugs.python.org/issue25636>
___
___
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

2015-09-18 Thread Christian Ullrich

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 <rep...@bugs.python.org>
<http://bugs.python.org/issue25162>
___
___
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

2015-09-18 Thread Christian Ullrich

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 <rep...@bugs.python.org>
<http://bugs.python.org/issue25163>
___
___
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

2015-09-18 Thread Christian Ullrich

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 <rep...@bugs.python.org>
<http://bugs.python.org/issue25164>
___
___
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

2015-09-18 Thread Christian Ullrich

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 <rep...@bugs.python.org>
<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

2015-09-18 Thread Christian Ullrich

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 <rep...@bugs.python.org>
<http://bugs.python.org/issue25165>
___
___
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

2015-09-15 Thread Christian Ullrich

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 <rep...@bugs.python.org>
<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

2014-06-23 Thread Christian Ullrich

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 rep...@bugs.python.org
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

2014-03-23 Thread Christian Ullrich

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 rep...@bugs.python.org
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

2014-03-23 Thread Christian Ullrich

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 rep...@bugs.python.org
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

2014-03-22 Thread Christian Ullrich

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 
module
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\pipicacls __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 rep...@bugs.python.org
http://bugs.python.org/issue21030
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com