Problem: Given the following folder structure

project
└── project2

If I want to patch project2 into project, the command would be

diener patch --target something --crates-to-patch project/project2 --path project/Cargo.toml

The problem is that references to project2 end up as absolute paths rather than the relative path from project, i.e. { path = "/full/path/to/project2" } rather than { path = "project2" } (relative path)

The example of nested directories might be a bit unintuitive but this could also be desirable for use-cases where repositories are positioned relative to each other, for instance both projects within the same folder.

folder
├── project
└── project2

Motivation: sometimes it's necessary to transfer projects to a different host after patching, so absolute paths stop working after the transfer unless they can be recreated exactly as they were before the transfer. In those cases it's preferrable to have relative paths as it's easier to make them work that way in the new host.

Solution: introduce an option to make path patches relative to the patched directory, e.g.

diener --target something --relative-crates-to-patch --crates-to-patch project/project2 --path project/Cargo.toml

https://rustacean-station.org/episode/rust-1.62-1.63-1.64/ talks about cargo-add being included in cargo itself now, and it's deps that might be relevant to this repo:

• https://crates.io/crates/toml_edit used here already, but a lot newer versions exists
• https://github.com/killercup/cargo-edit newer, at a glance seems worth a look for perhaps better/easier format preserving changes to things in toml files.

So this issue is more of a question: can these tools help make dealing with modifying Cargo files in diener easier/better?

This could be in the form of a new check command or based on update with a new --dry-run flag.
The goal is to be able to check whether a project is up to date without having to touch the .lock file.

would be great if when running metadata takes a long time, to give a hint that it has not just hung.

E.g. running it against master of https://github.com/AcalaNetwork/Acala.git for patching substrate.
(I think this is aggravated by substrate repo getting fat)

If I point diener at a particular cumulus then whatever version of polkadot that that cumulus is pointing to must be also patched / updated to. And that polkadot is referring to a version of substrate so that also needs to be patched / updated to. ( The point is by doing diener patch --crates-to-patch ../cumulus --cumulus for example there's no choice in which polkadot or substrate version to use, it must be whatever polkadot and substrate branch/path that ../cumulus is pointing to)

This would make diener a joy to use and would remove the tedium of running the command 2 - 3 times with different arguments.

(feel free to bikeshed the flag name...)

Currently the sections like [target.'cfg(target_arch="x86_64")'.dependencies] are not handled, it's a great addition as this syntax is already used in the substrate repo IMO. I'll see if I can find some time to support this :P.

Hey @bkchr! This is a super-convenient tool for updating Substrate, Polkadot and Beefy dependencies, thanks for sharing it. The only addition that I believe would make it perfect for my use case is the Cumulus support. Have you considered adding the updaing/patching functionality for cumulus crates? Would you review the PR if I try to implement this? Thank you

As corroborated by https://gitlab.parity.io/parity/mirrors/polkadot/-/jobs/1577990#L521 and reproducible by the steps of paritytech/pipeline-scripts#45 (comment), diener doesn't patch all crates in a repository.

As an example polkadot-node-core-pfv (https://github.com/paritytech/polkadot/blob/f8b668b7540eaac106765a978c17af533d261f8e/node/core/pvf/Cargo.toml) for which there was no Adding patch for polkadot-node-core-pfv log line in the GitLab job and it also doesn't show up in the patch entries as demonstrated by the diff of paritytech/pipeline-scripts#45 (comment). Outdated, see #15 (comment).

From cursory look at the code I think this is where the crates are detected, but I haven't dug deeper into that to know the cause of why some crates are missed.

https://github.com/bkchr/diener/blob/69ab0f76fb851968af8e493061cca84a2f3b1c5b/src/patch.rs#L236-L255

The description and readme haven't been updated to account for the monorepo structure: