subject:"Environment Variable"



Irit Katriel  added the comment:

> os.environ defines the __delitem__ method to call C unsetenv(). Thus `del 
> os.environ[varname]` does unset the environment variable, at least at the 
> level of the C runtime.


For the current process, yes. But it's not that what the user needs to do to 
fix the problem is to define an environment variable and rerun the program.

--

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

[issue44264] Add descriptive error message when environment variable not detected

2022-01-29 Thread Eryk Sun



Eryk Sun  added the comment:

This is just a point of clarification.

> my del did not change the environment variable

os.environ defines the __delitem__ method to call C unsetenv(). Thus `del 
os.environ[varname]` does unset the environment variable, at least at the level 
of the C runtime.

--
nosy: +eryksun

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

[issue44264] Add descriptive error message when environment variable not detected



Irit Katriel  added the comment:

I vote to reject this proposal. Unless another core dev disagrees, I will close 
this issue.

--
status: pending -> open

___
Python tracker 

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

[issue44264] Add descriptive error message when environment variable not detected



Irit Katriel  added the comment:

> if a user of a Python program were to come across it, it may not indicate 
> what they needed to do to avoid the crash. 

The user of a program should not see this exception. The program should 
translate it to an error that would make sense to the user.

--
resolution:  -> rejected
status: open -> pending

___
Python tracker 

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

[issue44264] Add descriptive error message when environment variable not detected



Irit Katriel  added the comment:

It's not necessarily true that the environment variable is not set just because 
the key is not in os.environ. In this example my del did not change the 
environment variable:

>>> import os
>>> os.environ['TMPDIR']
'/var/folders/kf/0v7kz3ps62dg11v9rq0sz35mgn/T/'
>>> del os.environ['TMPDIR']
>>> os.environ['TMPDIR']
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 678, in __getitem__
KeyError: 'TMPDIR'

--
nosy: +iritkatriel

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

[issue46226] User specific paths added to System PATH environment variable

2022-01-10 Thread Steve Dower



Steve Dower  added the comment:

Without logs or the ability to reproduce it, there's not much we can do. I ran 
the install and it put the variables in the right place, so it's not happening 
all the time.

The install logs are usually detailed enough to see why decisions like this are 
made, but it'll almost certainly be because of something specific to your 
machine. If running the install again produces the same result, those logs will 
be helpful as well. I don't see us being able to make any product changes for 
this though.

--

___
Python tracker 

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

[issue46226] User specific paths added to System PATH environment variable

2022-01-10 Thread Aleksandr Krymskiy



Aleksandr Krymskiy  added the comment:

I installed 3.10, and then removed 3.9 that I had installed previously. Python 
is installed in "C:\Program Files\Python310". The only thing that exists under 
%LocalAppData% is an empty directory 
"C:\Users\avk\AppData\Local\Programs\Python\Python310\Scripts" - I always 
install "for all users" so there isn't anything else under the 
"C:\Users\avk\AppData\Local\Programs\Python" other than the empty directory I 
mentioned.

--

___
Python tracker 

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

[issue46226] User specific paths added to System PATH environment variable

2022-01-07 Thread Eryk Sun



Eryk Sun  added the comment:

Were you upgrading an existing installation of Python 3.10? Did it actually 
install in "C:\Program Files\Python310"? Is Python currently installed in 
per-user "%LocalAppData%\Programs\Python\Python310"? Was it ever installed 
there?

--
nosy: +eryksun

___
Python tracker 

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

[issue46226] User specific paths added to System PATH environment variable

2022-01-07 Thread Aleksandr Krymskiy



Aleksandr Krymskiy  added the comment:

I did not find install logs in my user %TEMP% or C:\Windows\Temp. I did select 
"install for all users" during setup just like I always do, but I did not 
override the default location of "C:\Program Files\Python310". I attached 
screenshots of the options selected during setup.

--
Added file: https://bugs.python.org/file50549/py_install_options.png

___
Python tracker 

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

[issue46226] User specific paths added to System PATH environment variable

2022-01-03 Thread Steve Dower



Steve Dower  added the comment:

If you have them, can you share your install logs (look in %TEMP% for files 
starting with "Python"). If not, please share your install options.

By default, this works fine. You have to make some specific modifications to 
the install options to do what you've done, such as choosing to install for all 
users and then overriding the install path to a per-user location. If you're 
installing just for yourself, the installer shouldn't even have the permissions 
required to modify system-wide environment variables.

It's also possible that your machine has a special configuration to do this, in 
which case you'll need to speak with your administrator to find out why. We 
can't help with that - we just use standard MSIs and let the OS choose where 
things go.

--

___
Python tracker 

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

[issue46226] User specific paths added to System PATH environment variable

2022-01-02 Thread Ned Deily



Change by Ned Deily :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue46226] User specific paths added to System PATH environment variable

2022-01-02 Thread Aleksandr Krymskiy



New submission from Aleksandr Krymskiy :

Installed Python 3.10.1 using Windows 64-bit installer from python.org. Upon 
examining the PATH environment variables I noticed that my local user paths 
(C:\Users\avk\AppData\...) have been added to the System-level PATH variable 
instead of User level, which can cause problems on multi-user systems, since 
users other than mine will now have these paths in their environment causing 
them to potentially try to execute code from unexpected location that they 
should not even have access too. User paths should be added to User specific 
PATH environment variable and only global (C:\Program Files\Python310\...) kept 
in the System scope by the installer. Please see my screenshot - the 
highlighted should be moved to User scoped PATH var.

--
components: Installation
files: py_paths.png
messages: 409507
nosy: akrymskiy
priority: normal
severity: normal
status: open
title: User specific paths added to System PATH environment variable
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file50535/py_paths.png

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

[issue45969] When uninstalling Python under Windows the "Scripts" folders should be removed from the PATH environment variable

2021-12-02 Thread Steve Dower



Steve Dower  added the comment:

Unless someone can find an authoring bug under Tools/msi, I don't think we can 
do anything about this. We rely on the built-in Windows support for adding and 
removing these variables, and if that's broken, we can't do anything with our 
current setup.

I really want to get us out of this addiction to cluttering up PATH with lots 
of different directories - it's bad for security/reliability/etc. of the system 
as a whole, and I don't like Python being the cause of issues here. But I 
haven't quite come up with the better design yet... 

