Atualização de desenvolvimento do crates.io

 (blog.rust-lang.org)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Nos últimos seis meses, o crates.io introduziu um visualizador de código-fonte para inspecionar diretamente pacotes publicados e um sistema de contas independente do GitHub, além de reforçar orientações sobre segurança e substituições pela biblioteca padrão
  • A nova aba Code oferece busca de arquivos, realce de sintaxe e seleção de linhas compartilhável; usando manifestos ZIP e JSON no CDN e requisições de intervalo HTTP, carrega apenas os arquivos necessários sem sobrecarregar os servidores da API
  • De acordo com a RFC #3946, a implementação de nomes de usuário próprios do crates.io foi iniciada; após permitir mudanças de nome de usuário e passar por revisão de segurança, o plano é oferecer suporte a provedores de autenticação além do GitHub
  • O frontend foi migrado completamente de Ember.js para Svelte, e busca, consultas de dependências reversas, cache do CDN e processamento do índice Git também foram aprimorados para maior desempenho e estabilidade
  • Avisos de descontinuação de manutenção do RustSec e APIs substitutas da biblioteca padrão, como std::sync::LazyLock, agora aparecem nas páginas dos pacotes, ajudando na auditoria de dependências e na remoção de dependências desnecessárias

Visualizador de código-fonte para inspecionar pacotes publicados

  • Na nova aba Code da página do pacote, é possível navegar dentro do crates.io pelos arquivos de cada versão publicada
    • Ela mostra não o repositório vinculado, mas os arquivos que o cargo realmente baixa ao adicionar uma dependência
    • Também permite ver arquivos que não existem no repositório, como o Cargo.toml normalizado gerado pelo cargo, facilitando a auditoria de dependências
  • O visualizador oferece busca na árvore de arquivos, realce de sintaxe e seleção de linhas no estilo do GitHub
    • Ao clicar ou arrastar sobre números de linha, é gerada uma URL compartilhável no formato #L10-L20
  • O servidor gera, para todas as versões publicadas, arquivos ZIP e manifestos JSON que descrevem a composição dos arquivos
    • Como os arquivos .crate usados pelo cargo são tarballs comprimidos com gzip e não dão suporte a acesso aleatório, uma tarefa em segundo plano os reempacota como ZIPs navegáveis
    • Os ZIPs e manifestos são servidos por um CDN estático
    • O frontend primeiro recebe o manifesto e então carrega cada arquivo apenas quando necessário, por meio de requisições de intervalo HTTP
    • A navegação pelo código praticamente não adiciona carga aos servidores da API do crates.io, e versões existentes também foram processadas em lote para oferecer suporte até a releases antigas
  • A biblioteca de renderização do visualizador de código é originalmente um renderizador de diferenças, e um visualizador de comparação entre versões usando a mesma infraestrutura também está em desenvolvimento
    • Quando estiver pronto, será possível revisar no crates.io as mudanças exatas entre duas versões publicadas

Contas do crates.io independentes do GitHub

  • A equipe do crates.io aprovou no fim de maio a RFC #3946
  • Antes, o login pelo GitHub e a identidade no crates.io eram fortemente acoplados, e o nome de usuário também era determinado pela conta do GitHub; a RFC introduz nomes de usuário próprios do crates.io, independentes das contas vinculadas
  • Esse nome de usuário próprio é um pré-requisito para, no futuro, oferecer suporte a login por provedores de autenticação além do GitHub
  • A implementação já começou, mas a principal funcionalidade ainda incompleta visível aos usuários é a mudança de nome de usuário
    • Depois disso, serão conduzidas uma RFC adicional e a implementação de login por outros provedores de autenticação
    • Como isso afeta diretamente autenticação e segurança de contas, a implantação será feita lentamente, em etapas pequenas e cuidadosamente revisadas

Avisos de segurança e orientações de substituição pela biblioteca padrão

  • A aba Security existente mostra avisos de segurança do banco de dados RustSec, e agora pacotes marcados pelo RustSec como sem manutenção também exibem um banner de alerta no topo da página
    • Pelo banner, é possível acessar o aviso correspondente, com detalhes e possíveis alternativas
  • Pacotes cuja funcionalidade foi incorporada à biblioteca padrão exibem o banner “You might not need this dependency”
    • Por exemplo, lazy_static pode ser substituído por std::sync::LazyLock desde o Rust 1.80
    • Na lista de dependências, pacotes substituídos recebem um pequeno ícone de lâmpada com a mesma orientação
  • Os dados relacionados são mantidos no novo repositório rust-lang/std-replacement-data
    • Somente entradas de substituição pela biblioteca padrão são permitidas
    • Todas as entradas devem citar as APIs estabilizadas de std, core ou alloc e a respectiva versão do Rust
    • Antes de adicionar uma entrada, o mantenedor do pacote deve ser avisado e receber um prazo para dar opinião
    • Novas entradas podem ser propostas no repositório, e os dados acumulados também podem ser aproveitados por outras ferramentas

Migração do frontend para Svelte concluída

  • O experimento de migrar o frontend do crates.io de Ember.js para Svelte foi concluído com sucesso
    • O novo frontend alcançou paridade com as funcionalidades existentes
    • Após um teste público em abril, ele passou a ser o frontend padrão no início de maio
    • A aplicação Ember.js foi removida do repositório
  • A migração foi uma conversão um-para-um, preservando o design e as funcionalidades existentes para que os usuários não percebessem mudanças
  • A equipe e os contribuidores agora podem usar um framework moderno, reduzindo a barreira de entrada para novos contribuidores e aumentando a velocidade de iteração; o visualizador de código-fonte é um exemplo disso
  • A equipe agradece tanto ao Ember.js, usado pelo crates.io por muitos anos, quanto à equipe do Svelte, que apoiou a transição

