[issue43888] GitHub Actions CI/CD `Coverage` job is broken on master
Change by Sviatoslav Sydorenko : -- keywords: +patch pull_requests: +24196 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25471 ___ Python tracker <https://bugs.python.org/issue43888> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43888] GitHub Actions CI/CD `Coverage` job is broken on master
Change by Sviatoslav Sydorenko : -- type: crash -> ___ Python tracker <https://bugs.python.org/issue43888> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43888] GitHub Actions CI/CD `Coverage` job is broken on master
New submission from Sviatoslav Sydorenko : I noticed that https://github.com/python/cpython/runs/2378199636 (a coverage job on the last commit on master at the time of writing) takes suspiciously long to complete. I did some investigation and noticed that this job on the 3.9 branch succeeds (all of the job runs on the first page in the list are green — https://github.com/python/cpython/actions/workflows/coverage.yml?query=branch%3A3.9) But then I took a look at the runs on master and discovered that the last successful run was 4 months ago — https://github.com/python/cpython/actions.html?query=is%3Asuccess+branch%3Amaster_file_name=coverage.yml. The last success is https://github.com/python/cpython/actions/runs/444323166 and after that, starting with https://github.com/python/cpython/actions/runs/05699, if fails consistently. Notably, all of the failures are caused by the job timeout after *6 hours* — GitHub platform just kills those, 6h is a default per-job timeout in GHA. It's also important to mention that before every job starting timing out effectively burning 6 hours of GHA time for each merge and producing no useful reports, there were occasional 6h-timeouts but they weren't consistent. Looking into the successful runs from the past, on master and other jobs, I haven't noticed it taking more than 1h35m to complete with a successful outcome. Taking into account this as a baseline, I suggest changing the timeout of the whole job or maybe just one step that actually runs coverage. Action items: * Set job timeout in GHA to 1h40m (allowing a bit of extra time for exceptionally slow jobs) — this will make sure that the failure/timeout is reported sooner than 6h * Figure out why this started happening in the first place. I'm going to send a PR addressing the first point but feel free to pick up the investigation part — I don't expect to have time for this anytime soon. P.S. FTR the last timeout of this type happened two months ago — https://github.com/python/cpython/actions.html?page=4=branch%3A3.9_file_name=coverage.yml. -- messages: 391373 nosy: webknjaz priority: normal severity: normal status: open title: GitHub Actions CI/CD `Coverage` job is broken on master type: crash ___ Python tracker <https://bugs.python.org/issue43888> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43540] importlib: Document how to replace load_module() in What's New in Python 3.10
Sviatoslav Sydorenko added the comment: @vstinner: I think I figure out the solution — https://github.com/pypa/setuptools/pull/2633 -- nosy: +webknjaz ___ Python tracker <https://bugs.python.org/issue43540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26131] Raise ImportWarning when loader.load_module() is used
Sviatoslav Sydorenko added the comment: > What is "VendorImporter" @brett.cannon `VendorImporter` is something comping from `pkg_resources`. Because of an entangled traceback and the fact that it dynamically injects a vendored copy of `six`, it's hard to spot. Here's an upstream issue I filed about this warning: https://github.com/pypa/setuptools/issues/2481. -- nosy: +webknjaz ___ Python tracker <https://bugs.python.org/issue26131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20120] Percent-signs (%) in .pypirc should not be interpolated
Sviatoslav Sydorenko added the comment:
Not sure if it's in the scope of this issue but I thought I'd report it.
I've just hit a similar issue with `setup.cfg` under Python 3.8 which is
supposed to be parsed by `setuptools` but for some reason, I only see
`distutils` in the trace, coming from `pip`.
```
$ python -m pip install --upgrade tox
ERROR: Exception:
Traceback (most recent call last):
File
"/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/site-packages/pip/_internal/cli/base_command.py",
line 186, in _main
status = self.run(options, args)
File
"/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/site-packages/pip/_internal/commands/install.py",
line 253, in run
options.use_user_site = decide_user_install(
File
"/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/site-packages/pip/_internal/commands/install.py",
line 604, in decide_user_install
if site_packages_writable(root=root_path, isolated=isolated_mode):
File
"/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/site-packages/pip/_internal/commands/install.py",
line 549, in site_packages_writable
test_writable_dir(d) for d in set(get_lib_location_guesses(**kwargs))
File
"/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/site-packages/pip/_internal/commands/install.py",
line 543, in get_lib_location_guesses
scheme = distutils_scheme('', *args, **kwargs)
File
"/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/site-packages/pip/_internal/locations.py",
line 109, in distutils_scheme
d.parse_config_files()
File "/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/distutils/dist.py",
line 413, in parse_config_files
val = parser.get(section,opt)
File "/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/configparser.py",
line 799, in get
return self._interpolation.before_get(self, section, option, value,
File "/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/configparser.py",
line 395, in before_get
self._interpolate_some(parser, option, L, value, section, defaults, 1)
File "/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/configparser.py",
line 442, in _interpolate_some
raise InterpolationSyntaxError(
configparser.InterpolationSyntaxError: '%' must be followed by '%' or '(',
found: '%3Adevel\nCode of Conduct =
https://docs.ansible.com/ansible/latest/community/code_of_conduct.html\nSource
Code = https://github.com/ansible/pylibssh'
```
(https://github.com/ansible/pylibssh/runs/640262804?check_suite_focus=true#step:7:32)
This is caused by
```
diff --git a/setup.cfg b/setup.cfg
index 9318235..0455376 100644
--- a/setup.cfg
+++ b/setup.cfg
@@ -9,7 +9,7 @@ version = 0.0.1.dev1
url = https://github.com/ansible/pylibssh
project_urls =
Bug Tracker = https://github.com/ansible/pylibssh/issues
-CI: Travis = https://travis-ci.com/ansible/pylibssh
+CI: GitHub Workflows =
https://github.com/ansible/pylibssh/actions?query=branch%3Adevel
Code of Conduct =
https://docs.ansible.com/ansible/latest/community/code_of_conduct.html
Source Code = https://github.com/ansible/pylibssh
description = Python bindings for libssh client specific to Ansible use case
```
--
nosy: +webknjaz
___
Python tracker
<https://bugs.python.org/issue20120>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38216] Fix for issue30458 prevents crafting invalid requests
Change by Sviatoslav Sydorenko : -- nosy: +webknjaz ___ Python tracker <https://bugs.python.org/issue38216> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36274] http.client cannot send non-ASCII request lines
Sviatoslav Sydorenko added the comment: @xtreak the encoded null-byte test would be an extra test case to consider. It is reasonable to test as many known invalid sequences as possible. Changing that byte to encoded notation would just replace one test with another effectively changing the semantics of it. To me, it's quite weird that it's considered a CVE at all: it's happening on the client side and it doesn't prevent the user from just feeding the proper bytes right into the socket so why overcomplicate things? -- ___ Python tracker <https://bugs.python.org/issue36274> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36274] http.client cannot send non-ASCII request lines
Change by Sviatoslav Sydorenko : -- nosy: +webknjaz ___ Python tracker <https://bugs.python.org/issue36274> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36608] Replace bundled pip and setuptools with a downloader in the ensurepip module
Sviatoslav Sydorenko added the comment: Thanks for the feedback! I've changed it a bit to have a separate command for downloading bundles to the source tree. It'd work as in `python -m ensurepip.bundle` (needs a better name/CLI args probably). Does it sound better now? -- ___ Python tracker <https://bugs.python.org/issue36608> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30088] mailbox.Maildir doesn't create subdir structure when create=True and base dir exists
Sviatoslav Sydorenko added the comment: Hi, I've tried clarifying this in docs as suggested @ https://github.com/python/cpython/pull/1163 -- ___ Python tracker <https://bugs.python.org/issue30088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36608] Replace bundled pip and setuptools with a downloader in the ensurepip module
Change by Sviatoslav Sydorenko : -- keywords: +patch pull_requests: +12719 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36608> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36608] Replace bundled pip and setuptools with a downloader in the ensurepip module
New submission from Sviatoslav Sydorenko : Hi, I've noticed that there's an idea to not pollute Git tree with vendored blobs. In particular, `ensurepip` is one of the components doing this. Such a wish was expressed here: https://bugs.python.org/issue35277#msg330098 So I thought I'd take a stab at it... -- components: Library (Lib) messages: 339998 nosy: dstufft, pradyunsg, serhiy.storchaka, webknjaz priority: normal severity: normal status: open title: Replace bundled pip and setuptools with a downloader in the ensurepip module type: enhancement versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue36608> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21537] functools.lru_cache does not cache exceptions
Sviatoslav Sydorenko added the comment: Hi, I've got similar need (caching exceptions). My use case is syscall, which is not going to result in something different regardless of the number of times it's called. But I'd like to be able to have exception already raised for me by lru_cache, so that I won't poke kernel with no need. I'd suggest adding `cache_exceptions=False` key to the decorator to let user control whether it's worth enabling. This might be useful in stdlib. -- nosy: +webknjaz ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue21537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30088] mailbox.Maildir doesn't create subdir structure when create=True and base dir exists
Sviatoslav Sydorenko added the comment: > create a Maildir folder in a temporary directory: > > with tempfile.TemporaryDirectory() as tmpdir: > with mailbox.Maildir(os.path.join(tmpdir, 'mail'), create=True) as > box: > ... Yeah, I came up with the same solution. It just seems weird to me. The doc says "If create is True, the mailbox is created if it does not exist.". So it operates the term mailbox, not a folder. I would assume that a valid mailbox [1] is the whole **valid** directory structure with subfolders. If the corresponding subdirs are missing the folder should not be considered as a valid maildir, right? Given above, I think the documentation doesn't clearly promise the same behavior that the code does. Shouldn't this be fixed? (Either docs, or code) [1] http://www.qmail.org/man/man5/maildir.html -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30088] mailbox.Maildir doesn't create subdir structure when create=True and base dir exists
New submission from Sviatoslav Sydorenko: Hi, I've faced an issue w/ `mailbox.Maildir()`. The case is following: 1. I create a folder with `tempfile.TemporaryDirectory()`, so it's empty 2. I pass that folder path as an argument when instantiating `mailbox.Maildir()` 3. Then I receive an exception happening because "there's no such file or directory" (namely `cur`, `tmp` or `new`) during interaction with Maildir **Expected result:** subdirs are created during `Maildir()` instance creation. **Actual result:** subdirs are assumed as existing which leads to exceptions during use. **Workaround:** remove the actual dir before passing the path to `Maildir()`. It will be created automatically with all subdirs needed. **Fix:** PR linked. Basically it adds creation of subdirs regardless of whether the base dir existed before. -- components: Library (Lib) messages: 291789 nosy: webknjaz priority: normal pull_requests: 1293 severity: normal status: open title: mailbox.Maildir doesn't create subdir structure when create=True and base dir exists type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
