How to Connect a Local Rust Crate Before Publishing: A Step-by-Step Guide

Online Python Trainer for Beginners

Learn Python easily without overwhelming theory. Solve practical tasks with automatic checking, get hints in Russian, and write code directly in your browser — no installation required.

Start Course

Introduction: Why a Local Crate is Not a Luxury, But a Necessity

\n\n

Imagine: you are writing a Rust library for parsing configuration files. It's still raw, not ready for publication on crates.io, but you already want to test it in a real project — an Actix web server or a CLI utility. What to do? Copy the code? Create a monorepo? No, in Rust there is an elegant solution for this — a local unpublished crate.

\n\n

The question "How to use a local unpublished crate?" has gathered thousands of views on Stack Overflow. This is no coincidence: every Rust developer sooner or later faces the need to connect their own crate that hasn't been released yet. In this article, we will cover all the methods — from simply specifying a path to working with Git dependencies and workspaces. Let's go!

\n\n

What is an Unpublished Crate and Why Do You Need It?

\n\n

An unpublished crate is a Rust package that exists only on your local disk or in a private repository. It is not uploaded to crates.io and is not available to other developers (unless you give them access to the files).

\n\n

Typical use cases:

\n
    \n
  • Developing a library in parallel with the main project
  • \n
  • Refactoring: extracting part of the code into a separate crate
  • \n
  • Private corporate libraries that cannot be published
  • \n
  • Testing dependencies before publication
  • \n
\n\n

The main advantage is that you have full control over the code and can make changes instantly without waiting for publication on crates.io.

\n\n

Method 1: Path Dependency — The Simplest and Fastest

\n\n

This is the basic method, suitable when both projects (the dependency and the dependent) are on your computer.

\n\n

Project Structure

\n\n

Let's say you have the following folder structure:

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

Step 1: Create the my_lib Library

\n\n

Inside my_lib/Cargo.toml:

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

In my_lib/src/lib.rs, let's write a simple function:

\n\n
pub fn greet(name: &str) -> String {\n    format!("Hello, {}! This is a local crate.", name)\n}
\n\n

Step 2: Connect my_lib in my_app via path

\n\n

In my_app/Cargo.toml, add the [dependencies] section:

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

Note: the path is specified relative to the main project's Cargo.toml file. If the library is in a different directory, specify an absolute or relative path.

\n\n

Step 3: Use the Crate in Code

\n\n

In my_app/src/main.rs:

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

Run: cargo run — and you will see the output: "Hello, Alexey! This is a local crate."

\n\n

Important! Any changes in my_lib will be automatically picked up the next time you build my_app. No need to reinstall or update versions.

\n\n

Method 2: Git Dependencies — For Team Collaboration

\n\n

If you work in a team or store code in Git, it's better to use Git dependencies. This is convenient when the crate is in a separate repository (even a private one).

\n\n

Setup

\n\n

Suppose your unpublished crate my_lib is in the repository https://github.com/yourname/my_lib.git

Blogs

Book Recommendations