Gerenciamento de Dependências

Projetos Rust saudáveis fixam grafos de dependência reproduzíveis, atualizam deliberadamente dentro do semver e auditam vulnerabilidades conhecidas.

Receita

cargo update -p serde
cargo tree -i openssl
cargo audit
cargo deny check

Quando usar isso: Manutenção semanal, antes de lançamentos ou após um aviso de segurança.

Exemplo de Trabalho

Fluxo de trabalho de manutenção de workspace:

# Veja o que mudaria
cargo update --dry-run
 
# Atualiza um crate dentro dos limites do semver no Cargo.lock
cargo update -p tokio
 
# Descubra por que um crate está no grafo
cargo tree -i ring
 
# Verificação de segurança (instalar: cargo install cargo-audit)
cargo audit
 
# Detecção de licença + proibição + duplicatas
cargo deny check

# deny.toml (excerto)
[bans]
multiple-versions = "warn"
 
[sources]
unknown-registry = "deny"

O que isso demonstra:

cargo update atualiza Cargo.lock, não necessariamente os requisitos de versão do Cargo.toml
cargo tree -i encontra dependências reversas (quem puxa openssl?)
cargo audit compara o lockfile com o banco de dados de avisos do RustSec
cargo-deny impõe políticas de licença e dependência em CI

Análise Profunda

Semver na Prática

Mudança	Atualização
Correção de bug, mesma API	PATCH
Nova API compatível com versões anteriores	MINOR
Quebra da API pública	MAJOR

serde = "1.0.210"   # permite 1.0.x compatíveis
my_lib = "=2.1.0"   # fixação exata quando necessário

Minimizando o Grafo

cargo tree --edges normal --depth 2
cargo udeps   # dependências não utilizadas (ferramenta nightly)

Remova features não utilizadas para descartar crates transitórios
Prefira crates com poucas dependências para reduzir a superfície de segurança
[workspace.dependencies] do Workspace mantém as versões alinhadas

Higiene da Cadeia de Suprimentos

Fixe o registro para crates.io (padrão)
Revise novas dependências: manutenção, uso de unsafe, fator de ônibus (bus factor)
Habilite Dependabot ou automação cargo update com portões de CI

Armadilhas

cargo update sem CI - quebra builds em clones recentes até que o lock seja commitado. Correção: sempre comite alterações no lockfile com testes passando.
Ignorar versões duplicadas - dois syn majors inflacionam o tempo de compilação. Correção: cargo tree -d e unifique através de atualizações de dependência ou [patch].
Auditar apenas no lançamento - avisos chegam no meio do sprint. Correção: job semanal de cargo audit.
Pânico de crate yanked - lockfiles antigos podem referenciar versões yanked. Correção: cargo update -p affected imediatamente.
Dependências Git sem rev - branch flutuante quebra a reprodutibilidade. Correção: fixe rev, tag ou branch com commit travado no lockfile.

Alternativas

Alternativa	Usar Quando	Não Usar Quando
`cargo-outdated`	Ver versões mais novas disponíveis	Você precisa de atualização apenas do lockfile
`[patch.crates-io]`	Fork de emergência	Estratégia de dependência de longo prazo
Diretório de fornecedor (`cargo vendor`)	Builds offline (air-gapped)	CI normal com conexão à internet

FAQs

O cargo update altera o Cargo.toml?

Não, apenas o Cargo.lock (a menos que você use ferramentas que editem manifestos). Atualize os requisitos no Cargo.toml manualmente ao adotar novas versões principais.

Como fixo todas as dependências exatamente?

Raramente desejável. Para aplicativos, comite Cargo.lock. Para fixações exatas, use requisitos de versão = por crate.

O que é um crate yanked?

crates.io marca releases quebrados como yanked; novas resoluções os evitam, mas lockfiles existentes ainda podem referenciá-los até serem atualizados.

Como permito versões duplicadas temporariamente?

Documente em ADR, defina cargo deny para avisar e agende a unificação. Algumas pilhas de proc-macro precisam temporariamente de duas versões de syn.

Devo usar dependências git?

Apenas para patches não lançados. Prefira releases de crates.io com semver para serviços de produção.

Com que frequência devo atualizar?

Atualização semanal de minor/patch com CI; upgrades principais planejados com revisão do changelog e PR dedicado.

Quais licenças são comuns?

Licença dupla MIT OU Apache-2.0 é o padrão. Execute cargo deny check licenses antes de enviar produtos comerciais.

Como removo uma dependência?

Exclua do Cargo.toml, execute cargo build para atualizar o lock e pesquise no codebase por imports.

Posso automatizar atualizações?

Sim: Dependabot, Renovate ou PRs cargo update roteirizados com portão cargo test --workspace.

Como os avisos afetam as dependências transitivas?

Você pode precisar de cargo update -p transitive ou [patch] até que o upstream lance uma correção. Rastreie IDs do RustSec em notas de incidentes.

Relacionados

Cargo.toml Explicado - sintaxe de versão
Workspaces - tabelas de dependência compartilhadas
Segurança da Cadeia de Suprimentos - política mais ampla
Melhores Práticas do Cargo - checklist de manutenção

Versões da Pilha: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.

Gerenciamento de Dependências

