Are Rust workspaces in sub-directories supported?

[cdata]

Hello,

TL;DR how do you tell release-please that a Rust workspace is in a sub-directory of the project?

I'm trying to set up a release-please flow for my Rust project. My project is set up with a workspace manifest in a sub-directory of the repository (e.g., rust/Cargo.toml), and that manifest references several additional directories below it as workspace member crates.

I've tried to use --path to specify that my project is in the sub-directory, but I think I must be using it incorrectly because it doesn't seem to work.

Here is an example of what I have tried:

npx release-please \
  release-pr \
  --token $TOKEN \
  --release-type rust \
  --repo-url https://github.com/cdata/noosphere \
  --package-name noosphere \
  --path rust

I've tried a few variations of this, but for whatever reason it can't seem to find my workspace or any of the packages. The best I was able to get out of it was a PR where it thinks it should be versioning my whole project to 0.1.0.

So, I figured I should ask: how do you tell release-please that a Rust workspace is in a sub-directory of the project? Is this even supported?

Thank you for your time and consideration.

[cdata]

I was able to get things working by moving my workspace Cargo.toml to the root of the project directory. It would be preferable to keep the Cargo.toml in the rust sub-directory, though. Also, I still don't quite understand what the --path option is meant to do.

[cdata]

I still haven't figured out if this is supported, but I was able to work-around this problem by relocating my workspace manifest to the root of the repository. It would be nice if I didn't have to do this, but it's not a deal-breaker for me.

[folex]

It is kinda a blocker for us atm (fluencelabs/spell#10).

Wdyt about us making a pr to fix this? Will you be willing to accept it, or what's the policy?

Thanks in advance!

[chingor13]

Sorry for the late response.

It looks like we do not support a workspace being in a subdirectory -- the plugin assumes that there is a root Cargo.toml.

We would definitely accept a PR to fix this if you'd like to submit one. Alternatively, your workaround would likely work, but doesn't look ideal.

For an example of how to add another config to the plugin, take a look at maven-workspace's considerAllArtifacts option.

[sekwah41]

Wouldnt the easiest fix for this not be allowing it to be non root but to add a Generic file handler like JSON and XML?

Example entry

  "extra-files": [
    {
      "type": "toml",
      "path": "somefolder/Cargo.toml",
      "jsonpath": "$.package.version"
    },
  ],

The problem I can see with that would possibly be the re-writing would cause problems because the comments may be lost.

If I get some time after new years ill possibly take a look at implementing what I mentioned.

Another I may add which would be useful for cases of other file types would be to do a generic regex replacer. Atm locally im using something like this to update the file.

let versionRegex = /\nversion = "([0-9.]+)"/g;

let newContents = cargo.replace(versionRegex, `\nversion = "${tauriConfig.package.version}"`);