How would you improve Rich?
Rich currently has run time a dependency on typing_extensions, but this can be removed by moving all the imports into type checking blocks,
e.g.
if sys.version_info >= (3, 11):
from typing import Self
else:
from typing_extensions import Self # pragma: no coverBecomes:
from __future__ import annotations
from typing import TYPE_CHECKING
if TYPE_CHECKING:
# Can be replaced with `from typing import Self` in Python 3.11+
from typing_extensions import Self Or you can avoid from __future__ import annotations and when type hinting use "Self" instead of Self.
And then you move typing-extensions from tool.poetry.dependencies to tool.poetry.dev-dependencies in pyproject.toml.
What problem does it solve for you?
This reduces the amount of dependencies rich has, which helps with dependency conflicts and reduces the amount of IO that happens for the many consumers of rich.
But as a pip maintainer this is a slightly bigger issue for us, as we vendor rich, and it will allow us to stop vendoring typing-extensions which reduces the size of our distribution, and prevents edge cases with typing-extensions (which one popped up recently: pypa/pip#13428).
I am happy to raise a PR to complete this work.
How would you improve Rich?
Rich currently has run time a dependency on typing_extensions, but this can be removed by moving all the imports into type checking blocks,
e.g.
Becomes:
Or you can avoid
from __future__ import annotationsand when type hinting use"Self"instead ofSelf.And then you move
typing-extensionsfromtool.poetry.dependenciestotool.poetry.dev-dependenciesinpyproject.toml.What problem does it solve for you?
This reduces the amount of dependencies rich has, which helps with dependency conflicts and reduces the amount of IO that happens for the many consumers of rich.
But as a pip maintainer this is a slightly bigger issue for us, as we vendor rich, and it will allow us to stop vendoring
typing-extensionswhich reduces the size of our distribution, and prevents edge cases withtyping-extensions(which one popped up recently: pypa/pip#13428).I am happy to raise a PR to complete this work.