Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

client/updater design: parallel downloads

Aperta
  • Qualcosa non va?
#1,158 1 commento 2 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 10 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
python
Ambito
backend-api-design, security

Direzione di ricerca

Leggere i punti di ingresso esistenti Updater.refresh(), Updater.get_valid_targetinfos(list) e Updater.download_targets(list), quindi esaminare il contesto dei download paralleli di pip descritto nell’issue. Definire un ambito concreto per l’API o la concorrenza, considerando completato il lavoro quando targets e i metadati bin possono essere scaricati in parallelo senza rendere non sicuro lo stato condiviso di Updater.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement ngclient

Updater should in some way support parallel downloads.

This came up because I found an obscure corner in pip that does index file downloads in parallel in pip (pip list --outdated): if I plug my TUF-support in there, TUF Updater gets called from multiple threads and very bad things happen.

Some notes on this:

  • for the pip use case, letting pip handle the actual downloads would remove 50% of the need for this -- but bin metadata downloads would still be sequential (and Updater.refresh() would still be thread-unsafe)
  • Still, parallel downloads (for both targets and bin metadata) is probably a wanted feature in other user-facing apps as well: it is faster and is something package managers already often do
  • this feature does not mean that TUF API absolutely needs to be threadsafe: many use cases would be covered by small API change: Updater.get_valid_targetinfos(list) and Updater.download_targets(list) could still be a single-threaded API but they could be implemented in a way that uses multiple threads and multiple connections to the server. I have no idea how easy this would be though.
  • The nicest solution might be a low-level Sans-IO style API (a state machine with events) or at least something that is asynchronous to the users. This API is then wrapped by a simple I/O layer that could look much like it now does. This would mean a large change.
Lingua principale
Python
Stelle
1.7k
Fork
304
Merge medio
9h 25m
PR unite (30g)
14

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di theupdateframework/python-tuf

Tutte le issue di theupdateframework/python-tuf

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.