Implementation name "python" is hard-coded in test_venv
Bug report
Bug description:
The behavior of venv was changed in 48d926269963.
Before this change, libpath was hard-coded as python%d.%d. It has now been replaced with sysconfig.get_path(..., scheme='venv').
However, while this patch was applied, the corresponding test, test_venv was not updated and was left unchanged. As a result, test_venv now fails when sysconfig is overridden.
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Linked PRs
- gh-143000
A good bug report typically also explains what the current behavior prevents you from doing.
I am sorry about the poor description. While writing more about the issue, I found this is not that simple as it looked first time. I will leave a comment once I update the issue body.
As this is only referring to unit test code, it's not clear why you think this change is needed. It doesn't affect any code users could write around the venv package, does it? And it seems you've gone to the trouble of writing a PR, while not explaining clearly what the problem, if any, is?
While writing more about the issue
Where were you writing more?
it's not clear why you think this change is needed
For context, youknowone helps maintain an alternative implementation of Python
@gvanrossum I updated the issue description. test_venv is not updated when venv behavior is changed.
@vsajip Any downstream or alter implementation which overrode sysconfig will encounter the test fails without a good reason. I am maintaining RustPython and wish these tests work as long as they are not marked as @cpython_only
@hauntsaninja Thank you for mentioning it!
OK, I get it now.
I recently ran venv on windows, and EnvBuilder is always setting the binary name python. If we are going to change the test, using EnvBuilder will be better.
https://github.com/python/cpython/blob/v3.14.2/Lib/venv/init.py#L171
Any advice about the proper approach will be appreciated. Worth to try using EnvBuilder in tests?