Anyway, all that to say that I'm not in any rush to expand or seriously mess 
with the current PATH settings. If there's an authoring bug we can fix, great, 
but I don't think this one is on us in a way we can easily deal with.

--

___
Python tracker 

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

[issue45969] When uninstalling Python under Windows the "Scripts" folders should be removed from the PATH environment variable

2021-12-02 Thread Luca



New submission from Luca :

This issue is related to:
  https://bugs.python.org/issue3561
and:
  https://bugs.python.org/issue45968

When installing Python under Windows, if the "Add Python 3.x to PATH" option is 
flagged, the following two folders are added to the PATH environment variable:
  %USERPROFILE%\AppData\Local\Programs\Python\Python3x\
  %USERPROFILE%\AppData\Local\Programs\Python\Python3x\Scripts\

However when uninstalling Pyhton only the former folder is removed from the 
PATH environment variable, and not the latter one.

Moreover if also the following folder will be added to the PATH environment 
variable in future (see issue #45968):
  %USERPROFILE%\AppData\Roaming\Python\Python3x\Scripts\
then the same would apply to it.

--
components: Installation, Windows
messages: 407551
nosy: lucatrv, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: When uninstalling Python under Windows the "Scripts" folders should be 
removed from the PATH environment variable
type: enhancement
versions: Python 3.10

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

[issue45968] Windows installer should add also "%USERPROFILE%\AppData\Roaming\Python\Python3x\Scripts" folder to the PATH environment variable

2021-12-02 Thread Luca



New submission from Luca :

This issue is related to https://bugs.python.org/issue3561

When installing Python under Windows, if the "Add Python 3.x to PATH" option is 
flagged, the following two folders are added to the PATH environment variable:
%USERPROFILE%\AppData\Local\Programs\Python\Python3x\
%USERPROFILE%\AppData\Local\Programs\Python\Python3x\Scripts\

However also the following folder should be added, which is where scripts 
reside when packages are installed with "pip install --user":
%USERPROFILE%\AppData\Roaming\Python\Python3x\Scripts\

--
components: Installation, Windows
messages: 407550
nosy: lucatrv, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows installer should add also 
"%USERPROFILE%\AppData\Roaming\Python\Python3x\Scripts" folder to the PATH 
environment variable
type: enhancement
versions: Python 3.10

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

[issue43773] macOS official installer builds not respecting DYLD_LIBRARY_PATH environment variable.

2021-11-09 Thread Brandt Bucher



Change by Brandt Bucher :


--
nosy:  -brandtbucher

___
Python tracker 

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

[issue43773] macOS official installer builds not respecting DYLD_LIBRARY_PATH environment variable.

2021-11-09 Thread Brandt Bucher



Change by Brandt Bucher :


--
pull_requests:  -27755

___
Python tracker 

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

[issue43773] macOS official installer builds not respecting DYLD_LIBRARY_PATH environment variable.

2021-11-09 Thread Brandt Bucher



Change by Brandt Bucher :


--
nosy: +brandtbucher
nosy_count: 3.0 -> 4.0
pull_requests: +27755
pull_request: https://github.com/python/cpython/pull/29505

___
Python tracker 

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

[issue44352] Native Windows Python builds running on Europe/Moscow TZ report wrong time from datetime.datetime.now when there is TZ environment variable also set to Europe/Moscow

2021-06-11 Thread Mike Kaganski



Mike Kaganski  added the comment:

@Eryk Sun: yes, of course you are right - but please see the date of the 
commit; I didn't know what you kindly explained me in your reply yesterday :-) 
Thank you again.

--

___
Python tracker 

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

[issue44352] Native Windows Python builds running on Europe/Moscow TZ report wrong time from datetime.datetime.now when there is TZ environment variable also set to Europe/Moscow

2021-06-11 Thread Eryk Sun



Eryk Sun  added the comment:

Note that this explanation in your commit is wrong and unhelpful: "likely 
because datetime.datetime.now in the native Windows Python takes into account 
both system timezone data and the TZ environment variable". When TZ is set, 
localtime() is based only on the TZ value, and daylight saving time uses only 
U.S. rules (e.g. beginning 2021-03-14 and ending 2021-11-07). The value must be 
of the form "tzn [+|-]hh[:mm[:ss] ][dzn]", but there is no validation. So 
"Europe/Moscow" is invalid and gets parsed as UTC with U.S. DST. I recommend 
clearing the TZ variable because the value format is non-standard, and its DST 
support is U.S.-centric nonsense.

--

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

[issue44352] Native Windows Python builds running on Europe/Moscow TZ report wrong time from datetime.datetime.now when there is TZ environment variable also set to Europe/Moscow

2021-06-10 Thread Mike Kaganski



Mike Kaganski  added the comment:

Thank you Eryk! This is a good workaround for me. I have implemented it: 
https://git.libreoffice.org/core/+/3bcaa4ba79477a21251ddaa06e0ea159196a7ffb

It looks like it's not a Python's problem; I suppose this may be closed. Thanks 
again!

--
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue44352] Native Windows Python builds running on Europe/Moscow TZ report wrong time from datetime.datetime.now when there is TZ environment variable also set to Europe/Moscow

2021-06-09 Thread Eryk Sun



Eryk Sun  added the comment:

> 2. Execute 'set TZ=Europe/Moscow'

The Windows C runtime supports a simple format for the TZ environment variable, 
which is detailed in the documentation of _tzset() [1]. For example, it's 
"MSK-3" for Moscow Standard Time. It's -3 because the offset is from local time 
to UTC. 

The CRT does not verify that the TZ value is valid. "Europe/Moscow" is invalid, 
but it's blindly parsed anyway. There's no UTC offset, so it defaults to UTC (0 
offset). It's parsed as supporting daylight saving time, according to U.S. 
rules. Currently this corresponds to UTC + 1. That's why there's a -2 hour 
delta from Moscow Standard Time, which does not observe daylight saving time.

I recommend that you unset the TZ environment variable before running Windows 
Python. Use the system timezone.

---
[1] 
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-160

--
nosy: +eryksun

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

[issue44352] Native Windows Python builds running on Europe/Moscow TZ report wrong time from datetime.datetime.now when there is TZ environment variable also set to Europe/Moscow

2021-06-09 Thread Zachary Ware



Change by Zachary Ware :


--
nosy: +belopolsky, p-ganssle

___
Python tracker 

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

[issue44352] Native Windows Python builds running on Europe/Moscow TZ report wrong time from datetime.datetime.now when there is TZ environment variable also set to Europe/Moscow

2021-06-08 Thread Mike Kaganski

New submission from Mike Kaganski :

On a Windows 10 system, which TZ is set to Moscow (UTC+3), I use a native
Windows Python build (as opposed to e.g. one from Cygwin). Specifically, I
tested both custom Python build created by LibreOffice project, as well as the
Python by Python Software Foundation available from MS Store [1].

1. Open command prompt on Windows (cmd.exe).
2. Execute 'set TZ=Europe/Moscow'
3. Execute 'python'
4. In the Python prompt, execute 'import datetime'
5. Execute 'datetime.datetime.now()'

The result of this is a time that is two hours off, e.g.

> datetime.datetime(2021, 6, 8, 19, 59, 21, 925240)

instead of proper

> datetime.datetime(2021, 6, 8, 21, 59, 21, 925240)

which appears when step #2 is skipped.
Possibly Python takes both system time zone information *and* the environment
variable into account when calculating the time. I suppose it should only
consider one or the other, not both.

Note that the problem does not happen with Cygwin's Python, which works fine
with the same TZ environment variable value.

For a real-life problem that results from this, see case at [2], where unit
test is failing only from 00:00 till 02:00 on my local system, obviously
telling me that I should sleep at that time, not try to run unit tests :-)

[1] https://www.microsoft.com/en-us/p/python-38/9mssztt1n39l
[2]
https://gerrit.libreoffice.org/c/core/+/92217/2#message-f55091795e7cde9d75adc00ddb69451121b644f6

--
components: Windows
messages: 395355
nosy: mikekaganski, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Native Windows Python builds running on Europe/Moscow TZ report wrong
time from datetime.datetime.now when there is TZ environment variable also set
to Europe/Moscow
type: behavior
versions: Python 3.8

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

[issue44264] Add descriptive error message when environment variable not detected

2021-05-29 Thread David Gene



New submission from David Gene :

Using os.environ[KEY] with a non-existent environment variable key only gives a 
simple KeyError, which may be fine for a developer to understand, but if a user 
of a Python program were to come across it, it may not indicate what they 
needed to do to avoid the crash. I would raising the keyError with a message 
such as "Environment variable '{}' not set".

--
messages: 394735
nosy: astrosticks
priority: normal
pull_requests: 25047
severity: normal
status: open
title: Add descriptive error message when environment variable not detected
type: enhancement
versions: Python 3.11

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

[issue43773] macOS official installer builds not respecting DYLD_LIBRARY_PATH environment variable.

2021-04-09 Thread Carlton Gibson


Carlton Gibson  added the comment:

Hi Ned, 

Thank you for the reply. That explains a lot. I hadn't considered that SQLite 
would be statically linked. 

> I believe the original reason was to avoid linking with the Apple-supplied 
> system copy of the sqlite3 library.

I can see that being a goal, yes. 

It's likely a niche use-case needing to adjust the SQLite version, so …

Thanks again!

--

___
Python tracker 

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

[issue43773] macOS official installer builds not respecting DYLD_LIBRARY_PATH environment variable.

2021-04-08 Thread Ned Deily



Ned Deily  added the comment:

Thanks for the report. However, I think you've drawn the wrong conclusion form 
what you've observed. The reason you are unable to do what you are trying to do 
is that the _sqlite3 module included with the python.org macOS Pythons is 
statically linked with its own copy of an sqlite3 library, not dynamically 
linked. This has been true for a long time (10+ years); I believe the original 
reason was to avoid linking with the Apple-supplied system copy of the sqlite3 
library.  You can see this by using otool:

- with the python.org 3.9.4:

$ /usr/local/bin/python3.9 -c 'import sys;print(sys.version)'
3.9.4 (v3.9.4:1f2e3088f3, Apr  4 2021, 12:19:19)
[Clang 12.0.0 (clang-1200.0.32.29)]
$ /usr/local/bin/python3.9 -c 'import _sqlite3;print(_sqlite3.__file__)'
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_sqlite3.cpython-39-darwin.so
$ otool -L $(/usr/local/bin/python3.9 -c 'import 
_sqlite3;print(_sqlite3.__file__)')
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_sqlite3.cpython-39-darwin.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1292.60.1)

- with a MacPorts python3.9.4:

