Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reject subdirectory manifests that are not members of the workspace #93

Merged
merged 1 commit into from
Dec 8, 2022

Conversation

MarijnS95
Copy link
Member

The previous implementation had one fatal flaw: having a non-workspace Cargo.toml in a subdirectory, with a [workspace] defined some directories higher is invalid when that [workspace] doesn't include the given Cargo.toml subdirectory/package. cargo rejects this with a current package believes it's in a workspace when it's not, and we should do the same instead of having an unwrap_or_else that falls back to using the workspace root Cargo.toml as a package (especially if it might not contain a [package] at all).

This would for example fail when running x new template in the repo directory, cd'ing into it and invoking x build. Instead of complaining about template/Cargo.toml not being part of the workspace, it detects the workspace and falls back to building the root package because the template directory appears to just be a subdirectory of the root without defining a subpackage along it. Since our root doesn't define a [package], the supposed-to-be-infallible unwrap() on manifest.package below fails.

Copy link
Contributor

@dvc94ch dvc94ch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice, thanks!

The previous implementation had one fatal flaw: having a non-workspace
`Cargo.toml` in a subdirectory, with a `[workspace]` defined some
directories higher is invalid when that `[workspace]` doesn't include
the given `Cargo.toml` subdirectory/package.  `cargo` rejects this with
a `current package believes it's in a workspace when it's not`, and we
should do the same instead of having an `unwrap_or_else` that falls back
to using the workspace root `Cargo.toml` as a package (especially if it
might not contain a `[package]` at all).

This would for example fail when running `x new template` in the repo
directory, `cd`'ing into it and invoking `x build`.  Instead of
complaining about `template/Cargo.toml` not being part of the workspace,
it detects the workspace and falls back to building the root package
because the `template` directory appears to just be a subdirectory of
the root without defining a subpackage along it.  Since our root doesn't
define a `[package]`, the supposed-to-be-infallible `unwrap()` on
`manifest.package` below fails.
@MarijnS95 MarijnS95 merged commit 03299a7 into rust-mobile:master Dec 8, 2022
@MarijnS95 MarijnS95 deleted the manifest-not-in-workspace branch December 8, 2022 20:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants