[issue31011] Users (except from the one who installed) not able to see python in add remove programs.

[Debarshi Goswami]

New submission from Debarshi Goswami:

When Python (64 bit) is installed for all users from an admin account on 
Windows, it gets installed correctly for all users , but it does not appear in 
add remove program for users other than one who installed it.


Command used : python-3.6.1-amd64.exe /quiet InstallAllUsers=1 PrependPath=1 
TargetDir=C:\apps\Python36

Work around: Repair the installation by launching Python installer again.

--
components: Installation
messages: 298965
nosy: Debarshi.Goswami
priority: normal
severity: normal
status: open
title: Users (except from the one who installed) not  able to see python in add 
remove programs.
type: behavior
versions: Python 3.6

___
Python tracker 
<http://bugs.python.org/issue31011>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31011] Users (except from the one who installed) not able to see python in add remove programs.

[Debarshi Goswami]

Changes by Debarshi Goswami :


--
nosy: +manddy221

___
Python tracker 
<http://bugs.python.org/issue31011>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19283] Need support to avoid Windows CRT compatibility issue.

[Debarshi Goswami]

New submission from Debarshi Goswami:

Some support is needed to avoid compatibility issues in different version of 
CRT in Windows.
I have an application which embeds Python interpreter and the application is 
build on MSVC11, whereas I am using Python 3.3.2 which is build on MSVC10. I 
know there are some compatibility issues which are addressed in Issue10082 and 
Issue1003535. But even other Python APIs which uses FILE pointer inside are 
failing too. I tried the following things – 
1.  PyRun_FileExFlags with MSVC11 FILE*. It crashes as expected.
2.  PyRun_FileExFlags with MSVC10 FILE* using _Py_fopen() directly passing 
to it. It is also crashing whereas _Py_fopen() returns FILE* of MSVC10 type.
3.  Py_CompileString() also crashes. I don’t know the reason, but here my 
application is not providing FILE* from outside. It uses FILE* of Python 
library which is of MSVC10 type.
I did some investigation and found if I provide FILE* of MSVC10 type from my 
application in PyRun_File() or if I call Py_CompileString(), it crashes after 
parsing the file (I am not totally sure, but it seems to me). Here is the call 
stack – 
python33.dll!PyUnicode_InternInPlace(_object * * p) Line 14220 C
python33.dll!new_identifier(const char * n, compiling * c) Line 570 C
python33.dll!alias_for_import_name(compiling * c, const _node * n, int store) 
Line 2808 C
python33.dll!ast_for_import_stmt(compiling * c, const _node * n) Line 2892  C
python33.dll!PyAST_FromNode(const _node * n, PyCompilerFlags * flags, const 
char * filename, _arena * arena) Line 724   C
python33.dll!PyParser_ASTFromFile(_iobuf * fp, const char * filename, const 
char * enc, int start, char * ps1, char * ps2, PyCompilerFlags * flags, int * 
errcode, _arena * arena) Line 2124C
python33.dll!PyRun_FileExFlags(_iobuf * fp, const char * filename, int start, 
_object * globals, _object * locals, int closeit, PyCompilerFlags * flags) Line 
1931  C

It fails in PyDict_GetItem() call in PyUnicode_InternInPlace() function. Here 
is the snippet - 

/* It might be that the GetItem call fails even
   though the key is present in the dictionary,
   namely when this happens during a stack overflow. */
Py_ALLOW_RECURSION
t = PyDict_GetItem(interned, s);
Py_END_ALLOW_RECURSION

I am not sure why PyDict_GetItem() is failing because of FILE*. It seems to me 
that Python is able to parse file provided successfully.

I am initializing interpreter successfully and PyRun_String() API works fine. 
But I dont want to use PyRun_String() as it performs everything virtually and 
provide no debug support.

--
components: Interpreter Core, Windows
messages: 200238
nosy: debarshig
priority: normal
severity: normal
status: open
title: Need support to avoid Windows CRT compatibility issue.
versions: Python 3.3

___
Python tracker 
<http://bugs.python.org/issue19283>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19283] Need support to avoid Windows CRT compatibility issue.

[Debarshi Goswami]