$ /opt/macports/bin/python3.9 -c 'import _sqlite3;print(_sqlite3.__file__)'
/opt/macports/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_sqlite3.cpython-39-darwin.so
$ otool -L $(/opt/macports/bin/python3.9 -c 'import 
_sqlite3;print(_sqlite3.__file__)')
/opt/macports/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_sqlite3.cpython-39-darwin.so:
/opt/macports/lib/libsqlite3.0.dylib (compatibility version 9.0.0, 
current version 9.6.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1292.60.1)

If you want to replace the sqlite3 library, you would need to rebuild the 
_sqlite3 module. That's not something we would encourage or support.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue43773] macOS official installer builds not respecting DYLD_LIBRARY_PATH environment variable.

2021-04-08 Thread Carlton Gibson


New submission from Carlton Gibson :

Hi. 

On MacOS 11.3 "Big Sur", with the latest 3.9.4 installed with the official 
installer downloaded from python.org, the DYLD_LIBRARY_PATH environment 
variable is not being respected. 

This looks very similar to Issue40198
https://bugs.python.org/issue40198

To begin everything looks correct as per 40198:

~ $ python3 --version
Python 3.9.4
~ $ which python3
/Library/Frameworks/Python.framework/Versions/3.9/bin/python3
~ $ codesign --display --entitlements=:- 
/Library/Frameworks/Python.framework/Versions/3.9/bin/python3
Executable=/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9

http://www.apple.com/DTDs/PropertyList-1.0.dtd;>


com.apple.security.cs.allow-dyld-environment-variables

com.apple.security.cs.disable-library-validation

com.apple.security.cs.disable-executable-page-protection

com.apple.security.automation.apple-events





The active python is that from the official installer, and it looks to have the 
correct entitlements, as per the resolution to 40198. 

However, it's not working in practice. 

I create a script test: 

~ $ cat ~/bin/sqlite_config.py 
import os
import sqlite3

print("DYLD_LIBRARY_PATH:" )
print(os.getenv('DYLD_LIBRARY_PATH'))

print("SQLite Version:")
print(sqlite3.sqlite_version)

Together with a compiled SQLite version: 

~ $ ls /Users/carlton/lib/sqlite/3.35.4
libsqlite3.dylib

Trying to use this, the dylib is not picked up: 

~ $ DYLD_LIBRARY_PATH="/Users/carlton/lib/sqlite/3.35.4" python3 
~/bin/sqlite_config.py 
DYLD_LIBRARY_PATH:
/Users/carlton/lib/sqlite/3.35.4
SQLite Version:
3.34.0

Contrast the same when run with a pyenv installed python: 

~ $ pyenv which python3.8
/Users/carlton/.pyenv/versions/3.8.3/bin/python3.8
~ $ DYLD_LIBRARY_PATH="/Users/carlton/lib/sqlite/3.35.4" 
/Users/carlton/.pyenv/versions/3.8.3/bin/python3.8 ~/bin/sqlite_config.py 
DYLD_LIBRARY_PATH:
/Users/carlton/lib/sqlite/3.35.4
SQLite Version:
3.35.4

The expected result, in both cases, is that the last lines should read: 

SQLite Version:
3.35.4



I don't know if this is the result of a tightening in macOS' SIP in Big Sur (or 
something else entirely...) — I thought to test it by installing the official 
build in a different location (so not in the SIP protected `/Library/` space 
but somewhere in `~` but the installer doesn't look like it allows that (no 
doubt for good reasons). 

Next step for me with be building from source to see if I can dig deeper, but I 
thought I'd report it, as it does look like a change in behaviour from the 
*success* reported in 40198. 

Thanks very much!

--
components: macOS
messages: 390529
nosy: carltongibson, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: macOS official installer builds not respecting DYLD_LIBRARY_PATH 
environment variable.
type: behavior
versions: Python 3.9

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

[issue27263] Tkinter sets the HOME environment variable, breaking scripts

2021-02-26 Thread Eryk Sun



Eryk Sun  added the comment:

ntpath.expanduser() no longer uses HOME (though the doc string still refers to 
$HOME), so at least that problem is resolved. 

I suppose IDLE could work around the HOME issue in Windows by passing 
env=os.environ.copy() in the subprocess.Popen() call that creates the 
subprocess. os.environ will not contain the HOME value that TCL sets in the 
underlying process environment.

--
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.5, Python 
3.6

___
Python tracker 

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

[issue37680] distutils appends LDFLAGS environment variable before object file names

2021-02-03 Thread Steve Dower



Steve Dower  added the comment:

Distutils is now deprecated (see PEP 632) and all tagged issues are being 
closed. From now until removal, only release blocking issues will be considered 
for distutils.

If this issue does not relate to distutils, please remove the component and 
reopen it. If you believe it still requires a fix, most likely the issue should 
be re-reported at https://github.com/pypa/setuptools

--
nosy: +steve.dower
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue28288] Expose environment variable PYTHON_OPT as alternative to command line options

2020-11-30 Thread Irit Katriel



Irit Katriel  added the comment:

It's too late for the PYTHON3WARNINGS variable in 2.7, but Serhiy's suggestion 
for PYTHON_OPTS can still be implemented. Updating title and version 
accordingly.

--
nosy: +iritkatriel
title: Expose environment variable for Py_Py3kWarningFlag -> Expose environment 
variable PYTHON_OPT as alternative to command line options
versions: +Python 3.10 -Python 2.7

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

[issue35328] Set a environment variable for venv prompt

2020-09-21 Thread Brett Cannon



Change by Brett Cannon :


--
resolution: fixed -> 
status: closed -> open
versions: +Python 3.10 -Python 3.9

___
Python tracker 

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

[issue35328] Set a environment variable for venv prompt

2020-09-19 Thread Mathias Fredriksson



Change by Mathias Fredriksson :


--
pull_requests: +21368
pull_request: https://github.com/python/cpython/pull/22324

___
Python tracker 

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

[issue35328] Set a environment variable for venv prompt

2020-09-19 Thread Mathias Fredriksson



Mathias Fredriksson  added the comment:

I believe GH-21587 does not fully address this issue because VIRTUAL_ENV_PROMPT 
is being conditionally set only if VIRTUAL_ENV_DISABLE_PROMPT is unset. Shell 
prompts must set VIRTUAL_ENV_DISABLE_PROMPT to non-empty to prevent venv from 
hijacking PS1. I'm one of the maintainers of the Pure prompt for zsh, and it 
would be great if VIRTUAL_ENV_PROMPT could always be set, just as VIRTUAL_ENV 
is too.

--
nosy: +mafredri

___
Python tracker 

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

[issue35328] Set a environment variable for venv prompt

2020-09-09 Thread Vinay Sajip



Change by Vinay Sajip :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue35328] Set a environment variable for venv prompt

2020-07-28 Thread Vinay Sajip



Vinay Sajip  added the comment:


New changeset c82dda1e08c4b74ca24f88d6a549d93108c319cf by Zackery Spytz in 
branch 'master':
bpo-35328: Set VIRTUAL_ENV_PROMPT at venv activation (GH-21587)
https://github.com/python/cpython/commit/c82dda1e08c4b74ca24f88d6a549d93108c319cf


--

___
Python tracker 

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

[issue35328] Set a environment variable for venv prompt

2020-07-21 Thread Zackery Spytz



Change by Zackery Spytz :


--
nosy: +ZackerySpytz
nosy_count: 6.0 -> 7.0
pull_requests: +20727
pull_request: https://github.com/python/cpython/pull/21587

___
Python tracker 

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

[issue40886] Add PYTHONLOGGING environment variable and -L cmdline argument

2020-06-05 Thread Karthikeyan Singaravelan



Change by Karthikeyan Singaravelan :


--
nosy: +vinay.sajip

___
Python tracker 

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

[issue40886] Add PYTHONLOGGING environment variable and -L cmdline argument

2020-06-05 Thread Bar Harel



New submission from Bar Harel :

Per discussion on mailing list, I suggest adding a PYTHONLOGGING environment 
variable, and a matching -L cmdline argument.

When set to a logging level of choice, they will initiate basicConfig with the 
appropriate level.

For example, "py.exe -L info" will be equivalent to 
"logging.basicConfig(level='info')" on interpreter startup.

Sames as setting env var "PYTHONLOGGING=info".

This matches the current behavior of other settings, such as PYTHONWARNINGS and 
-W, allows to easily test programs without modifying them, and further 
completes the expected arguments available from the commandline.

Discussion on mailing list for reference:
https://mail.python.org/archives/list/python-id...@python.org/thread/I74LVJWJLE2LUCCZGOF5A5JDSDHJ6WX2/

--
components: Library (Lib)
messages: 370807
nosy: bar.harel
priority: normal
severity: normal
status: open
title: Add PYTHONLOGGING environment variable and -L cmdline argument
type: enhancement
versions: Python 3.10

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

[issue30462] urllib does not support NO_PROXY environment variable containing domain with asterisk

2020-05-27 Thread Cheryl Sabella



Cheryl Sabella  added the comment:

The original pull request has been closed for inactivity, so this is now 
available for anyone to work on.  Please credit the original author if anyone 
change is based on the original PR.  Thanks!

--
nosy: +cheryl.sabella
versions: +Python 3.10 -Python 3.8

___
Python tracker 

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

[issue40781] Remove sys._debugmallocstats() function and PYTHONMALLOCSTATS environment variable



STINNER Victor  added the comment:

> Please, don't remove these as I use them often to track down memory usage in 
> a similar way as Inada-san.

Ok, sure. I close my issue and I closed my PR.

Note: Maybe your advanced usage of statistics on memory allocators should be 
documented somewhere in https://devguide.python.org/.

--
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue40781] Remove sys._debugmallocstats() function and PYTHONMALLOCSTATS environment variable

2020-05-26 Thread Pablo Galindo Salgado



Pablo Galindo Salgado  added the comment:

Please, don't remove these as I use them often to track down memory usage in a 
similar way as Inada-san.

--

___
Python tracker 

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

[issue40781] Remove sys._debugmallocstats() function and PYTHONMALLOCSTATS environment variable

2020-05-26 Thread Inada Naoki



Inada Naoki  added the comment:

I use it often when I investigate memory usage.
It provides some useful information even in release Python build. For example:

* Which size class is most allocated?
* How many block are allocated?
* Which size class have most free blocks? (e.g. Inner fragmentation)
* Combined with tracing application to stderr, which part of the application 
increase memory usage?

--

___
Python tracker 

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

[issue40781] Remove sys._debugmallocstats() function and PYTHONMALLOCSTATS environment variable



STINNER Victor  added the comment:

> I use it often when I investigate memory usage.

Oh. If you use it, we should keep the feature :-)

--

___
Python tracker 

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

[issue40781] Remove sys._debugmallocstats() function and PYTHONMALLOCSTATS environment variable



New submission from STINNER Victor :

I never used sys._debugmallocstats() function or PYTHONMALLOCSTATS environment 
variable, whereas I spend significant time on optimizing memory allocators and 
free lists. The output is written into stderr which is very convenient to 
process these data.

I only "re"-discovered recently this debug feature when writing PR 20247 "Make 
tuple free list per-interpreter": I had to update _PyTuple_DebugMallocStats().

Removing this debug feature reduces the maintenance burden.

Attached PR removes all code related to the sys._debugmallocstats() function 
and the PYTHONMALLOCSTATS environment variable.

If someone wants to hack Python memory allocators or free lists, I suggest to 
add temporary code to dump some stats. But I don't think that it's worth it to 
keep the feature for all uses in Python.

People who worry about the memory usage of their application don't have to go 
into this low level of details, but care more about memory peak, where the 
memory was allocated (ex: tracemalloc module), RSS memory, etc.

--
components: Interpreter Core
messages: 369987
nosy: vstinner
priority: normal
severity: normal
status: open
title: Remove sys._debugmallocstats() function and PYTHONMALLOCSTATS 
environment variable
versions: Python 3.10

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

[issue40781] Remove sys._debugmallocstats() function and PYTHONMALLOCSTATS environment variable



STINNER Victor  added the comment:

"Recent" changes in builtin Python debug tools.

* In Python 3.9, I removed the "COUNT_ALLOCS" special build: bpo-39489.

* Debug build of Python 3.8 is now ABI compatible with release build: I 
disabled Py_TRACE_REFS macro by default in --with-pydebug build. There is a new 
opt-in --with-trace-refs option for configure. We have a dedicated buildbot to 
ensure that the feature continue to work.

* In Python 3.8, I modified the debug hooks on Python memory allocators to omit 
the serial number by default. It reduces the memory footprint when these hooks 
are used (1 size_t per memory block). Extract of Objects/obmalloc.c:

/* Uncomment this define to add the "serialno" field */
/* #define PYMEM_DEBUG_SERIALNO */

--

___
Python tracker 

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

[issue40781] Remove sys._debugmallocstats() function and PYTHONMALLOCSTATS environment variable



STINNER Victor  added the comment:

INADA-san, Antoine, Serhiy, Pablo: did any of you used this feature recently? 
Is it useful for your hacks?

--
nosy: +inada.naoki, pablogsal, pitrou, serhiy.storchaka

___
Python tracker 

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

[issue40781] Remove sys._debugmallocstats() function and PYTHONMALLOCSTATS environment variable



Change by STINNER Victor :


--
keywords: +patch
pull_requests: +19687
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/20430

___
Python tracker 

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

[issue40542] path environment variable not created correctly

2020-05-07 Thread Zachary Ware



Zachary Ware  added the comment:

Just a note to add my full support for what Steve said.  PATH is frequently 
abused on Windows, and we only have the option at all because people become 
unreasonably upset if it's not there.  I wouldn't be against adding a "you 
don't actually want this, use py.exe" note to the option, though :)

--

___
Python tracker 

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

[issue40542] path environment variable not created correctly

2020-05-07 Thread Steve Dower



Steve Dower  added the comment:

Yes, it is bad behaviour, but it is very upsetting for many people to not have 
the option. This is why it's disabled by default, and why I regularly 
discourage people from selecting the option (and quite often get abused for 
taking the trouble... oh well... that's apparently how open-source life works 
these days).

If you install just for the current user, it will only appear ahead of the 
user's own PATH entries, which are stored separately from the system ones and 
concatenated automatically (unless the whole thing exceeds a certain length, in 
which case you just lose PATH entries... another reason to avoid it).

Adding to the end of the PATH would leave people broken and confused as any 
other install of Python would still take precedence. So to minimize breakage, 
it goes to the front, but the per-user install is the default.

So thanks for the support, but unfortunately we don't have any viable way to 
move forward on it. Tell people not to add to PATH and to run py.exe instead - 
which we've been doing for years, but it doesn't really have much effect.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue40542] path environment variable not created correctly

2020-05-06 Thread Eryk Sun



Eryk Sun  added the comment:

Prepending directories ahead of system directories in PATH affects programs 
that implement their own search, which includes shells such as cmd.exe that do 
so in order to support PATHEXT efficiently. That said, note that temporarily 
prepending to PATH in a particular environment is common. Consider an activated 
virtual environment or a developer command prompt.

Usually programs defer to a Windows API function when searching for a file. The 
API uses search paths from the runtime library functions RtlGetSearchPath, 
RtlGetExePath, and LdrGetDllPath.

With WINAPI SearchPathW, the default search path is from RtlGetSearchPath 
(undocumented). It includes the following directories in non-safe search mode 
(the default mode):

  1. %__APPDIR__%
  2. %__CD__%
  3. %SystemRoot%\System32
  4. %SystemRoot%\System
  5. %SystemRoot%
  6. %PATH%

and the following adjusted order in safe search mode:

  1. %__APPDIR__%
  3. %SystemRoot%\System32
  4. %SystemRoot%\System
  5. %SystemRoot%
  2. %__CD__%
  6. %PATH%

Safe search mode can be set via WINAPI 
SetSearchPathMode(BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE).

With WINAPI CreateProcessW, the search path is from RtlGetExePath 
(undocumented). This is similar to the result from RtlGetSearchPath, except, 
instead of supporting a safe search mode, RtlGetExePath allows excluding the 
current directory (%__CD__%) from the search path by setting the environment 
variable NoDefaultCurrentDirectoryInExePath.

With WINAPI LoadLibrary[Ex]W, the system uses the search path from 
LdrGetDllPath (undocumented). The default DLL search path at startup under 
normal circumstances is the same as the safe-mode result from RtlGetSearchPath 
-- except for special casing of known system DLLs and API sets.

--
nosy: +eryksun

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

[issue40542] path environment variable not created correctly

2020-05-06 Thread Ned Deily



Change by Ned Deily :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue40542] path environment variable not created correctly

2020-05-06 Thread Roman



New submission from Roman :

The Python 3.8 for Windows installer has an option to add the install folder to 
the path environment variable. It adds the path to the front of the list so 
that it is the first item. According to my understanding, this is bad behavior. 
It should add new path items to the end of the list because Windows searches in 
order. c:\windows\system32 should remain the first item in the list. This is a 
classic mistake of installers.

--
components: Installation
messages: 368312
nosy: Roman
priority: normal
severity: normal
status: open
title: path environment variable not created correctly
type: behavior
versions: Python 3.8

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

[issue39395] The os module should unset() environment variable at exit

2020-01-24 Thread Eric Snow



Eric Snow  added the comment:

FTR, #39376 is related (avoid the process-global env vars in the first place).

--
nosy: +eric.snow

___
Python tracker 

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

[issue39395] The os module should unset() environment variable at exit

2020-01-24 Thread STINNER Victor



STINNER Victor  added the comment:

On non-Windows platforms, Python now requires setenv() and unsetenv()
functions to build.

setenv() and unsetenv() should be available on all platforms supported by 
Python. If it's not the case, someone can maintain a downstream patch which is 
a revert of commit b8d1262e8afe7b907b4a394a191739571092acdb.

If someone asks to support a platform which doesn't provide setenv() and 
unsetenv(), we can revisit the idea of unsetting variables set by Python at 
exit, to workaround putenv() issue: something like my (abandonned) PR 18078.

--

___
Python tracker 

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

[issue39395] The os module should unset() environment variable at exit

2020-01-24 Thread STINNER Victor



Change by STINNER Victor :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue39395] The os module should unset() environment variable at exit

2020-01-24 Thread STINNER Victor



STINNER Victor  added the comment:


New changeset b8d1262e8afe7b907b4a394a191739571092acdb by Victor Stinner in 
branch 'master':
bpo-39395: putenv() and unsetenv() always available (GH-18135)
https://github.com/python/cpython/commit/b8d1262e8afe7b907b4a394a191739571092acdb


--

___
Python tracker 

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

[issue39395] The os module should unset() environment variable at exit



STINNER Victor  added the comment:

Clearing environment variables at exit has a drawback: it changes the behavior 
in code executed after Python finalization (Py_FinalizeEx() call). It may cause 
regression.

So I proposed PR 18135 to fix this issue differently: on non-Windows platforms, 
Python now requires setenv() to build. This PR has no backward compatibility 
issue: it doesn't unset environment variables at exit.

--

___
Python tracker 

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

[issue39395] The os module should unset() environment variable at exit



Change by STINNER Victor :


--
pull_requests: +17521
pull_request: https://github.com/python/cpython/pull/18135

___
Python tracker 

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

[issue39395] The os module should unset() environment variable at exit



STINNER Victor  added the comment:

I closed bpo-39406: os.putenv() is now implemented with setenv() if available. 
The internal putenv_dict is no longer used on Windows and if setenv() is 
available.

Now only non-Windows platforms without setenv() are affected by this issue.

--

___
Python tracker 

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

[issue39395] The os module should unset() environment variable at exit



STINNER Victor  added the comment:

> Issue39406 is a new feature. In any case we should fix potential crash in 
> older Python versions.

Python 3.8 and older are not affected by this issue since they never destroy 
the posix_putenv_garbage dictionary: memory is never released.

--

___
Python tracker 

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

[issue39395] The os module should unset() environment variable at exit



