Comment connecter une crate Rust locale avant publication : guide étape par étape

Introduction : pourquoi une crate locale n'est pas un luxe, mais une nécessité

Imaginez : vous écrivez en Rust une bibliothèque pour analyser des fichiers de configuration. Elle est encore brute, pas prête à être publiée sur crates.io, mais vous voulez déjà la tester dans un projet réel — un serveur web sur Actix ou un utilitaire CLI. Que faire ? Copier le code ? Créer un monorepo ? Non, en Rust il existe une solution élégante — une crate locale non publiée.

La question "How to use a local unpublished crate?" a rassemblé des milliers de vues sur Stack Overflow. Ce n'est pas un hasard : chaque développeur Rust rencontre tôt ou tard le besoin de connecter sa propre crate qui n'est pas encore sortie. Dans cet article, nous allons passer en revue toutes les méthodes — de la simple indication de chemin au travail avec les dépendances Git et les espaces de travail. C'est parti !

Qu'est-ce qu'une crate non publiée et pourquoi en a-t-on besoin ?

Unpublished crate (crate non publiée) est un paquet Rust qui n'existe que sur votre disque local ou dans un dépôt privé. Il n'est pas téléchargé sur crates.io et n'est pas accessible aux autres développeurs (sauf si vous leur donnez accès aux fichiers).

Scénarios d'utilisation typiques :

\n
• Développement d'une bibliothèque en parallèle du projet principal
\n
• Refactorisation : vous extrayez une partie du code dans une crate séparée
\n
• Bibliothèques d'entreprise privées qui ne peuvent pas être publiées
\n
• Test des dépendances avant publication
\n

Le principal avantage est que vous avez un contrôle total sur le code et pouvez apporter des modifications instantanément, sans attendre la publication sur crates.io.

Méthode 1 : Dépendance de chemin — la plus simple et la plus rapide

C'est la méthode de base, adaptée lorsque les deux projets (dépendance et dépendant) se trouvent sur votre ordinateur.

Structure du projet

Supposons que vous ayez la structure de dossiers suivante :

my_project/\n├── my_lib/          # crate non publiée\n│   ├── Cargo.toml\n│   └── src/\n│       └── lib.rs\n└── my_app/          # projet principal\n    ├── Cargo.toml\n    └── src/\n        └── main.rs

Étape 1 : Créer la bibliothèque my_lib

Dans my_lib/Cargo.toml :

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

Dans my_lib/src/lib.rs, écrivons une fonction simple :

pub fn greet(name: &str) -> String {\n    format!("Bonjour, {} ! C'est une crate locale.", name)\n}

Étape 2 : Connecter my_lib dans my_app via le chemin

Dans my_app/Cargo.toml, ajoutez la section [dependencies] :

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

Notez : le chemin est indiqué par rapport au fichier Cargo.toml du projet principal. Si la bibliothèque se trouve dans un autre répertoire, indiquez un chemin absolu ou relatif.

Étape 3 : Utiliser la crate dans le code

Dans my_app/src/main.rs :

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

Lancez : cargo run — et vous verrez la sortie : "Bonjour, Alexandre ! C'est une crate locale."

Important ! Toute modification dans my_lib sera automatiquement prise en compte lors de la prochaine compilation de my_app. Pas besoin de réinstaller ou de mettre à jour les versions.

Méthode 2 : Dépendances Git — pour le travail en équipe

Si vous travaillez en équipe ou stockez le code dans Git, il est préférable d'utiliser les dépendances Git. C'est pratique lorsque la crate se trouve dans un dépôt séparé (même privé).

Configuration

Supposons que votre crate non publiée my_lib se trouve dans le dépôt https://github.com/yourname/my_lib.git