Como conectar um crate Rust local antes da publicação: guia passo a passo

Introdução: por que um crate local não é um luxo, mas uma necessidade

Imagine: você está escrevendo em Rust uma biblioteca para analisar arquivos de configuração. Ela ainda está crua, não pronta para publicação no crates.io, mas você já quer testá-la em um projeto real — um servidor web em Actix ou um utilitário CLI. O que fazer? Copiar o código? Criar um monorepositório? Não, em Rust existe uma solução elegante para isso — o crate local não publicado.

A pergunta "How to use a local unpublished crate?" reuniu milhares de visualizações no Stack Overflow. Não é por acaso: todo desenvolvedor Rust, mais cedo ou mais tarde, enfrenta a necessidade de conectar seu próprio crate que ainda não foi lançado. Neste artigo, abordaremos todas as formas — desde a simples indicação do caminho até o trabalho com dependências Git e workspaces. Vamos lá!

O que é um unpublished crate e para que serve?

Unpublished crate (crate não publicado) é um pacote Rust que existe apenas no seu disco local ou em um repositório privado. Ele não está carregado no crates.io e não está disponível para outros desenvolvedores (a menos que você lhes dê acesso aos arquivos).

Cenários típicos de uso:

\n
• Desenvolvimento de uma biblioteca em paralelo com o projeto principal
\n
• Refatoração: você separa parte do código em um crate separado
\n
• Bibliotecas corporativas privadas que não podem ser publicadas
\n
• Teste de dependências antes da publicação
\n

A principal vantagem é que você obtém controle total sobre o código e pode fazer alterações instantaneamente, sem esperar pela publicação no crates.io.

Método 1: Path dependency — o mais simples e rápido

Este é o método básico, adequado quando ambos os projetos (dependência e dependente) estão no seu computador.

Estrutura do projeto

Suponha que você tenha a seguinte estrutura de pastas:

my_project/\n├── my_lib/          # unpublished crate\n│   ├── Cargo.toml\n│   └── src/\n│       └── lib.rs\n└── my_app/          # projeto principal\n    ├── Cargo.toml\n    └── src/\n        └── main.rs

Passo 1: Criar a biblioteca my_lib

Dentro de my_lib/Cargo.toml:

[package]\nname = "my_lib"\nversion = "0.1.0"\nedition = "2021"\n\n[dependencies]

Em my_lib/src/lib.rs escrevemos uma função simples:

pub fn greet(name: &str) -> String {\n    format!("Olá, {}! Este é um crate local.", name)\n}

Passo 2: Conectar my_lib em my_app via path

Em my_app/Cargo.toml adicionamos a seção [dependencies]:

[package]\nname = "my_app"\nversion = "0.1.0"\nedition = "2021"\n\n[dependencies]\nmy_lib = { path = "../my_lib" }

Observe: o caminho é indicado em relação ao arquivo Cargo.toml do projeto principal. Se a biblioteca estiver em outro diretório, indique o caminho absoluto ou relativo.

Passo 3: Usar o crate no código

Em my_app/src/main.rs:

use my_lib::greet;\n\nfn main() {\n    let message = greet("Alexandre");\n    println!("{}", message);\n}

Execute: cargo run — e veja a saída: "Olá, Alexandre! Este é um crate local."

Importante! Quaisquer alterações em my_lib serão automaticamente captadas na próxima compilação de my_app. Não é necessário reinstalar ou atualizar versões.

Método 2: Dependências Git — para trabalho em equipe

Se você trabalha em equipe ou armazena o código no Git, é melhor usar dependências Git. Isso é conveniente quando o crate está em um repositório separado (mesmo privado).

Configuração

Suponha que seu crate não publicado my_lib esteja no repositório https://github.com/seunome/my_lib.git