Página de erro com Ferris

  • O Ferris nas páginas de erro do crates.io agora segue o cursor do mouse com os olhos
  • Mesmo na página de erro 404, há uma pequena interação

Desempenho da busca e das consultas de dependências reversas

  • A busca ordenada por relevância antes calculava a classificação de todos os pacotes que correspondiam ao termo pesquisado, o que podia levar 1 a 2 segundos em buscas curtas ou comuns
    • Agora, o cálculo de ranking é limitado aos 1.000 pacotes correspondentes com mais downloads recentes
  • O endpoint de dependências reversas não recalcula mais o conjunto completo de pacotes dependentes a cada requisição
    • Os resultados são servidos a partir de uma tabela pré-calculada sincronizada por triggers do banco de dados
    • Joins caros foram substituídos por varreduras de índice limitadas, reduzindo bastante a possibilidade de timeout

Documentação de arquitetura e renderização de Markdown

  • O ARCHITECTURE.md foi totalmente reformulado, com foco nos sistemas de alto nível do crates.io e em como eles se interconectam
    • O processo que ocorre ao executar cargo publish
    • Por que downloads comuns de pacotes não passam pelo servidor da API
    • Como a contagem de downloads é calculada a partir dos logs de acesso do CDN
  • O README agora renderiza listas de definição, uma extensão de Markdown amplamente usada
    • O renderizador de Markdown comrak já oferecia suporte a listas de definição, mas essa extensão não estava ativada

Melhoria da eficiência do cache do CDN

  • Foram adicionados metadados de tags de cache aos arquivos enviados ao CDN estático
    • Em vez de enviar solicitações de invalidação individuais para cada URL de arquivo, agora é possível invalidar de uma só vez todos os arquivos em cache de um pacote ou release específico
  • O cabeçalho de resposta global Vary: Cookie, que prejudicava o cache no CDN de respostas da API pública e de assets do frontend, foi removido
    • Para respostas específicas por usuário, aplica-se agora Cache-Control: no-store
    • Como resultado, a taxa de acerto do cache nas bordas do CDN melhorou

Acessibilidade e processamento do índice Git

  • A acessibilidade do crates.io foi melhorada para usuários de leitores de tela
    • Ícones decorativos foram ocultados da árvore de acessibilidade
    • A hierarquia de títulos foi corrigida
    • A marcação correta de listas foi aplicada às listas
    • Testes de snapshot ARIA foram introduzidos para evitar que regressões sejam incorporadas sem detecção
    • A acessibilidade continuará sendo aprimorada nos próximos meses
  • A cópia local do índice Git dos workers em segundo plano foi alterada para um repositório bare e shallow
    • Cerca de 250 mil arquivos de checkout e todo o histórico de commits foram removidos do disco
    • Isso melhora o desempenho do processamento em um contexto de aumento da frequência de publicação de pacotes
  • O squash periódico do índice agora usa a API do GitHub em vez de gerar grandes Git packs localmente
    • O método anterior de geração local de packs já causou falta de memória em workers de produção

Canais de feedback

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Opiniões no Lobste.rs

  • É bom ver que está em andamento o trabalho para desvincular as contas do crates.io do GitHub

    • Antigamente, eu gostava da possibilidade de fazer login em vários serviços com a conta do GitHub, mas agora isso parece menos atraente. Como o Tailscale oferece suporte a provedores de identidade OIDC, configurei o login usando o Codeberg e o WebFinger do meu domínio
      Para fazer login com o e-mail do próprio domínio, example@example.com, coloque em https://example.com/.well-known/webfinger um arquivo JSON cujo subject seja acct:example@example.com e cujo href do emissor OpenID Connect seja https://codeberg.org
      Nas configurações do Codeberg, basta criar uma aplicação OAuth2 com o URI de redirecionamento https://login.tailscale.com/a/oauth_response e depois inserir no Tailscale o Client ID e o Client Secret emitidos. Parece que, no futuro, o crates.io também oferecerá algo parecido

  • Eu não sabia que as melhorias no crates.io tinham sido tão grandes recentemente. Normalmente eu procurava primeiro no lib.rs, mas talvez meu hábito mude em breve; a mudança de que mais gostei foi o Ferris

    • Fico curioso para saber quanto dessas melhorias se deve à adoção de agentes

  • A mudança nos olhos do Ferris não faz muito sentido fisicamente. As partes brancas nos olhos pretos são realces de reflexão especular; se o cursor do mouse for a fonte de luz, fica difícil dizer que a representação mostra os olhos seguindo o cursor

  • Ao auditar dependências, primeiro crio um link simbólico de ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ para ~/cargosrc, para acessar facilmente os arquivos baixados pelo Cargo
    Para cada dependência a auditar, clono o repositório Git, faço checkout da versão-alvo, apago localmente os arquivos rastreados e envio SIGSTOP ao processo do rust-analyzer. Adiciono a dependência ao Cargo.toml do projeto, executo cargo fetch e então copio o conteúdo do diretório $dependency-$version baixado para o repositório clonado, faço commit e examino as diferenças em um visualizador de histórico Git
    Ao terminar a revisão, salvo por script a combinação de dependência, versão e hash do Cargo.lock em um banco de dados confiável, para não verificar a mesma versão novamente. Embora o procedimento pareça complicado, automatizei a maior parte dele, então é mais eficiente do que uma UI web; seria bom se o Cargo oferecesse suporte a esse fluxo de revisão na linha de comando. Também fico curioso se existe algum plugin que ajude na revisão em si, mais do que ferramentas como o cargo-crev

  • A implementação em que o frontend busca apenas o manifesto e depois carrega cada arquivo sob demanda por meio de requisições HTTP de intervalo está aqui e usa o DecompressionStream nativo do navegador