Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

client/updater design: parallel downloads

Aberta
  • Algo errado?
#1,158 1 comentário 2 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 10 dias

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Estagnada
Stack de tecnologia
python
Domínio
backend-api-design, security

Direção de pesquisa

Leia os pontos de entrada existentes Updater.refresh(), Updater.get_valid_targetinfos(list) e Updater.download_targets(list) e, em seguida, revise o contexto de download paralelo do pip descrito na issue. Defina um escopo concreto para a API ou para a concorrência, considerando o trabalho concluído quando targets e os metadados bin puderem ser baixados em paralelo sem tornar inseguro o estado compartilhado de Updater.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.
Linguagem predominante
Python
Estrelas
1.7k
Forks
304
Merge médio
9h 25min
PRs com merge (30d)
14

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de theupdateframework/python-tuf

Todas as issues de theupdateframework/python-tuf

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.