[issue41800] Python installation fails when run under system account if there is already an existing installation on the system already

2020-09-18 Thread Jurko Gospodnetić

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

2020-09-17 Thread Jurko Gospodnetić

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

2020-09-17 Thread Jurko Gospodnetić

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

2020-09-17 Thread Jurko Gospodnetić

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)

2020-09-17 Thread Jurko Gospodnetić

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

2020-09-17 Thread Jurko Gospodnetić

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

2020-09-17 Thread Jurko Gospodnetić

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

2020-06-03 Thread Jurko Gospodnetić

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

2014-10-05 Thread Jurko Gospodnetić

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

2014-10-05 Thread Jurko Gospodnetić

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

2014-10-05 Thread Jurko Gospodnetić

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

2014-08-18 Thread Jurko Gospodnetić

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

2014-08-18 Thread Jurko Gospodnetić

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)

2014-05-03 Thread Jurko Gospodnetić

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)

2014-05-02 Thread Jurko Gospodnetić

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)

2014-05-02 Thread Jurko Gospodnetić

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

2014-04-12 Thread Jurko Gospodnetić

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

2014-04-10 Thread Jurko Gospodnetić

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

2014-04-05 Thread Jurko Gospodnetić

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

2014-04-03 Thread Jurko Gospodnetić

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

2014-03-29 Thread Jurko Gospodnetić

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

2014-03-29 Thread Jurko Gospodnetić

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

2014-03-23 Thread Jurko Gospodnetić

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

2014-03-21 Thread Jurko Gospodnetić

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

2014-03-19 Thread Jurko Gospodnetić

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

2014-03-19 Thread Jurko Gospodnetić

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

2014-03-19 Thread Jurko Gospodnetić

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

2014-03-19 Thread Jurko Gospodnetić

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

2014-03-19 Thread Jurko Gospodnetić

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

2014-03-14 Thread Jurko Gospodnetić

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

2014-03-12 Thread Jurko Gospodnetić

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

2014-03-12 Thread Jurko Gospodnetić

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

2014-03-12 Thread Jurko Gospodnetić

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

2014-03-12 Thread Jurko Gospodnetić

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

2014-03-12 Thread Jurko Gospodnetić

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

2014-03-11 Thread Jurko Gospodnetić

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

2014-03-11 Thread Jurko Gospodnetić

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

2014-03-11 Thread Jurko Gospodnetić

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

2014-03-10 Thread Jurko Gospodnetić

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

2014-03-10 Thread Jurko Gospodnetić

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

2014-03-10 Thread Jurko Gospodnetić

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

2014-03-10 Thread Jurko Gospodnetić

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

2014-03-10 Thread Jurko Gospodnetić

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

2014-03-10 Thread Jurko Gospodnetić

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

2014-03-10 Thread Jurko Gospodnetić

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

2014-03-10 Thread Jurko Gospodnetić

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

2014-02-24 Thread Jurko Gospodnetić

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

2014-02-24 Thread Jurko Gospodnetić

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

2014-02-24 Thread Jurko Gospodnetić

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

2013-12-14 Thread Jurko Gospodnetić

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

2013-12-14 Thread Jurko Gospodnetić

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

2013-12-14 Thread Jurko Gospodnetić

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

2013-12-14 Thread Jurko Gospodnetić

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

2013-12-14 Thread Jurko Gospodnetić

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

2013-12-14 Thread Jurko Gospodnetić

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

2013-12-14 Thread Jurko Gospodnetić

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

2013-12-14 Thread Jurko Gospodnetić

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

2010-12-11 Thread Jurko Gospodnetić

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

2010-12-11 Thread Jurko Gospodnetić

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