Projetos Rust saudáveis fixam grafos de dependência reproduzíveis, atualizam deliberadamente dentro do semver e auditam vulnerabilidades conhecidas.

Receita

cargo update -p serde
cargo tree -i openssl
cargo audit
cargo deny check

Quando usar isso: Manutenção semanal, antes de lançamentos ou após um aviso de segurança.

Exemplo de Trabalho

Fluxo de trabalho de manutenção de workspace:

# Veja o que mudaria
cargo update --dry-run
 
# Atualiza um crate dentro dos limites do semver no Cargo.lock
cargo update -p tokio
 
# Descubra por que um crate está no grafo
cargo tree -i ring
 
# Verificação de segurança (instalar: cargo install cargo-audit)
cargo audit
 
# Detecção de licença + proibição + duplicatas
cargo deny check

# deny.toml (excerto)
[bans]
multiple-versions = "warn"
 
[sources]
unknown-registry = "deny"

O que isso demonstra:

cargo update atualiza Cargo.lock, não necessariamente os requisitos de versão do Cargo.toml
cargo tree -i encontra dependências reversas (quem puxa openssl?)
cargo audit compara o lockfile com o banco de dados de avisos do RustSec
cargo-deny impõe políticas de licença e dependência em CI

Análise Profunda

Semver na Prática

Mudança	Atualização
Correção de bug, mesma API	PATCH
Nova API compatível com versões anteriores	MINOR
Quebra da API pública	MAJOR

serde = "1.0.210"   # permite 1.0.x compatíveis
my_lib = "=2.1.0"   # fixação exata quando necessário

Minimizando o Grafo

cargo tree --edges normal --depth 2
cargo udeps   # dependências não utilizadas (ferramenta nightly)

Remova features não utilizadas para descartar crates transitórios
Prefira crates com poucas dependências para reduzir a superfície de segurança
[workspace.dependencies] do Workspace mantém as versões alinhadas

Higiene da Cadeia de Suprimentos

Fixe o registro para crates.io (padrão)
Revise novas dependências: manutenção, uso de unsafe, fator de ônibus (bus factor)
Habilite Dependabot ou automação cargo update com portões de CI

Armadilhas

cargo update sem CI - quebra builds em clones recentes até que o lock seja commitado. Correção: sempre comite alterações no lockfile com testes passando.
Ignorar versões duplicadas - dois syn majors inflacionam o tempo de compilação. Correção: cargo tree -d e unifique através de atualizações de dependência ou [patch].
Auditar apenas no lançamento - avisos chegam no meio do sprint. Correção: job semanal de cargo audit.
Pânico de crate yanked - lockfiles antigos podem referenciar versões yanked. Correção: cargo update -p affected imediatamente.
Dependências Git sem rev - branch flutuante quebra a reprodutibilidade. Correção: fixe rev, tag ou branch com commit travado no lockfile.

Alternativas

Alternativa	Usar Quando	Não Usar Quando
`cargo-outdated`	Ver versões mais novas disponíveis	Você precisa de atualização apenas do lockfile
`[patch.crates-io]`	Fork de emergência	Estratégia de dependência de longo prazo
Diretório de fornecedor (`cargo vendor`)	Builds offline (air-gapped)	CI normal com conexão à internet

FAQs

O cargo update altera o Cargo.toml?

Não, apenas o Cargo.lock (a menos que você use ferramentas que editem manifestos). Atualize os requisitos no Cargo.toml manualmente ao adotar novas versões principais.

Como fixo todas as dependências exatamente?

Raramente desejável. Para aplicativos, comite Cargo.lock. Para fixações exatas, use requisitos de versão = por crate.

O que é um crate yanked?

crates.io marca releases quebrados como yanked; novas resoluções os evitam, mas lockfiles existentes ainda podem referenciá-los até serem atualizados.

Como permito versões duplicadas temporariamente?

Documente em ADR, defina cargo deny para avisar e agende a unificação. Algumas pilhas de proc-macro precisam temporariamente de duas versões de syn.

Devo usar dependências git?

Apenas para patches não lançados. Prefira releases de crates.io com semver para serviços de produção.

Com que frequência devo atualizar?

Atualização semanal de minor/patch com CI; upgrades principais planejados com revisão do changelog e PR dedicado.

Quais licenças são comuns?

Licença dupla MIT OU Apache-2.0 é o padrão. Execute cargo deny check licenses antes de enviar produtos comerciais.

Como removo uma dependência?

Exclua do Cargo.toml, execute cargo build para atualizar o lock e pesquise no codebase por imports.

Posso automatizar atualizações?

Sim: Dependabot, Renovate ou PRs cargo update roteirizados com portão cargo test --workspace.

Como os avisos afetam as dependências transitivas?

Você pode precisar de cargo update -p transitive ou [patch] até que o upstream lance uma correção. Rastreie IDs do RustSec em notas de incidentes.

Relacionados

Cargo.toml Explicado - sintaxe de versão
Workspaces - tabelas de dependência compartilhadas
Segurança da Cadeia de Suprimentos - política mais ampla
Melhores Práticas do Cargo - checklist de manutenção

Versões da Pilha: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.

Gerenciamento de Dependências

Buscar na documentação

Gerenciamento de Dependências