Hi, I am trying to figure out how setup rust projects in a team. Let's say we have several projects/applications/programs that are mostly independent of each other. Since the built applications need to communicate, they are not complete independent, but share some types (which can also evolve).
Problems we had so far (not with rust, we don't use it yet):
Incompatible versions in production
If one system falls behind in version (maybe because a newer version needs newer hardware), it can be hard to update and maintain older versions
My questions are:
How would you setup these projects to manage the dependencies?
Is cargo the right tool for that? Will it work if some dependencies are not written in rust?
Cargo's workspaces sound applicable. In which case I would use a monorepo.
Not sure what exactly you are asking here. If you want to link some C library, you can definitely still use Cargo as you build system. I'm not too familiar with FFI in Rust though, so I can't say if/when Cargo becomes inapplicable for more complex scenarios.
To share types only, I have to create an additional (shared) package, since a package can only have one lib crate. Then I can share the package with a monorepo or a git remote, right?
Sorry, let me rephrase: With dependencies I meant already existing projects that are written for example in c++. A new rust project might depend on a specific version of that in production. So the question is if I can (mis)use cargo as general dependency management / build tool. I guess, if I add a cargo.toml and build.rs to an existing c++ project, I can build all projects in a single workspace, right? Is that a good idea, though?
A package can only have on lib crate, that's correct. You can share it via monorepo, git remote, just some other git repository you have read access to, vendored, or via a registry like crates.io or your own private registry. See the specifying dependencies section of the Cargo book.
Like I said, I never had to deal with complex FFI settings and I don't maintain a *-sys crate, so my knowledge of when Cargo becomes unfeasible here is limited. You can definitely use build scripts to build a shared library and link it into your Cargo project. There are also great tools to ease the burden of FFIs like cxx and safer-ffi. You can also extend Cargo easily to support your custom workflows, i.e. see the xtask model.
