How to develop rustic + rustic_core together locally?

[intgr]

I want to work on the two repsitories at the same time. Seems like a pretty essential thing for development? But I could not find documentation for how to do it (dev-docs nor GitHub issues/discussions).

I have two git checkouts of both rustic and rustic_core as siblings in the same parent directory. Either repo builds successfully on its own.

I thought I can just patch Cargo.toml of rustic to use the local rustic_core checkout. But with the following does not work:

 [dependencies]
 abscissa_core = { version = "0.8.1", default-features = false, features = ["application"] }
-rustic_backend = { version = "0.5.2", features = ["cli"] }
-rustic_core = { version = "0.7.2", features = ["cli"] }
+rustic_backend = { path = "../rustic_core/crates/backend", features = ["cli"] }
+rustic_core = { path = "../rustic_core/crates/core", features = ["cli"] }

• it creates a massive diff in Cargo.lock file
• upgrades to some breaking versions dependencies (derive_more v1 -> v2)
• accesses APIs that have changed to private in rustic_core (OpenFile::from_node)

Cargo build log: cargo-build.log

So how do you develop this thing?

[aawsome]

Hi @intgr
Thanks for the question. Seems we are a bit behind in rustic and current rustic_core version is not supported.
I've create #1456 (will be merged soon into main) - with these changes, using a local+recent rustic_core dependency should work.

We usually try to develop both quite independent and then release rustic_core before we bump the version in rustic...

[intgr]

Oh I see: if I check out rustic_core from the latest git tag, then this path = dependency trick works. Thanks for the quick reply.

We usually try to develop both quite independent

So how do you test that any unreleased rustic_core changes work correctly, if the code can't be invoked via CLI?

(I don't understand what benefits this repository split brings, but I can see quite a few downsides.)

[aawsome]

So how do you test that any unreleased rustic_core changes work correctly, if the code can't be invoked via CLI?

There are unit and integration tests within rustic_core. The incompatibility was mainly introduced by a dependency update (which was only automatically tested within rustic_core) and an API change (same, tested by modified integration tests).

Besides this, we test exactly like you with local dependencies :-)