You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"pytest-memray==1.7.0 ; python_full_version < '3.14' and implementation_name == 'cpython' and sys_platform != 'win32'",
"pytest-socket>=0.7.0",
"pytest-timeout>=2.3.1",
"quart>=0.20.0",
"quart-trio>=0.12.0",
"towncrier>=24.8.0",
"trustme>=1.2.1",
"trio>=0.27.0",
]
mypy = [
"anyio[trio]>=4.8.0",
"cryptography>=44.0.2",
"httpx>=0.28.1",
"hypercorn>=0.15.0",
"idna>=3.10",
"mypy>=1.14.1",
"pytest>=8.3.4",
"quart>=0.20.0",
"quart-trio>=0.12.0",
"trio>=0.27.0",
"trustme>=1.2.1",
"types-requests>=2.32.0.20241016",
"nox>=2024.10.9",
"zstandard>=0.23.0",
]
I am not sure exactly what to say that the common dependencies represent, but if we could figure out something sensible to call them, we could represent them in their own dependency group:
some_other_group = [
"anyio[trio]>=4.8.0",
"cryptography>=44.0.2",
"httpx>=0.28.1",
"hypercorn>=0.15.0", # dev lacks the version bound; both are affected by tool.uv.sources.hypercorn"idna>=3.10",
"pytest>=8.3.4",
"quart>=0.20.0",
"quart-trio>=0.12.0",
"trio>=0.27.0",
"trustme>=1.2.1",
]
Second, in Fedora we really benefit from dependency groups because we can use them to generate build-time requirements for running the tests rather than manually enumerating them; see discussion in https://src.fedoraproject.org/rpms/python-urllib3/pull-request/44.
However, we really just want the dependencies for running the tests, without profilers (like pytest-memray), coverage analysis (coverage), or tools for maintainer tasks (build, towncrier). It would be really helpful if there were a dependency group (test, presumably) that just listed test dependencies. Even if you decided not to split out coverage and profiling dependencies, and even if we still had to patch out a couple of unwanted dependencies, this would be a much more useful starting point than the dev group is.
If you decide to do this, the “dependency group includes” technique demonstrated above would make it easy to include a new test group in the dev group, so dev could still install “everything.”
Alternatives
For the first suggestion, repetition of dependency specifications seems to be more of an inconvenience for upstream maintainers than it is for downstream packagers and users. The alternative is the status quo, and it’s generally adequate.
For the second suggestion, one alternative for the Fedora package is to manually list BuildRequires for testing, as we did prior to 2.4.0. This is acceptable; it requires some care to make sure that the manual list remains synchronized with the actual upstream dependencies. The other alternative is to patch the contents of the dev dependency group – using sed or a TOML-specific patching tool – before using it to generate BuildRequires, as currently proposed in https://src.fedoraproject.org/rpms/python-urllib3/pull-request/44. This is viable, but the less patching we can do, the less trouble it is, and the fewer errors we are likely to make.
Duplicate
I did not find any similar requests.
Contribution
Would you be willing to submit a PR? (Help can be provided if you need assistance submitting a PR)
Yes, I would be willing to submit a PR if a rough consensus on design and nomenclature emerges.
The text was updated successfully, but these errors were encountered:
Context
There are two things I notice about the current dependency groups.
First, there is a lot of repetition between
devandmypy:urllib3/pyproject.toml
Lines 58 to 94 in 910f031
I am not sure exactly what to say that the common dependencies represent, but if we could figure out something sensible to call them, we could represent them in their own dependency group:
and then use Dependency Group Includes:
Second, in Fedora we really benefit from dependency groups because we can use them to generate build-time requirements for running the tests rather than manually enumerating them; see discussion in https://src.fedoraproject.org/rpms/python-urllib3/pull-request/44.
However, we really just want the dependencies for running the tests, without profilers (like
pytest-memray), coverage analysis (coverage), or tools for maintainer tasks (build,towncrier). It would be really helpful if there were a dependency group (test, presumably) that just listed test dependencies. Even if you decided not to split out coverage and profiling dependencies, and even if we still had to patch out a couple of unwanted dependencies, this would be a much more useful starting point than thedevgroup is.If you decide to do this, the “dependency group includes” technique demonstrated above would make it easy to include a new
testgroup in thedevgroup, sodevcould still install “everything.”Alternatives
For the first suggestion, repetition of dependency specifications seems to be more of an inconvenience for upstream maintainers than it is for downstream packagers and users. The alternative is the status quo, and it’s generally adequate.
For the second suggestion, one alternative for the Fedora package is to manually list
BuildRequiresfor testing, as we did prior to 2.4.0. This is acceptable; it requires some care to make sure that the manual list remains synchronized with the actual upstream dependencies. The other alternative is to patch the contents of thedevdependency group – usingsedor a TOML-specific patching tool – before using it to generateBuildRequires, as currently proposed in https://src.fedoraproject.org/rpms/python-urllib3/pull-request/44. This is viable, but the less patching we can do, the less trouble it is, and the fewer errors we are likely to make.Duplicate
I did not find any similar requests.
Contribution
Would you be willing to submit a PR?
(Help can be provided if you need assistance submitting a PR)
Yes, I would be willing to submit a PR if a rough consensus on design and nomenclature emerges.
The text was updated successfully, but these errors were encountered: