Cómo conectar un crate local de Rust antes de publicarlo: guía paso a paso

Introducción: por qué un crate local no es un lujo, sino una necesidad

Imagine: está escribiendo en Rust una biblioteca para analizar archivos de configuración. Todavía está en desarrollo, no está lista para publicarse en crates.io, pero ya quiere probarla en un proyecto real: un servidor web en Actix o una utilidad CLI. ¿Qué hacer? ¿Copiar el código? ¿Crear un monorepositorio? No, en Rust existe una solución elegante para esto: el crate local no publicado.

La pregunta "How to use a local unpublished crate?" ha acumulado miles de visitas en Stack Overflow. No es casualidad: todo desarrollador de Rust, tarde o temprano, se enfrenta a la necesidad de conectar su propio crate que aún no ha sido lanzado. En este artículo, analizaremos todas las formas: desde simplemente especificar la ruta hasta trabajar con dependencias Git y workspaces. ¡Allá vamos!

¿Qué es un unpublished crate y para qué sirve?

Un unpublished crate (crate no publicado) es un paquete de Rust que existe solo en su disco local o en un repositorio privado. No está cargado en crates.io ni está disponible para otros desarrolladores (a menos que les dé acceso a los archivos).

Escenarios de uso típicos:

\n
• Desarrollar una biblioteca en paralelo con el proyecto principal
\n
• Refactorización: extraer parte del código en un crate separado
\n
• Bibliotecas corporativas privadas que no se pueden publicar
\n
• Probar dependencias antes de publicarlas
\n

La principal ventaja es que obtiene control total sobre el código y puede realizar cambios al instante, sin esperar la publicación en crates.io.

Método 1: Path dependency — el más simple y rápido

Este es el método básico, adecuado cuando ambos proyectos (dependencia y dependiente) están en su computadora.

Estructura del proyecto

Supongamos que tiene la siguiente estructura de carpetas:

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

Paso 1: Crear la biblioteca my_lib

Dentro de my_lib/Cargo.toml:

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

En my_lib/src/lib.rs escribimos una función simple:

pub fn greet(name: &str) -> String {\n    format!("¡Hola, {}! Este es un crate local.", name)\n}

Paso 2: Conectar my_lib en my_app mediante path

En my_app/Cargo.toml agregamos la sección [dependencies]:

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

Tenga en cuenta: la ruta se especifica en relación con el archivo Cargo.toml del proyecto principal. Si la biblioteca está en otro directorio, indique la ruta absoluta o relativa.

Paso 3: Usar el crate en el código

En my_app/src/main.rs:

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

Ejecutamos: cargo run — y vemos la salida: "¡Hola, Alejandro! Este es un crate local."

¡Importante! Cualquier cambio en my_lib se recogerá automáticamente en la próxima compilación de my_app. No es necesario reinstalar ni actualizar versiones.

Método 2: Dependencias Git — para trabajo en equipo

Si trabaja en equipo o almacena el código en Git, es mejor usar dependencias Git. Esto es útil cuando el crate está en un repositorio separado (incluso privado).

Configuración

Supongamos que su crate no publicado my_lib está en el repositorio https://github.com/yourname/my_lib.git