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

Use $PWD and --manifest-path to select a default package in workspaces #25

Merged
merged 7 commits into from
Dec 8, 2022

Conversation

MarijnS95
Copy link
Member

@MarijnS95 MarijnS95 commented Nov 25, 2022

Fixes rust-mobile/cargo-apk#8

This restores original, prevalent --manifest-path usage to select a package containing the APK crate in a [workspace], instead of using -p for that.

pub struct Workspace {
#[serde(default)]
pub default_members: Vec<String>,
Copy link
Member Author

Choose a reason for hiding this comment

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

Should start using this too.

src/utils.rs Outdated Show resolved Hide resolved
@MarijnS95 MarijnS95 force-pushed the workspace-default-package branch 2 times, most recently from 3034a40 to 29f28ea Compare November 25, 2022 17:07
src/subcommand.rs Outdated Show resolved Hide resolved
@dvc94ch
Copy link
Collaborator

dvc94ch commented Dec 1, 2022

is libraryfication of cargo ever going to happen? I really whish we didn't have to rebuild these components

@MarijnS95
Copy link
Member Author

is libraryfication of cargo ever going to happen? I really whish we didn't have to rebuild these components

No idea, would be cool.

Even cooler would be a plugin system, where cargo reads the manifest and only communicates meaningful chunks with us, instead of giving us a crate that contains their way of parsing the Cargo.toml, config.toml etc.

…paces

This restores original, prevalent `--manifest-path` usage to select a
package containing the APK crate in a `[workspace]`, instead of using
`-p` for that.
When calling `.parent()` on a filename the result is `""`, which should
be treated as PWD (`"."`) but `dunce::canonicalize()` ends up in a "No
such file or directory".
`.ancestors()` only calls `.parent()` on a `Path` which walks up until
the string empty, but this isn't the root of the filesystem if the path
wasn't absolute.
@MarijnS95 MarijnS95 force-pushed the workspace-default-package branch from 68b8a09 to 89165f5 Compare December 6, 2022 11:01
@MarijnS95 MarijnS95 requested a review from dvc94ch December 6, 2022 11:03
@MarijnS95 MarijnS95 marked this pull request as ready for review December 6, 2022 11:08
@MarijnS95 MarijnS95 force-pushed the workspace-default-package branch from 89165f5 to 2ade565 Compare December 6, 2022 11:56
src/utils.rs Outdated
Comment on lines 103 to 113
// Find the closest member based on the given path
Ok(path
.ancestors()
// Move manifest out of the HashMap
.find_map(|dir| all_members.remove(dir))
.unwrap_or_else(|| {
(
workspace_manifest_path.to_owned(),
workspace_manifest.clone(),
)
}))
Copy link
Member Author

Choose a reason for hiding this comment

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

This logic is slightly incomplete as it falls back to the package defined in the workspace (found in xbuild):

  • Even if it doesn't contain a [package] (leading to a panic in the outer function that expects this to have been checked already);
  • When there's a manifest along the way that isn't the workspace, but it is not part of it (this is a proper error in cargo).

I'll resolve these in xbuild first (where an identical setup to this PR has already been merged) and apply the same solution here afterwards.

Copy link
Member Author

Choose a reason for hiding this comment

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

Fixed here too by replicating rust-mobile/xbuild#93!

@MarijnS95
Copy link
Member Author

I'll probably merge this tonight and push out a new cargo-apk release.

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 force-pushed the workspace-default-package branch from f07e2bb to 9e8401e Compare December 8, 2022 19:00
@MarijnS95 MarijnS95 merged commit 9ee82c9 into master Dec 8, 2022
@MarijnS95 MarijnS95 deleted the workspace-default-package 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.

Restore --manifest-path (and $PWD) behaviour to select packages in a workspace
2 participants