3

I am creating a library, that is nearly close to its first release, so I would like to upload it to crates.io. Library has a multi-crate design, so I ended with something like:

- CrateA
- CrateProcMacros
- CrateC
- CrateD
- CrateE
- CrateF
- Cargo.toml (handles the workspace)
- Cargo.lock
...

where CrateA is the parent of the other crates, and has dependencies on another of those local crates, and some of those crates also depends on another ones. I mean, it's the primary crate of the library, the one responsible for exposing the public API of the project, and the unique one that I would like to be published in crates.io.

Reading the cargo docs I am seeing that I won't be able to publish a unique crate to the registry. All will be uploaded and published.

So, what alternatives I have to only publish my CrateA to the registry? Should I change my project's structure, and move to CrateA all the other packages and then try to publish it? Or there's some way to achieve this?

EDIT

CrateA have direct dependencies on another crates. An those others also depends on another one inside my workspace.

Alex Vergara
  • 1,766
  • 1
  • 10
  • 29
  • 1
    Whatever you do, don't change the structure of your project. You chose it for some reason. It is more important than packaging. From what I remember you must publish each crate separately. – Aleksander Krauze Nov 02 '22 at 09:32

2 Answers2

2

The way Cargo packaging works is that you are publishing your source code nearly unchanged. There is no pre-compilation step. There is no step where multiple library crates are gathered into one package. The only way to publish your CrateA is to publish all of its dependencies too.

There is interest in making a multi-crate project easier to publish, but for now, you've got to do it all explicitly.

  1. Make sure each package in your project declares a [package] name that makes sense in public. (The name of the directory you keep it in doesn't matter.) It's common to have names like myproject-partoftheproject, where the package people actually use normally would be named myproject.

  2. Make sure that each dependency declaration has a version number (not just a path) matching what you're going to publish. (You don't have to remove the path; that will be done for you within publication.)

  3. Publish each package. You must do this in reverse dependency order — that is, CrateA last.

No one will mind that you've published extra packages that aren't meant for direct use — for example, lots of libraries necessarily have separate proc-macro packages. Though, if you have any crates that are really just for code organization and don't have any particular benefit, you could consider making them into modules inside fewer crates.

Kevin Reid
  • 37,492
  • 13
  • 80
  • 108
-2

master Cargo.toml should be like this

[workspace]
members = [
    "CrateA",
    "CrateB",
    ...
]

And CrateA/Cargo.toml should be like this

[package]
name = "Foo"
version = "0.0.0"
edition = "2021"
authors = ["Foo <Foo@gmail.com>"]
license = "Bar"
description = "Baz"
[dependencies]
CrateB = { path = "../CrateB", version = "0.0.0" }
CrateC = "0.0.0"
Eveheeero
  • 52
  • 5