Debarshi Goswami added the comment:

If any workaround is available. It is also fine.

--
type:  -> crash

___
Python tracker 
<http://bugs.python.org/issue19283>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19283] Need support to avoid Windows CRT compatibility issue.

[Debarshi Goswami]

Debarshi Goswami added the comment:

My question is, even a FILE* of MSVC10 type is provided, why these APIs are 
crashing, after all it expects MSVC10 type.

--

___
Python tracker 
<http://bugs.python.org/issue19283>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19582] Tkinter is not working with Py_SetPath

[Debarshi Goswami]

New submission from Debarshi Goswami:

Tkinter is not working when I set PYTHONPATH using Py_SetPath before 
Initialization in an application embedding Python interpreter.

Any call to Py_SetPath is screwing up Tkinter with an error traceback -
-
'Line 1789: Traceback (most recent call last):
  File "TestTK.py", line 33, in 
  File "C:\Python33\Lib\tkinter\__init__.py", line 1789, in __init__
self.tk = _tkinter.create(screenName, baseName, className, interactive, 
wantobjects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following directories: 
C:/Python33/lib/tcl8.5  and so on

This probably means that Tcl wasn't installed properly. 
-
But if set the 2 environment variable it works fine
set TCL_LIBRARY=C:\Python33\tcl\tcl8.5\
set TK_LIBRARY=C:\tcl\tk8.5\

If Py_SetPath is not called tkinter works well and tkwindow can be launched.

I am using Windows7 64 and Python 3.3.2

--
components: Tkinter
messages: 202825
nosy: Debarshi.Goswami
priority: normal
severity: normal
status: open
title: Tkinter is not working with Py_SetPath
versions: Python 3.3

___
Python tracker 
<http://bugs.python.org/issue19582>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19582] Tkinter is not working with Py_SetPath

[Debarshi Goswami]

Changes by Debarshi Goswami :


--
components: +Interpreter Core
type:  -> compile error

___
Python tracker 
<http://bugs.python.org/issue19582>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19582] Tkinter is not working with Py_SetPath

[Debarshi Goswami]

Debarshi Goswami added the comment:

Is there any way to run Tkinter adding some changes from interpreter?

--

___
Python tracker 
<http://bugs.python.org/issue19582>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19582] Tkinter is not working with Py_SetPath

[Debarshi Goswami]

Debarshi Goswami added the comment:

Anyone tried this issue?

--

___
Python tracker 
<http://bugs.python.org/issue19582>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24805] Python installer having problem in installing Python for all users in Windows

[Debarshi Goswami]

New submission from Debarshi Goswami:

Python installer (msi) having problem in installing Python for all users in 
Windows. It gets installed for installing user only. 

I was able to log the python output and found the below in the log. 
MSI (s) (8C:D0) [07:13:00:212]: Determined that existing product (either this 
product or the product being upgraded with a patch) is installed per-user.

I tried the below command combinations  to install python per machine, but it 
seems this a default product behavior. It should be fixed.

1. msiexec /i %setup_loc% TARGETDIR="C:\apps\Python34" ADDLOCAL="ALL" 
ALLUSERS="1" MSIINSTALLPERUSER="" /qb

2. msiexec /i %setup_loc% TARGETDIR="C:\apps\Python34" ADDLOCAL="ALL" 
WHICHUSERS="ALL" /qb 
  
3. msiexec /a %setup_loc% /passive /norestart TARGETDIR="c:\apps\Python34" 
ADDLOCAL="ALL" ALLUSERS="1"


Setup_loc=python msi file location
ADDLOCAL="ALL" -  Install all the features of the product .
ALLUSERS="1" - ALLUSERS property value of 1 specifies the per-machine 
installation .
MSIINSTALLPERUSER="" - MSIINSTALLPERUSER property to an empty string ("") for a 
per-machine installation.

Please let me know if I am missing anything. It seems a bug to me.

--
components: Installation
messages: 248109
nosy: Debarshi.Goswami
priority: normal
severity: normal
status: open
title: Python installer having problem in installing Python for all users in 
Windows
type: behavior
versions: Python 3.4

___
Python tracker 
<http://bugs.python.org/issue24805>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com