Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

client/updater design: parallel downloads

Ouverte
  • Quelque chose ne va pas ?
#1,158 1 commentaire 2 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
python
Domaine
backend-api-design, security

Piste de recherche

Lisez d’abord les points d’entrée existants Updater.refresh(), Updater.get_valid_targetinfos(list) et Updater.download_targets(list), puis examinez le contexte des téléchargements parallèles de pip décrit dans l’issue. Définissez un périmètre concret pour l’API ou la concurrence, la tâche étant considérée comme terminée lorsque targets et les métadonnées bin peuvent être téléchargés en parallèle sans rendre dangereux l’état partagé de Updater.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Python
Étoiles
1.7k
Forks
304
Merge moyen
9 h 25 min
PR mergées (30 j)
14

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de theupdateframework/python-tuf

Toutes les issues de theupdateframework/python-tuf

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.