Change by STINNER Victor :


--
versions:  -Python 3.7, Python 3.8

___
Python tracker 

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

[issue39395] The os module should unset() environment variable at exit

2020-01-22 Thread Serhiy Storchaka



Serhiy Storchaka  added the comment:

Issue39406 is a new feature. In any case we should fix potential crash in older 
Python versions.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue39395] The os module should unset() environment variable at exit

2020-01-22 Thread Serhiy Storchaka



Change by Serhiy Storchaka :


--
type:  -> crash
versions: +Python 3.7, Python 3.8

___
Python tracker 

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

[issue39395] The os module should unset() environment variable at exit

2020-01-21 Thread STINNER Victor



STINNER Victor  added the comment:

I proposed bpo-39406 which avoids to have to clear environment variables set by 
Python at exit on platforms providing setenv().

--

___
Python tracker 

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

[issue39395] The os module should unset() environment variable at exit

2020-01-21 Thread STINNER Victor



STINNER Victor  added the comment:

Fedora downstream issue, crash in the "elements" package: 
https://bugzilla.redhat.com/show_bug.cgi?id=1791761

--

___
Python tracker 

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

[issue39395] The os module should unset() environment variable at exit

2020-01-20 Thread STINNER Victor



Change by STINNER Victor :


--
keywords: +patch
pull_requests: +17471
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18078

___
Python tracker 

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

[issue39395] The os module should unset() environment variable at exit

2020-01-20 Thread STINNER Victor



New submission from STINNER Victor :

os.environ[key] = value has to keep internally the string "key=value\0" after 
putenv("key=value\0") has been called, since the glibc doesn't copy the string. 
Python has to manage the string memory.

Internally, the posix module uses a "posix_putenv_garbage" dictionary mapping 
key (bytes) to value (bytes). Values are "key=value\0" strings.

The bpo-35381 issue converted the os ("posix" in practice) module PEP 384: 
"Remove all static state from posixmodule": commit 
b3966639d28313809774ca3859a347b9007be8d2. The _posix_clear() function is now 
called by _PyImport_Cleanup().

Problem: the glibc is not aware that Python is exiting and that the memory of 
the environment variable has been released. Next access to environment 
variables ("environ" C variable, putenv, setenv, unsetenv, ...) can crash. 
Sometimes, it doesn't crash even if the memory has been released, because 
free() does not always dig immediately holes in the heap memory (the complex 
problelm of memory fragmentation).

The posix module should notify the glibc that the memory will be released 
before releasing the memory, to avoid keeping dangling pointers in the 
"environ" C variable.

The following crash in the Elements module is an example of crash introduced by 
commit b3966639d28313809774ca3859a347b9007be8d2 which introduced this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1791761

--
components: Interpreter Core
messages: 360309
nosy: vstinner
priority: normal
severity: normal
status: open
title: The os module should unset() environment variable at exit
versions: Python 3.9

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

[issue39122] Environment variable PYTHONUSERBASE is not set during customized Python Installation

2019-12-23 Thread Sara Martínez Giner


New submission from Sara Martínez Giner :

Environment variable PYTHONUSERBASE is not set during customized Python 
Installation.

Python installer 3.7.6(x64) / Windows 10

Check 1: Customize the installation to install Python in C:\Python37 for all 
users. 
  Result: Access Denied using pip

Check 2: Check 1: Customize the installation to install Python in C:\Program 
Files\Python37 for all users (default). 
  Result: pip works, but error appears trying to install anything with pip. For 
example:
>>pip install virtualenv
 WARNING: The script virtualenv.exe is intalled in 
'C:\Users\XXX\AppData\Roaming\Python\Python37\Scripts' which is not on path

By default APPDATA matches with C:\Users\XXX\AppData\Roaming
and PYHTONUSERBASE is empty

-

I've found the path constructor in \Python37\Lib\site.py (_getuserbase)

So I try the following steps:
- Create folder with full control in C:\ (C:\Python)
- Set environment variable PYTHONUSERBASE=C:\Python
- Install Python for all users in C:\Python\Python37

That works for me.

--
components: Windows
messages: 358808
nosy: paul.moore, sarmar11, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Environment variable PYTHONUSERBASE is not set during customized Python 
Installation
type: security
versions: Python 3.7

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

[issue35328] Set a environment variable for venv prompt

2019-10-31 Thread Vinay Sajip



Change by Vinay Sajip :


--
versions: +Python 3.9 -Python 3.8

___
Python tracker 

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

[issue34709] Suggestion: make getpass.getuser() also look at SUDO_USER environment variable

2019-09-12 Thread Gregory P. Smith



Gregory P. Smith  added the comment:

Adding a check for SUDO_USER would break existing uses as it would no longer be 
reporting the user the process is running as.

--
assignee:  -> gregory.p.smith
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed
title: Suggestion: make getuser.getpass() also look at SUDO_USER environment 
variable -> Suggestion: make getpass.getuser() also look at SUDO_USER 
environment variable

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

[issue34709] Suggestion: make getuser.getpass() also look at SUDO_USER environment variable

2019-09-11 Thread Zachary Ware



Zachary Ware  added the comment:

I agree with Steven in that I'm not quite sure this is a good change, but I 
also see that it would be useful in some cases.  Perhaps either a 
`check_sudo_user=False` keyword-only parameter, or a `vars_to_check=()` parameter would be better?

Adding Gregory P. Smith as the last person to have added their name to 
getpass.py :)

--
nosy: +gregory.p.smith, zach.ware

___
Python tracker 

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

[issue37680] distutils appends LDFLAGS environment variable before object file names

2019-07-25 Thread Batuhan



Change by Batuhan :


--
nosy: +BTaskaya

___
Python tracker 

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

[issue37680] distutils appends LDFLAGS environment variable before object file names

2019-07-25 Thread Omer Ozarslan



Omer Ozarslan  added the comment:

Attached a better example. Run make 
(static_example|shared_example|working_shared_example).

--
Added file: https://bugs.python.org/file48506/python-issue-2.tar.gz

___
Python tracker 

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

[issue37680] distutils appends LDFLAGS environment variable before object file names

2019-07-25 Thread Omer Ozarslan



New submission from Omer Ozarslan :

distutils honors some environment variables during extension build, however, 
LDFLAGS is appended before declaring object files. This causes undefined 
symbols during importing an extension built with some static libraries using 
this environment variable. This is not apparent in the case of dynamic linking, 
but it can be observed by adding "-Wl,--as-needed" flag, since this will link 
libraries only if they are required. Therefore, it will be necessary to add 
them after object files in case of dynamic linking as well in that case.

I believe this part is the culprit as it appends LDFLAGS environment variable 
to executable name: 
https://github.com/python/cpython/blob/c994c8f/Lib/distutils/sysconfig.py#L211-L235

I attached a minimal example (it requires cython, which relies on distutils for 
compilation).

It would be nice if LDFLAGS is appended after object files, or a new 
environment variable (e.g. LDLIBS) is introduced to distutils to be appended 
after object files.

--
components: Distutils
files: python-issue.tar.gz
messages: 348436
nosy: dstufft, eric.araujo, ozars
priority: normal
severity: normal
status: open
title: distutils appends LDFLAGS environment variable before object file names
Added file: https://bugs.python.org/file48505/python-issue.tar.gz

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

[issue37411] testEnviron (test.test_wsgiref.HandlerTests) fails when environment variable X is set

2019-07-03 Thread STINNER Victor



Change by STINNER Victor :


--
pull_requests:  -14383

___
Python tracker 

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

[issue37411] testEnviron (test.test_wsgiref.HandlerTests) fails when environment variable X is set

2019-07-02 Thread hai shi



Change by hai shi :


--
pull_requests: +14383
pull_request: https://github.com/python/cpython/pull/14453

___
Python tracker 

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

[issue37411] testEnviron (test.test_wsgiref.HandlerTests) fails when environment variable X is set

2019-07-02 Thread STINNER Victor



Change by STINNER Victor :


--
pull_requests:  -14375

___
Python tracker 

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

[issue37411] testEnviron (test.test_wsgiref.HandlerTests) fails when environment variable X is set

2019-07-02 Thread hai shi



Change by hai shi :


--
pull_requests: +14375
pull_request: https://github.com/python/cpython/pull/14453

___
Python tracker 

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

[issue37411] testEnviron (test.test_wsgiref.HandlerTests) fails when environment variable X is set

2019-06-28 Thread Karthikeyan Singaravelan



Change by Karthikeyan Singaravelan :


--
pull_requests:  -14269

___
Python tracker 

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

[issue37411] testEnviron (test.test_wsgiref.HandlerTests) fails when environment variable X is set

2019-06-28 Thread hai shi



Change by hai shi :


--
pull_requests: +14269
pull_request: https://github.com/python/cpython/pull/14453

___
Python tracker 

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

[issue37411] testEnviron (test.test_wsgiref.HandlerTests) fails when environment variable X is set



STINNER Victor  added the comment:

Ok, the bug is now fixed in 2.7, 3.7, 3.8 and master branches. Thanks Miro for 
the report. I also enhanced the test to test all variables of handler.environ.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue37411] testEnviron (test.test_wsgiref.HandlerTests) fails when environment variable X is set



STINNER Victor  added the comment:


New changeset dfa9499ccbc14a4227ca8d0c1728e2beacbb45c6 by Victor Stinner (Miss 
Islington (bot)) in branch '2.7':
[2.7] bpo-37411: Rewrite test_wsgiref.testEnviron() (GH-14394) (GH-14404)
https://github.com/python/cpython/commit/dfa9499ccbc14a4227ca8d0c1728e2beacbb45c6


--

___
Python tracker 

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

[issue37411] testEnviron (test.test_wsgiref.HandlerTests) fails when environment variable X is set



miss-islington  added the comment:


New changeset bdbd5e895ddf9aefcb79cdc52341f0697ad6aea0 by Miss Islington (bot) 
in branch '3.8':
bpo-37411: Rewrite test_wsgiref.testEnviron() (GH-14394)
https://github.com/python/cpython/commit/bdbd5e895ddf9aefcb79cdc52341f0697ad6aea0


--

___
Python tracker 

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

[issue37411] testEnviron (test.test_wsgiref.HandlerTests) fails when environment variable X is set



miss-islington  added the comment:


New changeset 814c7aefc2b8e9892bce3d59c0ab39563d658aa2 by Miss Islington (bot) 
in branch '3.7':
bpo-37411: Rewrite test_wsgiref.testEnviron() (GH-14394)
https://github.com/python/cpython/commit/814c7aefc2b8e9892bce3d59c0ab39563d658aa2


--
nosy: +miss-islington

___
Python tracker 

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

[issue37411] testEnviron (test.test_wsgiref.HandlerTests) fails when environment variable X is set



Change by miss-islington :


--
pull_requests: +14216
pull_request: https://github.com/python/cpython/pull/14404

___
Python tracker 

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

[issue37411] testEnviron (test.test_wsgiref.HandlerTests) fails when environment variable X is set



Change by miss-islington :


--
pull_requests: +14215
pull_request: https://github.com/python/cpython/pull/14403

___
Python tracker 

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

[issue37411] testEnviron (test.test_wsgiref.HandlerTests) fails when environment variable X is set



Change by miss-islington :


--
pull_requests: +14214
pull_request: https://github.com/python/cpython/pull/14402

___
Python tracker 

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

[issue37411] testEnviron (test.test_wsgiref.HandlerTests) fails when environment variable X is set



STINNER Victor  added the comment:


New changeset 5150d327924959639215ed0a78feffc0d88258da by Victor Stinner in 
branch 'master':
bpo-37411: Rewrite test_wsgiref.testEnviron() (GH-14394)
https://github.com/python/cpython/commit/5150d327924959639215ed0a78feffc0d88258da


--

___
Python tracker 

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

[issue37411] testEnviron (test.test_wsgiref.HandlerTests) fails when environment variable X is set



Change by STINNER Victor :


--
versions: +Python 2.7 -Python 3.6

___
Python tracker 

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

[issue37411] testEnviron (test.test_wsgiref.HandlerTests) fails when environment variable X is set



STINNER Victor  added the comment:

I wrote PR 14394 to fix the test.

--

___
Python tracker 

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

[issue37411] testEnviron (test.test_wsgiref.HandlerTests) fails when environment variable X is set