-
-
Notifications
You must be signed in to change notification settings - Fork 33.7k
bpo-38470: compileall tests: Use a shorter path on Windows #16778
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Thank you for working on this! |
|
The buildbot fails with this as well: https://buildbot.python.org/all/#/builders/42/builds/59 |
|
The test still fails on my Windows 10 VM using my patch to disable long path support: https://bugs.python.org/issue38470#msg354636 |
|
The path created by create_long_path() is smaller than the limit, but py_compile uses _write_atomic() of importlib._bootstrap_external which adds a ".xxx" suffix: With this suffix, the temporary filename is too long: 261 characters on my VM. |
|
I proposed a different approach: PR #16789. |
|
Aha! Thank you! I'll get on it tomorrow
…On October 14, 2019 5:59:31 PM GMT+02:00, Victor Stinner ***@***.***> wrote:
The path created by create_long_path() is smaller than the limit, but
py_compile uses _write_atomic() of importlib._bootstrap_external which
adds a ".xxx" suffix:
```
# id() is used to generate a pseudo-random filename.
path_tmp = '{}.{}'.format(path, id(path))
```
With this suffix, the temporary filename is too long: 261 characters on
my VM.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#16778 (comment)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
|
GH-16789 has been merged instead. |
I'd like to test compileall with a really deeply nested path everywhere, but I cannot reproduce the issue occuring on Windows.
This limits the maximum path depth to 20 on Windows. That's enough to test the compileall functionality.
cc @frenzymadness
https://bugs.python.org/issue38470