Managing Your Own Dependencies
Cargo is pretty smart, and gives you some options for how you want dependencies to work within your own repo(s).
Option 1: Publish Everything!
If you really want to, you can use cargo publish
(after filling out all of the crate metadata) to make your crates public. You should only do this:
- If you actually want your crate to be public. The source code will be published, too.
- You have a license policy ready to go.
- Your crate offers something useful to the community. Let's not get into a
left-pad
situation.
For your company's pride and joy---a product you make money from---this is often not the best choice. In fact, your manager may be quite upset if you accidentally MIT license your core product.
Option 2: Separate Git Repos Per Project
Cargo can handle dependencies directly from git
. For example, you can use bracket-lib
(a library I created for Hands-on Rust) from Github directly:
bracket_lib = { git = "https://github.com/amethyst/bracket-lib.git" }
You can tell it to use a specific branch:
bracket_lib = { git = "https://github.com/amethyst/bracket-lib.git", branch = "bevy" }
Now, when you run cargo update
---Cargo pulls the latest version from the repo and uses it.
Paths within Git Repos
Cargo supports committing a workspace or series of projects to the same repo. The committed repos can refer to one another with relative paths:
bracket_lib = { path = "../bracket_lib" }
If you then link to that git repo, dependencies within the repo are pulled correctly.
Option 3: Mono-Repos
Using the path =
system within the mono-repo works great. You can mix and match a bit, having some git repos, some cargo/crates.io repos, and some path repos.
Option 4: File Server
If you all mount a directory you can share code that way. The downside is that git ownership becomes quite confusing.
Overriding Dependencies
Let's say that Team B has created a crate, and you are happily depending upon it. Down the line, Team A want to test the dependency from Team B---but they want to replace a dependency throughout the project with a new version (maybe to see if a patch works).
You can do this with cargo patches. For example, if you decide to use your own uuid
crate---you can add this to Cargo.toml
:
[patch.crates-io]
uuid = { path = "../path/to/uuid" }
Be warned that you can't publish (to crates.io) any crates that specify a patch.