[issue46622] Support decorating a coroutine with functools.cached_property
New submission from Tzu-ping Chung : Currently, decorating a coroutine with cached_property would cache the coroutine itself. But this is not useful in any way since a coroutine cannot be awaited multiple times. Running this code: import asyncio import functools class A: @functools.cached_property async def hello(self): return 'yo' async def main(): a = A() print(await a.hello) print(await a.hello) asyncio.run(main()) produces: yo Traceback (most recent call last): File "t.py", line 15, in asyncio.run(main()) File "/lib/python3.10/asyncio/runners.py", line 44, in run return loop.run_until_complete(main) File "/lib/python3.10/asyncio/base_events.py", line 641, in run_until_complete return future.result() File "t.py", line 12, in main print(await a.hello) RuntimeError: cannot reuse already awaited coroutine The third-party cached_property package, on the other hand, detects a coroutine and caches its result instead. I feel this is a more useful behaviour. https://github.com/pydanny/cached-property/issues/85 -- components: Library (Lib) messages: 412422 nosy: uranusjr priority: normal severity: normal status: open title: Support decorating a coroutine with functools.cached_property type: enhancement versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46622] Support decorating a coroutine with functools.cached_property
Tzu-ping Chung added the comment: > should not use asyncio directly but 'async def', 'await', and > `inspect.iscoroutine()` / `inspect.iscoroutinefunction()` instead. Hmm, this introduces some difficulties. Since a coroutine can only be awaited once, a new coroutine needs to be returned (that simply return the result when awaited) each time __get__ is called. But this means we need a way to somehow get the result in __get__. If there’s a separate `cached_property_async` it’s possible to make __get__ a coroutine function, but personally I’d prefer the interface to match the PyPI cached_property. -- ___ Python tracker <https://bugs.python.org/issue46622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46738] Allow http.server to emit HTML 5
New submission from Tzu-ping Chung : Currently, a directory listing page emitted by http.parser uses the HTML 4.01 doctype. While this is perfectly fine for most uses, the server tool is sometimes used for things that require another doctype; PEP 503[1], for example, requires an HTML 5 document. >From what I can tell, http.parser is already emitting a valid HTML 5 page, so >it should be possible to simply change the doctype declaration. Or, if >backward compatibility is paramount, this could live behind a --doctype flag >as well. If we go the latter route, more doctypes (e.g. XHTML) could >potentially be supported as well with minimal modification. [1]: https://www.python.org/dev/peps/pep-0503/ -- components: Library (Lib) messages: 413179 nosy: uranusjr priority: normal severity: normal status: open title: Allow http.server to emit HTML 5 ___ Python tracker <https://bugs.python.org/issue46738> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46622] Support decorating a coroutine with functools.cached_property
Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +29476 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31314 ___ Python tracker <https://bugs.python.org/issue46622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46622] Support decorating a coroutine with functools.cached_property
Tzu-ping Chung added the comment: I agree that `print(await a.hello)` does look awkward, although I know some would disagree. (Context: I submitted this BPO after a colleague of mine at $WORK pointed out the behavioural difference between `functools` and `cached_property to me.) Personally I’d feel this more natural: class Foo: @functools.cache async def go(self): print(1) async def main(): foo = Foo() await foo.go() await foo.go() Although now I just noticed this actually does not work either. Perhaps we should fix this instead and add a line in the documentation under cached_property to point people to the correct path? -- ___ Python tracker <https://bugs.python.org/issue46622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46622] Support decorating a coroutine with functools.cached_property
Change by Tzu-ping Chung : -- pull_requests: +29625 pull_request: https://github.com/python/cpython/pull/31495 ___ Python tracker <https://bugs.python.org/issue46622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46622] Add an async variant of lru_cache for coroutines.
Tzu-ping Chung added the comment: Another thing to point out is that existing third-party solutions (both alru_cache and cached_property) only work for asyncio, and the stdlib version (as implemented now) will be an improvement. And if the position is that the improvements should only be submitted to third-party solutions---I would need to disagree since both lru_cache and cached_property have third-party solutions predating their stdlib implementations, and it is double-standard IMO if an async solution is kept out while the sync version is kept in. -- ___ Python tracker <https://bugs.python.org/issue46622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43455] pathlib mistakenly assumes os.getcwd() is a resolved path in Windows
Tzu-ping Chung added the comment: I believe this has been fixed in https://github.com/python/cpython/pull/25264 -- ___ Python tracker <https://bugs.python.org/issue43455> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38671] pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not existent
New submission from Tzu-ping Chung :
Originally from https://discuss.python.org/t/pathlib-absolute-vs-resolve/2573/4
>>> import pathlib
>>> pathlib.Path().resolve()
WindowsPath('C:/temp')
>>> list(pathlib.Path().iterdir())
[]
>>> pathlib.Path('foo').resolve()
WindowsPath('foo')
>>> pathlib.Path('bar').touch()
>>> pathlib.Path('bar').resolve()
WindowsPath('C:/temp/bar')
--
messages: 355892
nosy: uranusjr
priority: normal
severity: normal
status: open
title: pathlib.Path.resolve(strict=False) returns relative path on Windows if
the entry does not existent
versions: Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue38671>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38671] pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not exist
Change by Tzu-ping Chung : -- title: pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not existent -> pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not exist ___ Python tracker <https://bugs.python.org/issue38671> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43312] Interface to select preferred "user" or "home" sysconfig scheme for an environment
Tzu-ping Chung added the comment:
Gentle ping again :) I’ve also created a PR for this.
> The Debian/Ubuntu packages have a local patch for distutils/setuptools
> introducing an --install-layout option. Maybe have the same for pip?
Pip already has a similar mechanism. The default layout is `prefix` and you can
change the installation prefix with `--prefix`; `home` and `user` layouts can
be specified with `--home={base}` and `--user`.
> So the problem to solve is
>
> - let a "sudo pip install" fail by default on the real system
> - let the same install succeed in a docker environment, or any other "image".
These need to be done in pip, so we’ll have a separate discussion on them
elsewhere.
> - behave transparently on venv and virtualenv installations.
This is what this issue tries to address. A distribution can overwrite
`sysconfig.get_default_scheme()` and `sysconfig.get_preferred_scheme(variant)`
to return the correct scheme based on whether the current Python is in a
virtual environment (by detecting `sys.prefix` and `sys.base_prefix`, I think).
When in a virtual environment, it can return the same scheme as the upstream.
Outside of a virtual environment, it can do whatever the platform sees fit, and
pip (or whatever calls sysconfig) will install things into wherever it’s told
to by the two functions.
--
___
Python tracker
<https://bugs.python.org/issue43312>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43948] sysconfig’s osx_framework_user puts headers in different locations from distutils
New submission from Tzu-ping Chung :
When built in framework mode on macOS, distutils puts user-site headers under
`{userbase}/include/python{py_version_short}{abiflags}`:
>>> import sys
>>> print(sys.platform, sys._framework)
darwin Python
>>> from distutils.dist import Distribution
>>> c = Distribution().get_command_obj('install')
>>> c.user = True
>>> c.finalize_options()
>>> print(c.install_headers)
/Users/uranusjr/Library/Python/3.9/include/python3.9/UNKNOWN
But sysconfig lacks the `pythonX.Y` part:
>>> import sysconfig
>>> print(sysconfig.get_path('include', scheme='osx_framework_user'))
/Users/uranusjr/Library/Python/3.9/include
This is inconsistent to all other schemes, such as `posix_user` (tested on the
`python:3.9-slim` OCI image):
>>> import sys
>>> print(sys.platform, sys._framework)
linux
>>> from distutils.dist import Distribution
>>> c = Distribution().get_command_obj('install')
>>> c.user = True
>>> c.finalize_options()
>>> print(c.install_headers)
/root/.local/include/python3.9/UNKNOWN
>>> import sysconfig
>>> print(sysconfig.get_path('include', scheme='posix_user'))
/root/.local/include/python3.9
Note that the paths on `posix_user` only differs by one component (`UNKNOWN`,
which is the distribution name), but `osx_framework_user` differs by two.
--
components: Library (Lib)
messages: 392037
nosy: uranusjr
priority: normal
severity: normal
status: open
title: sysconfig’s osx_framework_user puts headers in different locations from
distutils
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python
3.9
___
Python tracker
<https://bugs.python.org/issue43948>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43948] sysconfig’s osx_framework_user puts headers in different locations from distutils
Change by Tzu-ping Chung : -- components: +macOS nosy: +ned.deily, ronaldoussoren type: -> behavior ___ Python tracker <https://bugs.python.org/issue43948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43948] sysconfig's osx_framework_user puts headers in different locations from distutils
Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +25641 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27093 ___ Python tracker <https://bugs.python.org/issue43948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43948] sysconfig's osx_framework_user puts headers in different locations from distutils
Tzu-ping Chung added the comment: Personally I am not very surprised. The scenario (installing a package to the user scheme of a macOS Framework build) is quite obscure on its own, and AFAIK no third-party package installers is currently using sysconfig. Both pip and setuptools use distutils, and everything else uses one of them to perform the installation indirectly. -- ___ Python tracker <https://bugs.python.org/issue43948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44851] Update bundled pip to 21.2.3 and setuptools to 57.4.0
New submission from Tzu-ping Chung : PR coming soon -- components: Distutils messages: 399072 nosy: dstufft, eric.araujo, uranusjr priority: normal severity: normal status: open title: Update bundled pip to 21.2.3 and setuptools to 57.4.0 versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue44851> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44851] Update bundled pip to 21.2.3 and setuptools to 57.4.0
Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +26119 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27625 ___ Python tracker <https://bugs.python.org/issue44851> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44851] Update bundled pip to 21.2.3 and setuptools to 57.4.0
Tzu-ping Chung added the comment: I was not sure what the policy is and went with the two that accepts new features hoping someone would tell me I’m wrong :p So yeah, 3.9 should be added. -- versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue44851> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44858] sysconfig's posix_user scheme has different platlib value to distutils'
Change by Tzu-ping Chung : -- nosy: uranusjr priority: normal severity: normal status: open title: sysconfig's posix_user scheme has different platlib value to distutils' ___ Python tracker <https://bugs.python.org/issue44858> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44858] sysconfig's posix_user scheme has different platlib value to distutils'
New submission from Tzu-ping Chung : Submitted by accident; please ignore this, sorry for the noise. (I am going to submit this issue properly.) -- resolution: -> duplicate ___ Python tracker <https://bugs.python.org/issue44858> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44860] sysconfig's posix_user scheme has different platlib value to distutils's unix_user
New submission from Tzu-ping Chung :
On POSIX, the user scheme has a different 'platlib' location between distutils
and sysconfig, dispite the comment claiming they should be the same.
This can be reproduced on Fedora 34's stock Python 3.9:
$ docker run -it --rm -h=p fedora:34 bash
...
[root@p /]# yum install python3 -y
...
[root@p /]# type python3
python3 is hashed (/usr/bin/python3)
[root@p /]# python3 -V
Python 3.9.6
[root@p /]# python3.9 -q
>>> from distutils.command.install import install
>>> from distutils.dist import Distribution
>>> c = install(Distribution())
>>> c.user = True
>>> c.finalize_options()
>>> c.install_platlib
'/root/.local/lib/python3.9/site-packages'
>>> import sysconfig
>>> sysconfig.get_path('platlib', 'posix_user')
'/root/.local/lib64/python3.9/site-packages'
This issue was introduced by the sys.platlibdir value, and its usage in
distutils and sysconfig. sysconfig sets posix_user's lib paths like this:
'purelib': '{userbase}/lib/python{py_version_short}/site-packages',
'platlib': '{userbase}/{platlibdir}/python{py_version_short}/site-packages',
https://github.com/python/cpython/blob/a40675c659cd8c0699f85ee9ac31660f93f8c2f5/Lib/sysconfig.py#L100-L108
But distutils naively sets both to the same value that does not account for
platlibdir:
'purelib': '$usersite',
'platlib': '$usersite',
https://github.com/python/cpython/blob/a40675c659cd8c0699f85ee9ac31660f93f8c2f5/Lib/distutils/command/install.py#L68-L87
causing the mismatch, dispite the comment above clearly indicating the values
are supposed to be the same.
This was introduced in bpo-1294959 which changed the platlib template to depend
on sys.platlibdir, so a mismatch happens when the value of sys.platlibdir is
not 'lib'.
(Adding frenzy and vstinner to the nosy list since you introduced the comment
in distutils and the sys.platlibdir change, respectively.)
--
components: Distutils
messages: 399186
nosy: dstufft, eric.araujo, frenzy, uranusjr, vstinner
priority: normal
severity: normal
status: open
title: sysconfig's posix_user scheme has different platlib value to distutils's
unix_user
versions: Python 3.10, Python 3.11, Python 3.9
___
Python tracker
<https://bugs.python.org/issue44860>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44860] sysconfig's posix_user scheme has different platlib value to distutils's unix_user
Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +26149 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27655 ___ Python tracker <https://bugs.python.org/issue44860> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44858] sysconfig's posix_user scheme has different platlib value to distutils'
Change by Tzu-ping Chung : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44858> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38671] pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not exist
Tzu-ping Chung added the comment: I think this can be closed now that the PRs are all merged? -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38671> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44851] Update bundled pip to 21.2.3 and setuptools to 57.4.0
Change by Tzu-ping Chung : -- pull_requests: +26168 pull_request: https://github.com/python/cpython/pull/27658 ___ Python tracker <https://bugs.python.org/issue44851> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44860] sysconfig's posix_user scheme has different platlib value to distutils's unix_user
Tzu-ping Chung added the comment: > I'm not sure if it should be used to install libraries in $HOME/.local/lib64 > rather than $HOME/.local/lib. Previously, Fedora already used > $HOME/.local/lib and $HOME/.local/lib64 is not in the sys.path. This was also briefly discussed in bpo-1294959, but did not go through since “changing posix_user should have no impact on end users”. > Does the site module add $HOME/.local/lib64 to sys.path if it exists? It does not, only lib is checked right now. https://github.com/python/cpython/blob/c7ea1e3dcea6fbc9842463ce2b785b43501b1eaa/Lib/site.py#L288-L298 There are two possible solutions from what I can tell. We could just make posix_user match posix_prefix and always respect sys.platlibdir. This could be confusing to existing Python 3.9 users however since many of them already pip-installed things into ~/.local/lib and this would make their user-site packages split in two locations. The other would be to restore the pre-3.9 behaviour in sysconfig to use lib instead of depending on sys.platlibdir. I don’t know who uses sysconfig right now and can’t say what would break, but for pip this would be less disruptive since it currently installs things into ~/.local/ib (provided by distutils). -- ___ Python tracker <https://bugs.python.org/issue44860> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44860] sysconfig's posix_user scheme has different platlib value to distutils's unix_user
Tzu-ping Chung added the comment: I’ve updated the linked PR to change sysconfig instead to not use sys.platlibdir when generating the posix_user scheme. This means posix_user would behave the same in 3.9+ as 3.8 and prior. -- ___ Python tracker <https://bugs.python.org/issue44860> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45035] sysconfig's posix_home scheme has different platlib value to distutils's unix_home
New submission from Tzu-ping Chung :
This is similar to bpo-44860, but in the other direction:
$ docker run -it --rm -h=p fedora:34 bash
...
[root@p /]# yum install python3 -y
...
[root@p /]# type python3
python3 is hashed (/usr/bin/python3)
[root@p /]# python3 -V
Python 3.9.6
[root@p /]# python3.9 -q
>>> from distutils.command.install import install
>>> from distutils.dist import Distribution
>>> c = install(Distribution())
>>> c.home = '/foo'
>>> c.finalize_options()
>>> c.install_platlib
'/foo/lib64/python'
>>> import sysconfig
>>> sysconfig.get_path('platlib', 'posix_home', vars={'home': '/root'})
'/foo/lib/python'
sysconfig’s scheme should use `{platlib}` instead of hardcoding 'lib'.
Note that on Python 3.10+ the platlib values from distutils and sysconfig do
match (since the distutils scheme is automatically generated from sysconfig),
but the issue remains; sysconfig’s scheme should likely include `{platlib}`
(adding Victor and Miro to confirm this).
--
components: Distutils, Library (Lib)
messages: 400463
nosy: dstufft, eric.araujo, hroncok, uranusjr, vstinner
priority: normal
severity: normal
status: open
title: sysconfig's posix_home scheme has different platlib value to distutils's
unix_home
versions: Python 3.10, Python 3.11, Python 3.9
___
Python tracker
<https://bugs.python.org/issue45035>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45035] sysconfig's posix_home scheme has different platlib value to distutils's unix_home
Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +26454 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28011 ___ Python tracker <https://bugs.python.org/issue45035> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43112] SOABI on Linux does not distinguish between GNU libc and musl libc
Tzu-ping Chung added the comment: Can anyone problem examples that it’s not an option to continue using the “technically incorrect” `-gnu` suffix on 3.9 and 3.10? From what I understand, te suffix technically works (as in the module will load correctly), it just fails to distinguish the ABI in the name. If that’s correct, I feel “being able to distinguish between modules built against musl and glibc” should be a feature request and only implemented for 3.11+, while versions 3.10 and prior continue to use `-gnu`. This will also provide a simpler way out of the wheel compatibility problem; projects can distribute different wheels for 3.10 (or lower) and 3.11 (or higher), while the former wheel continues to contain `-gnu`-suffixed modules, and only contain `-musl`-suffixed ones in the latter. -- nosy: +uranusjr ___ Python tracker <https://bugs.python.org/issue43112> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45992] distutils paths are scattered between PythonXY and PythonXY-32 on WoW64
New submission from Tzu-ping Chung :
Should be reproducible with a 32-bit Python 3.10 running on 64-bit Windows.
$ py -3.10-32 -q
>>> from distutils.command.install import install
:1: DeprecationWarning: The distutils package is deprecated and
slated for removal in Python 3.12. Use setuptools or check PEP 632 for
potential alternatives
>>> from distutils.dist import Distribution
>>> c = install(Distribution())
>>> c.user = 1
>>> c.finalize_options()
>>> for k in ('purelib', 'platlib', 'headers', 'scripts', 'data'):
... print(f'{k}\t{getattr(c, "install_" + k)}')
...
purelib C:\Users\uranusjr\AppData\Roaming\Python\Python310-32\site-packages
platlib C:\Users\uranusjr\AppData\Roaming\Python\Python310-32\site-packages
headers C:\Users\uranusjr\AppData\Roaming\Python\Python310\Include\UNKNOWN
scripts C:\Users\uranusjr\AppData\Roaming\Python\Python310\Scripts
dataC:\Users\uranusjr\AppData\Roaming\Python
This is different from sysconfig, where all files are placed in the *-32 suffix:
>>> import sysconfig
>>> for k in ('purelib', 'platlib', 'include', 'scripts', 'data'):
... print(f'{k}\t{paths[k]}')
...
purelib C:\Users\uranusjr\AppData\Roaming\Python\Python310-32\site-packages
platlib C:\Users\uranusjr\AppData\Roaming\Python\Python310-32\site-packages
include C:\Users\uranusjr\AppData\Roaming\Python\Python310-32\Include
scripts C:\Users\uranusjr\AppData\Roaming\Python\Python310-32\Scripts
dataC:\Users\uranusjr\AppData\Roaming\Python
And also different from Python 3.9 (and prior), which does not use the *-32
prefix:
$ py -3.9-32 -q
>>> from distutils.command.install import install
>>> from distutils.dist import Distribution
>>> c = install(Distribution())
>>> c.user = 1
>>> c.finalize_options()
>>> for k in ('purelib', 'platlib', 'headers', 'scripts', 'data'):
... print(f'{k}\t{getattr(c, "install_" + k)}')
...
purelib C:\Users\uranusjr\AppData\Roaming\Python\Python39\site-packages
platlib C:\Users\uranusjr\AppData\Roaming\Python\Python39\site-packages
headers C:\Users\uranusjr\AppData\Roaming\Python\Python39\Include\UNKNOWN
scripts C:\Users\uranusjr\AppData\Roaming\Python\Python39\Scripts
dataC:\Users\uranusjr\AppData\Roaming\Python
It’s of course not a problem to change the prefix and add the *-32 suffix on
3.10 (since the only thing that’s important is to have a consistent prefix for
a given version), but the change should likely need to be applied consistently.
I think we should fix distutils to match sysconfig?
--
components: Distutils, Windows
messages: 407769
nosy: dstufft, eric.araujo, paul.moore, steve.dower, tim.golden, uranusjr,
zach.ware
priority: normal
severity: normal
status: open
title: distutils paths are scattered between PythonXY and PythonXY-32 on WoW64
versions: Python 3.10, Python 3.11
___
Python tracker
<https://bugs.python.org/issue45992>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45992] distutils paths are scattered between PythonXY and PythonXY-32 on WoW64
Tzu-ping Chung added the comment: They are old, but so are purelib and platlib, which were changed regardless. The problem is that distutils’s values are now half wrong and half right, neither matching pre-3.10 behaviour, nor matching post-3.10 sysconfig behaviour. -- ___ Python tracker <https://bugs.python.org/issue45992> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23706] pathlib.Path.write_text should include a newline argument
Change by Tzu-ping Chung : -- nosy: +uranusjr ___ Python tracker <https://bugs.python.org/issue23706> ___ ___ 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
New submission from Tzu-ping Chung : To reproduce: > py -m venv fooenv > fooenv\Scripts\activate.bat (fooenv) > python -c "import sys; print(sys.executable)" % This is correct C:\Users\uranusjr\Downloads\venvtest\Scripts\python.exe (fooenv) > python -q >>> import subprocess >>> subprocess.check_output(['python', '-c', 'import sys; >>> print(sys.executable)']) b'C:\\Users\\uranusjr\\AppData\\Local\\Programs\\Python\\Python37\\python.exe\r\n' The output shows the base interpreter, not the interpreter in venv. Not sure whether this is a venv or subprocess problem. -- components: Library (Lib), Windows messages: 357392 nosy: paul.moore, steve.dower, tim.golden, uranusjr, zach.ware priority: normal severity: normal status: open title: venv python reports wrong sys.executable in a subprocess on Windows versions: Python 3.7, Python 3.8 ___ 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
[issue38905] venv python reports wrong sys.executable in a subprocess on Windows
Tzu-ping Chung added the comment: Linux works correctly (Ubuntu with self-compiled Python 3.7.5) $ python3.7 -m venv fooenv $ . fooenv/bin/activate (fooenv) $ python -c "import sys; print(sys.executable)" /home/uranusjr/fooenv/bin/python (fooenv) $ python -q >>> import subprocess >>> subprocess.check_output(['python', '-c', 'import sys; >>> print(sys.executable)']) b'/home/uranusjr/fooenv/bin/python\n' -- ___ 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
[issue38905] venv python reports wrong sys.executable in a subprocess on Windows
Tzu-ping Chung added the comment: 3.6 works correctly on Windows: > py -3.6 -m venv test36 > test36\Scripts\activate.bat >>> import subprocess >>> print(subprocess.check_output(['python', '-c', 'import sys; >>> print(sys.executable)'])) b'C:\\Users\\uranusjr\\Downloads\\test36\\Scripts\\python.exe\r\n' So it seems the problem is introduced sometime after. -- ___ 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
[issue38905] venv python reports wrong sys.executable in a subprocess on Windows
Tzu-ping Chung added the comment: > If you don't use activate.bat, but just run the venv's python directly, what > do you see? I get: > What shell are you using? Above is with cmd.exe. I get the same result as activating (i.e. shows the base interpeter). All results in cmd.exe as well. > If you "echo %PATH%" after activate.bat, what do you see? > Before running activate.bat, do you have a python.exe in your path? If so, is > it the one that subprocess is reporting? PATH is as expected, the venv’s Scripts directory at the front after activation. I (only) have a python.exe from Windows Store in PATH. The one reported by subprocess is not in PATH. I’ll try to find a clean machine (maybe a VM) and try whether I can replicate this. BTW the problematic versions for me was 3.7.5 and 3.8.0. -- ___ 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
[issue38905] venv python reports wrong sys.executable in a subprocess on Windows
Tzu-ping Chung added the comment: I tested the following in various versions (all 64-bit) in a VM. All installations are 64-bit per-user. > py -m venv testenv > testenv\Scripts\python.exe -c "import subprocess; > print(subprocess.check_output(['python', '-c', 'import sys; > print(sys.executable)']))" 3.8.0: Incorrect 3.7.5: Incorrect 3.7.4: Incorrect 3.7.3: Incorrect 3.7.2: Correct 3.6.8: Correct 3.7.1: Correct 3.7.0: Correct So the change seems to have happened somewhere between 3.7.2 and 3.7.3. Does this timeline line up with the venv redirector change? -- ___ 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
[issue38905] venv python reports wrong sys.executable in a subprocess on Windows
Tzu-ping Chung added the comment: To provide concrete context, the problem I’m facing is with how Flit resolves `flit install --python`: https://github.com/takluyver/flit/blob/7e65ffc7a540d76b96de0df473d3edff6f97c26c/flit/__init__.py#L18-L28 Generally the setup is to install Flit into a globally available location (let’s name it env A), so it’s usable for every project and environment. For a project foo you’d have a virtual environment (env X) that’s created from a base interpreter (env B, which may or may not be the same as env A). So the comment workflow would look like this: > pythonB -m venv project-env > project-env\Scripts\activate.bat (project-env) > pythonA -m flit install --python=pythonX This results in the following subprocess call: subprocess.check_output( ["pythonX", "-c", "import sys; print(sys.executable)"], universal_newlines=True, ).strip() And ideally (pre-3.7.2 Windows, or current POSIX behaviour) this would give you the absolute path to pythonX. But right now on Windows the result is pythonB. So if this is to be determined as acceptable behaviour, we’d need to come up with a suggestion how this code can be rewritten. `shutil.which` could be a direction, but still not enough since it’d break `flit install --python=py` because that’s give you the location of py.exe, not the actual interperter. What else? -- ___ 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
[issue38905] venv python reports wrong sys.executable in a subprocess on Windows
Tzu-ping Chung added the comment: >> not enough since it’d break `flit install --python=py` because that’s give >> you the location of py.exe, not the actual interperter. > This would be fine if you still run the process to get its sys.executable. But then I need two separate workflows based on what is passed in. For py.exe I need to run it and get sys.executable. But for python.exe I *cannot* use sys.executable because that’s the base interepeter, not the venv path I want. And `if Path(arg).stem == "py"` just seems like a bug waiting to happen. > Your specific example would never have worked, FWIW, as it always would have > picked up pythonA rather than the application one or the base one, unless you > were relying on python3/python3.7 not being available on Windows (which is no > longer true - they are included in the Store package now). It is an illustration. I am fully aware of Windows not having version-named python executables. Thanks for the reminder anyway. -- ___ 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
[issue38927] venv --upgrade_deps fails on Windows
New submission from Tzu-ping Chung : https://github.com/python/cpython/commit/4acdbf11b1fae1af24c47413a6caa593010d1b6f EnvBuilder.upgrade_dependencies() uses `pip.exe install -U` to upgrade pip, which fails on Windows with `[WinError 5] Access is denied`. -- components: Library (Lib), Windows messages: 357562 nosy: paul.moore, steve.dower, tim.golden, uranusjr, zach.ware priority: normal severity: normal status: open title: venv --upgrade_deps fails on Windows versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38927> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38928] EnvBuilder.upgrade_dependencies() does not exist on 3.8
New submission from Tzu-ping Chung : The documentation says it is new in 3.8, but in reality it is not present until 3.9. https://docs.python.org/3/library/venv.html#venv.EnvBuilder.upgrade_dependencies -- assignee: docs@python components: Documentation messages: 357563 nosy: docs@python, uranusjr priority: normal severity: normal status: open title: EnvBuilder.upgrade_dependencies() does not exist on 3.8 versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38927] venv --upgrade_deps fails on Windows
Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +16883 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17403 ___ Python tracker <https://bugs.python.org/issue38927> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38928] EnvBuilder.upgrade_dependencies() does not exist on 3.8
Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +16884 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17404 ___ Python tracker <https://bugs.python.org/issue38928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38928] EnvBuilder.upgrade_dependencies() does not exist on 3.8
Change by Tzu-ping Chung : -- pull_requests: +16890 pull_request: https://github.com/python/cpython/pull/17410 ___ Python tracker <https://bugs.python.org/issue38928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35003] Provide an option to venv to put files in a bin/ directory on Windows
Tzu-ping Chung added the comment: There are more differences than Scripts/bin, like Windows use Lib but POSIX uses lib/pythonX.Y. IMO it’s probably better to stick with platform conventions, especially since those can be discovered with sysconfig.get_paths(expand=False). I wonder whether it’d be a good idea to record what scheme was used to create the venv (in pyvenv.cfg). Any Python runtime can use that value in get_paths(scheme=..., expand=False) to know about the venv’s structure, even if the venv was created on another platform. This would be particularly useful to e.g. inspect a Windows-native venv in a WSL Python. -- nosy: +uranusjr ___ Python tracker <https://bugs.python.org/issue35003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35003] Provide an option to venv to put files in a bin/ directory on Windows
Tzu-ping Chung added the comment:
> Surely "on native Windows you run venv-path\Scripts\activate[.ps1], on POSIX
> you use source venv-path/bin/activate" isn't *that* hard for new users to
> grok [...]?
The if-Windows-X-else-Y part isn’t that hard; it’s the activate part that is :p
I think Brett is thinking about eliminating the manual activate part entirely,
but any tool trying to automate that needs to do a lot of platform-specific
checks.
---
> I've personally never come across Scripts in any other situation than virtual
> environments [...].
Windows use a Scripts directory to store… scripts (Setuptools terminology, i.e.
console and gui script entry points). So e.g. the global pip.exe would be at
"{sys.prefix}\Scripts\pip.exe" (or is it sys.exec_prefix?) `pip install --user`
would also install scripts into `%APPDATA%\Programs\Python\PythonXY\Scripts`.
So venv’s setup is consistent with the rest of Python.
This directory structure can be expanded from sysconfig. So the proposal in my
previous comment is to record the scheme in pyvenv.cfg, so you can have
something like
def read_venv_scheme(env_dir):
with open(os.path.join(env_dir, 'pyvenv.cfg')) as f:
for line in f:
key, value = (p.strip() for p in line.split('='))
if key == 'scheme':
return value
def get_venv_environ_patch(env_dir):
scheme = read_venv_scheme(env_dir)
bin_dir = sysconfig.get_path('scripts', scheme=scheme,
expand=False).format(base=env_dir)
return {'VIRTUAL_ENV': env_dir, 'PATH': bin_dir}
and this would give you the appropriate value on any platform.
--
___
Python tracker
<https://bugs.python.org/issue35003>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36383] Virtual environment sysconfig.get_path() and distutils.sysconfig.get_python_inc() reports base Python include directory
Tzu-ping Chung added the comment:
I can replicate this on Linux as well. Furthormore,
sysconfig.get_path('include') also returns the global path.
--
components: +Library (Lib)
nosy: +uranusjr
title: In Windows 10 virtual environments distutils.sysconfig.get_python_inc()
reports base Python include directory -> Virtual environment
sysconfig.get_path() and distutils.sysconfig.get_python_inc() reports base
Python include directory
___
Python tracker
<https://bugs.python.org/issue36383>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32730] Allow py launcher to launch other registered Pythons
Change by Tzu-ping Chung : -- nosy: +uranusjr ___ Python tracker <https://bugs.python.org/issue32730> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38671] pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not exist
Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +17161 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17716 ___ Python tracker <https://bugs.python.org/issue38671> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43312] Interface to select preferred "user" or "home" sysconfig scheme for an environment
New submission from Tzu-ping Chung :
While trying to migrate pip’s internal usages of distutils to sysconfig,[1] I
noticed there isn’t a way for pip to select a scheme for sysconfig.get_paths()
for `pip install --target` and `pip install --user`. I tried to implement some
logic to "guess" a scheme ("posix_home" for `--home`, "nt_user" for `--user`
when os.name is "nt", etc.), but eventually hit a wall trying to support
alternative implementations.
PyPy, for example, adds additional schemes "pypy" and "pypy_nt", and it’s not
clear whether pip should use then for `--home` or not. @mattip helped clear
this up for PyPy (which also prompts bpo-43307), but we are worried that other
implementations may introduce even more special rules that causes problems, and
it’s also not a good idea for pip to implement special logic for every
implementation.
I would propose two changes to sysconfig:
1. Make sysconfig._get_default_scheme() a public function. This function will
be documented for implementations to return a default scheme to use when none
is given to sysconfig.get_paths().
2. Add a new function sysconfig.get_preferred_schemes() for implementations to
return preferred schemes for prefix, home, and user installations. This
function should return a dict[str, str] with three keys "prefix", "home", and
"user", and their values the scheme names to use.
I would be happy to work on a PR and iterate on the design if this sounds like
a reasonable idea. For CPython, the implementation would be something like (to
match distutils’s behaviour):
def get_preferred_schemes():
if os.name == "nt":
return {
"prefix": "nt",
"home": "posix_home",
"user": "nt_user",
}
return {
"prefix": "posix_prefix",
"home": "posix_home",
"user": "posix_user",
}
[1]: https://github.com/pypa/pip/pull/9626
--
components: Library (Lib)
messages: 387611
nosy: uranusjr
priority: normal
severity: normal
status: open
title: Interface to select preferred "user" or "home" sysconfig scheme for an
environment
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue43312>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43312] Interface to select preferred "user" or "home" sysconfig scheme for an environment
Tzu-ping Chung added the comment: Adding Christian to the nosy list since IIRC you said something related to this a while ago. -- nosy: +christian.heimes ___ Python tracker <https://bugs.python.org/issue43312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43312] Interface to select preferred "user" or "home" sysconfig scheme for an environment
Tzu-ping Chung added the comment: That would work as well (raising KeyError or ValueError if `name` is not valid?) -- ___ Python tracker <https://bugs.python.org/issue43312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43312] Interface to select preferred "user" or "home" sysconfig scheme for an environment
Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +23429 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24644 ___ Python tracker <https://bugs.python.org/issue43312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43312] Interface to select preferred "user" or "home" sysconfig scheme for an environment
Tzu-ping Chung added the comment: How do we move the discussion forward? I would really want this to be included in 3.10. Assuming distutils is going to be removed in 3.12, pip would be left with an extremely short window if this has to wait for another year. -- ___ Python tracker <https://bugs.python.org/issue43312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43455] pathlib mistakenly assumes os.getcwd() is a resolved path in Windows
Change by Tzu-ping Chung : -- keywords: +patch nosy: +uranusjr nosy_count: 5.0 -> 6.0 pull_requests: +23574 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17716 ___ Python tracker <https://bugs.python.org/issue43455> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41327] Windows Store "stub" Python executables give confusing behaviour
Tzu-ping Chung added the comment: FWIW, I tweeted about this a while ago (January) and IIRC Steve said there’s plan to change that. https://twitter.com/uranusjr/status/1212450480917340160 -- nosy: +uranusjr ___ Python tracker <https://bugs.python.org/issue41327> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41327] Windows Store "stub" Python executables give confusing behaviour
Tzu-ping Chung added the comment: What would be the best channel to raise this issue to the Windows team from the outside? It does not need to be a spam campaign, but it’d be nice if we could direct the affected users somewhere instead of pypa/packaging-problems and various issue trackers, where the Windows team wouldn’t see. -- ___ Python tracker <https://bugs.python.org/issue41327> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35699] distutils cannot find Build Tools 2017 since 3.7.2
Change by Tzu-ping Chung : -- nosy: +uranusjr ___ Python tracker <https://bugs.python.org/issue35699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35699] distutils cannot find Build Tools 2017 since 3.7.2
Tzu-ping Chung added the comment: I read a few of the logs, and all errors roots in the same place, when the test case tries to remove the tempdir during teardown/cleanup. The Windows (and other platforms not supporting directory fds) implementation of rmtree can have race conditions if files are added while the directory being walked, causing the error. I don’t know the case of CPython, but Pipenv has a similar problem when running concurrent tests with subprocesses. We never solved it (but simply wrap the rmtree call inside a try block and look away). -- ___ Python tracker <https://bugs.python.org/issue35699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character
Change by Tzu-ping Chung : -- pull_requests: +11678 stage: backport needed -> patch review ___ Python tracker <https://bugs.python.org/issue1104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character
Change by Tzu-ping Chung : -- pull_requests: +11678, 11679 stage: backport needed -> patch review ___ Python tracker <https://bugs.python.org/issue1104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character
Change by Tzu-ping Chung : -- pull_requests: +11678, 11679, 11680 stage: backport needed -> patch review ___ Python tracker <https://bugs.python.org/issue1104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character
Change by Tzu-ping Chung : -- pull_requests: +11678, 11679, 11680, 11681 stage: backport needed -> patch review ___ Python tracker <https://bugs.python.org/issue1104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32567] Venv’s config file (pyvenv.cfg) should be compatible with ConfigParser
New submission from Tzu-ping Chung : I’m not sure if it is intended, but it seems wrong to me that pyvenv.cfg is using a format that ConfigParser does not recognise. ConfigParser requires all values be placed under a section, but pyvenv.cfg does not do that. Maybe related: * ConfigParser’s format requirement: https://docs.python.org/3/library/configparser.html#supported-ini-file-structure * How venv creates the configuration file: https://github.com/python/cpython/blob/master/Lib/venv/__init__.py#L141 * Abandoned discussion on whether ConfigParser should support section-less format #22253 -- components: Library (Lib) messages: 310071 nosy: uranusjr priority: normal severity: normal status: open title: Venv’s config file (pyvenv.cfg) should be compatible with ConfigParser type: enhancement versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue32567> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32577] Pip creates entry point commands in the wrong place when invoked in a venv nested in a virtualenv
New submission from Tzu-ping Chung : (I’m not sure whether this is a venv or virtualenv problem. Asking here first.) To reproduce: $ python3.6 -m virtualenv outer $ ./outer/bin/python -m venv inner $ ls inner/bin activate activate.csh activate.fish python python3 In comparison: $ python3.6 -m venv another $ ls another/bin activate easy_install pip3 python3 activate.csh easy_install-3.6 pip3.6 python3.6 activate.fishpip python All commands that pip is supposed to populate are missing Pip can install packages correctly, but the entry points are populated not inside the inner venv, but the outer virtualenv: $ ./inner/bin/python -m pip install django $ ls inner/bin activate activate.csh activate.fish python python3 $ ls outer/bin ... django-admin django-admin.py The entry points correctly point to the inner environment. They are just in the wrong directory. -- components: Library (Lib) messages: 310140 nosy: uranusjr priority: normal severity: normal status: open title: Pip creates entry point commands in the wrong place when invoked in a venv nested in a virtualenv versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue32577> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32577] Pip creates entry point commands in the wrong place when invoked in a venv nested in a virtualenv
Tzu-ping Chung added the comment: Yup, seems so. Closing as duplicate then. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue32577> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30811] A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own.
Tzu-ping Chung added the comment:
Would it be possible for venv to do this automatically? Instead of using
sys.executable, use
import sysconfig
dirname, exename = sysconfig.get_config_vars('BINDIR', 'BUILDPYTHON')
to populate values in the context?
--
nosy: +uranusjr
___
Python tracker
<https://bugs.python.org/issue30811>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30811] A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own.
Tzu-ping Chung added the comment:
Plot twist: the workaround does not work on Windows.
$ cd SOMEDIR ; Placeholder for a valid directory.
$ virtualenv env1
...
$ env\Scripts\python.exe
Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> print(sysconfig.get_config_var('BINDIR'))
SOMDIR\env1\Scripts
This points to the virtualenv's BINDIR, not the real Python installation's :(
--
___
Python tracker
<https://bugs.python.org/issue30811>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30811] A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own.
Tzu-ping Chung added the comment: @cosven you are correct! I made some additional observation while working on adding venv support to pew, in this thread: https://github.com/berdario/pew/pull/173. I’ll try to summarise below. The root problem is indeed virtualenv’s custom site module, but even then it is possible for venv (or any tool built around it) to know where the “original” Python is, since virtualenv stores the old sys.prefix in sys.real_prefix. Unfortunately, however, this is not as useful as it seems. What we really want in this situation is sys.exec_prefix, which may or may not be the same as sys.prefix. I did manage to cobble together a hack, but it is by no means bullet-proof. To actually deal with this problem, we will need to amend the site module provided by virtualenv, as you mentioned. But this still can’t “solve” it. Since the site module is vendored in the produced virtualenv, existing virtualenvs will stay broken even after we managed to upgrade the virtualenv installations. -- ___ Python tracker <https://bugs.python.org/issue30811> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31694] Running Windows installer with LauncherOnly=1 should not register the version as installed
New submission from Tzu-ping Chung : After running python-3.6.2-amd64.exe /quiet LauncherOnly=1 Python 3.6.2 is registered as installed, even though nothing is actually installed. Running the installer again at this point shows an error indicating “this product is already installed”, and does not show me the usual repair/modify/uninstall options. I have to run uninstallation with Control Panel before the installer works again. -- components: Installation messages: 303727 nosy: uranusjr priority: normal severity: normal status: open title: Running Windows installer with LauncherOnly=1 should not register the version as installed type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue31694> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31694] Running Windows installer with LauncherOnly=1 should not register the version as installed
Tzu-ping Chung added the comment: The “this product is already installed” error is a mistake on my part. I was actually using 3.6.3 (released literally during I was testing this!) to install the launcher, and using 3.6.2 afterwards, hence the error message (because I was trying to modify using an older version). The main issue however stays. The installer still shouldn’t register the main Python distribution as installed when only the launcher was selected. -- ___ Python tracker <https://bugs.python.org/issue31694> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character
Change by Tzu-ping Chung : -- nosy: +uranusjr ___ Python tracker <https://bugs.python.org/issue1104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31720] msilib.MSIError is spelled MsiError in documentation
New submission from Tzu-ping Chung : The title describes it all. -- assignee: docs@python components: Documentation messages: 303877 nosy: docs@python, uranusjr priority: normal severity: normal status: open title: msilib.MSIError is spelled MsiError in documentation versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue31720> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31720] msilib.MSIError is spelled MsiError in documentation
Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +3887 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31720> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character
Tzu-ping Chung added the comment: I have created a PR #4517 from the patch. Would it be better to track the malloc problem in a new issue? As for why this never caused any problems… msilib is pretty standalone, and not one of the most used modules. It is also pretty trivial to roll your own solution with ctypes (or any FFI library), which is what I did when I hit this bug. -- ___ Python tracker <https://bugs.python.org/issue1104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character
Tzu-ping Chung added the comment: I made a shot to address the free() call. Hopefully this makes sense. -- ___ Python tracker <https://bugs.python.org/issue1104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32151] -mvenv vs minor python version updates
Tzu-ping Chung added the comment: Not sure if it’s the same thing, but I want to plug in that this can happen when you do a micro upgrade (e.g. 3.5.1 → 3.5.2) as well. This is because micro updates sometimes bump versions of dependencies (e.g. OpenSSL, Tk), and that breaks theirs links in the venv. Should this also be expected? -- nosy: +uranusjr ___ Python tracker <https://bugs.python.org/issue32151> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32151] -mvenv vs minor python version updates
Tzu-ping Chung added the comment: Hmm, I’m quite sure I have experience that a virtual environment breaks after a micro version upgrade on macOS, getting an “image not found” or something similar. I’m not using the official released Python, but via Homebrew, so maybe this does not happen with the official distribution? I vaguely remember getting into a similar problem on Windows as well though… I don’t have a handy environment set up for reproduction right now. I will try to report any problem if I run into this again in the future. -- ___ Python tracker <https://bugs.python.org/issue32151> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32442] Result of pathlib.Path.resolve() with UNC path is not very useful
New submission from Tzu-ping Chung :
The behaviour of os.path.abspath() and pathlib.Path.resolve() is a different
when dealing with a path on a UNC share (on Windows):
>>> import os, pathlib
>>> path = pathlib.Path('Z:\foo')
>>> path.resolve()
WindowsPath('//host/share/foo')
>>> os.path.abspath(path)
'Z:\\foo'
This is not necessarily a problem by itself, just a consequence of calling
different APIs underneath (although it probably worths a mention in
documentation). The real problem is that the UNC path is not really useful
anywhere in the Python standard library (AFAIK), and there’s no way to turn the
it (back) into network drive once you call resolve(). The only way to get a
network drive path is to
>>> pathlib.Path(os.path.abspath(path))
Some possibile solutions:
1. Change the behaviour of resolve() to return the network drive path instead.
This would be the most straightforward, API-wise, but is backward-incompatible,
and maybe the original implementation did this on purpose?
2. Add a as_absolute() to pathlib.Path. On Windows this would mirror the result
of os.path.abspath(); on POSIX this would probably be identical to resolve().
3. Add an argument to resolve()? This is essentially the same as 2., just
interfaced differently.
--
components: Library (Lib), Windows
messages: 309137
nosy: paul.moore, steve.dower, tim.golden, uranusjr, zach.ware
priority: normal
severity: normal
status: open
title: Result of pathlib.Path.resolve() with UNC path is not very useful
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue32442>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32442] Result of pathlib.Path.resolve() with UNC path is not very useful
Tzu-ping Chung added the comment: @Eric You’re correct, this is not the exact output. I tested the commands with a different path, but didn’t format them correctly when I convert them to use a generic example. Sorry for the confusion. @Eryk I found my problem. I was doing some os.rename and shutil stuff that constantly fails when moving and copying things using UNC paths, but works flawlessly when I convert them to use drives. I assumed it’s because the UNC, but after a more involved debugging I find all UNC calls work by themselves, only fail when I combine them. I guess it is due to some strange Windows thing, maybe UNC file stat can’t update fast enough for the next call to get the correct state or something. The attached recipe worked very well. Thanks for the help! I’m closing this since the problem is likely not Python-related. Sorry for the disturbance. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue32442> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30811] A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own.
Tzu-ping Chung added the comment: Unfortunately it is not a viable solution. If you run the virtualenv python without activation, e.g. virtualenv --python=python3.7 foo foo/bin/python -m venv bar The VIRTUAL_ENV environment variable wouldn’t be set in this situation, but the created venv (bar) would still be broken. The only viable cue I find to detect virtualenv existence is it sets sys.real_prefix to point to the prefix of the actual Python isntallation (i.e. the value of sys.prefix without virtualenv), while this variable does not exist by default. This is, however, obviously very hacky and unreliable, and not something venv should do IMO. virtualenv is the problem here, and should be responsible for fixing this situation instead. -- ___ Python tracker <https://bugs.python.org/issue30811> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25312] Cryptic error message if incorrect spec is set on a callable mock
New submission from Tzu-ping Chung: >>> from unittest import mock >>> >>> class Foo: ... def __init__(self, val): ... pass ... def func(self): ... pass ... >>> class FooMock(mock.Mock): ... def _get_child_mock(self, **kwargs): ... return mock.Mock(spec_set=Foo) ... >>> mock_foo = FooMock() >>> mock_foo.func() >>> mock_foo.func.mock_calls [call()] >>> mock_foo.func.assert_has_calls([mock.call()]) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/unittest/mock.py", line 824, in assert_has_calls ) from cause AssertionError: Calls not found. Expected: [call()] Actual: [call()] While this code is expected to fail (FooMock.func is set to an incorrect spec), the error message is misleading and does not make any sense. -- components: Library (Lib) messages: 252276 nosy: uranusjr priority: normal severity: normal status: open title: Cryptic error message if incorrect spec is set on a callable mock type: behavior versions: Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue25312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
