Version compatibility check for optional dependencies
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start by reading the optional rich traceback integration and its dependency declarations; the issue does not name specific files or tests. Check how supported rich versions affect Traceback.from_exception, then consider how compatibility should be detected and communicated. Done means an incompatible optional dependency is handled safely and the behavior is covered by tests, including the reported rich versions.
Written by the indexing model from the issue text.
Description
Hi folks,
I recently ran into an issue with the rich integration, for traceback formatting.
With structlog version 23.2.0, and rich version 13.0.1, receiving a traceback results in a crash during error handling, as follows :
[...]
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib64/python3.10/logging/__init__.py", line 1100, in emit
msg = self.format(record)
File "/usr/lib64/python3.10/logging/__init__.py", line 943, in format
return fmt.format(record)
File "<redacted>/.venv/lib/python3.10/site-packages/structlog/stdlib.py", line 1062, in format
ed = p(logger, meth_name, ed)
File "<redacted>/.venv/lib/python3.10/site-packages/structlog/dev.py", line 505, in __call__
self._exception_formatter(sio, exc_info)
File "<redacted>/.venv/lib/python3.10/site-packages/structlog/dev.py", line 218, in __call__
Traceback.from_exception(
TypeError: Traceback.from_exception() got an unexpected keyword argument 'locals_hide_dunder'
[...]
Upgrading rich to version 13.7.0 solves the issue, stacktraces now appear normally.
I undersand that rich is entirely optional to structlog, but I was wondering if maybe we could add some kind of protection against using an incompatible version of it. On top of my head :
- specifying version constraints. I'm unsure if the dependency constraint system permits to express "This is an optional dependency, so, please don't install it automatically with me ; but if it's present, ensure it validates those constraints, because I'm gonna use it". If that's possible, it would, in my opinion, be an ideal solution
- checking, at some initialization step (I assume we're making some kind of presence check for
richduring structlog init), that the installed version is indeed recent enough, and don't attempt to use it if not. Maybe log something indicating the minimum required version - checking version when attempting to use it. This sounds expensive at runtime though, so, probably not a good idea.
- some heuristic checks might be possible too, like, checking the function signature before attempting to call it, for non-existing arguments, etc. This would be pretty brittle, could not deal with all kinds of incompatibilities or bugs, etc ; so, probably not great either.
Also, similar checks could make sense for other optional dependencies (like better-exceptions)
What do you think ? Does that seem reasonable ?
- Dominant language
- Python
- Stars
- 5k
- Forks
- 302
- Avg merge
- 17m
- Merged PRs (30d)
- 4
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from hynek/structlog
-
bind_contextvars is not thread-safe?Possibly taken @nosmile99 claimed this 2 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Transform examples in docs into included source filesPossibly taken @alexchen-sys claimed this 100 days ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 25/100
-
Difficulty 5/5 Over a week Newbie friendliness 38/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
waiting for feedback
Difficulty 3/5 1-2 days Newbie friendliness 48/100
Similar issues
-
Project submission:Open
Difficulty 1/5 Under an hour Newbie friendliness 72/100
slavakurilyak/awesome-ai-agents#845 ·
Maintainers usually reply within 1 day
-
tests: pin that the atomic writers in utils/paths.py stage the temporary file in the target's directoryPossibly taken A pull request linked to this issue is open or already merged. Opendifficulty:2 enhancement good first issue
Difficulty 1/5 1-3 hours Newbie friendliness 92/100
MakazhanAlpamys/Soup#2178 ·
Maintainers usually reply within 1 day
-
[BUG] dcg.waggr permutation p-values are folded twice, so near-zero scores get the smallest p-valuesOpen
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
scverse/rapids-singlecell#854 ·
Maintainers usually reply within 1 day
-
Slang input: int8_t4_packed and uint8_t4_packed are copied into CrossGLPossibly taken @ninglinLiu claimed this today. Openarea:frontend backend:slang bug direction:input
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 13 days