Skip to content
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

More porting from requests to urllib3 #2773

Open
wants to merge 4 commits into
base: develop
Choose a base branch
from

Conversation

jku
Copy link
Member

@jku jku commented Jan 29, 2025

This is a followup to #2762 (that replaces RequestsFetcher with Urllib3Fetcher):

  • remove last uses of requests (examples, verify_release)
  • remove requests from dependencies
  • Move the fetcher implementations from tuf.ngclient._internal to tuf.ngclient: this was always the intention anyway and this allows RequestsFetcher to be not imported by default but importable if users want it: from tuf.ngclient.requests_fetcher import RequestsFetcher

This is pretty nice:

$ pip install -e .
...
Successfully installed securesystemslib-1.2.0 tuf-5.1.0 urllib3-2.3.0

two dependencies!

Obviously if you install cryptography you end up with a few more but even in that case we have come down from 17 dependencies in v0.14 to five dependencies in next release. With this trajectory we're hitting zero before 2028!

@jku jku changed the title More porting from from requests to urllib3 More porting from requests to urllib3 Jan 29, 2025
@jku

This comment was marked as outdated.

jku added 4 commits February 14, 2025 17:41
This is related to theupdateframework#2762 (that replaces RequestsFetcher with
Urllib3Fetcher) and takes care of the remaining requests use cases in
the code base.

Signed-off-by: Jussi Kukkonen <jkukkonen@google.com>
This also removes RequestsFetcher from tuf.ngclient.__init__.py:
Otherwise we can't drop the requests dependency.

This means RequestsFetcher is not currently public.

Signed-off-by: Jussi Kukkonen <jkukkonen@google.com>
RequestsFetcher should still be public (even if deprecated).

* We don't want to import RequestsFetcher in __init__
  (because that requires importing requests)
* but we do want RequestsFetcher to be importable publicly

Move both fetchers out of _internal: that was never the right place for
them anyway: they are public modules.

Signed-off-by: Jussi Kukkonen <jkukkonen@google.com>
Signed-off-by: Jussi Kukkonen <jkukkonen@google.com>
@jku jku marked this pull request as ready for review February 14, 2025 15:46
@jku jku requested a review from a team as a code owner February 14, 2025 15:46
@jku
Copy link
Member Author

jku commented Feb 14, 2025

@NicholasTanz GitHub doesn't let me mark you as reviewer but I wouldn't mind if you did review: this is a followup on your PR

@jku
Copy link
Member Author

jku commented Feb 14, 2025

we have come down from 17 dependencies in v0.14 to five dependencies in next release. With this trajectory we're hitting zero before 2028!

singularity is actually projected for christmas 2026:

Screenshot from 2025-02-14 22-42-19

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant