-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
fix(publish): Don't strip non-dev features #14325
Conversation
We'll be doing a second `prepare_for_publish` call that doesn't need the filtering, we don't have access to the `included`, and we don't want the warnings duplicated.
First, we added support for stripping of local-only dev-dependencies. This was dual-implemented for `Cargo.toml` and `Summary`. This left off stripping of `dep/feature` that reference dev-dependencies (enabling features within dev-dependencies). When we fixed this, we again dual-implemented it. The `Cargo.toml` version was correct but the `Summary` version was instead stripping too many features, particularly features that reference renamed dependencies. We didn't have tests for this case and it wasn't caught earlier because crates.io re-generates the `Summary` from `Cargo.toml`, ignoring what we post. That makes this only show up with custom registries that trust what Cargo posts. Rather than fixing the `Summary` generation, I remove the dual-implementation and instead generate the `Summary` from the published `Cargo.toml`. Unfortunately, we don't have access directly to the packaged `Cargo.toml`. It could be passed around and I originally did so, hoping to remove use of the local `Package`. However, the local `Package` is needed for things like reading the `README`. So I scaled back and isolate the change to only what needs it. This also makes it easier for `prepare_transmit` callers. Fully open to someone exploring removing this extra `prepare_for_publish` in the future. Fixes rust-lang#14321
r? @weihanglo rustbot has assigned @weihanglo. Use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the fix. Unsure if there is a better way to fix this, but this seems good enough. Just need some more comments :)
@@ -1652,13 +1655,15 @@ fn publish_dev_dep_stripping() { | |||
"target-normal-and-dev/cat", | |||
"optional-dep-feature/cat", | |||
"dep:optional-namespaced", | |||
"dep:optional-renamed-namespaced10", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we cover more rename cases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added
renamed-dev-only
optional-renamed-dep-feature
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, hadn't refreshed. I'll post a follow up PR
src/cargo/util/toml/mod.rs
Outdated
@@ -2608,7 +2608,8 @@ fn prepare_toml_for_publish( | |||
package.workspace = None; | |||
if let Some(StringOrBool::String(path)) = &package.build { | |||
let path = paths::normalize_path(Path::new(path)); | |||
let build = if included.contains(&path) { | |||
let included = included.map(|i| i.contains(&path)).unwrap_or(true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why defaulting to true
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the caller hasn't specified what files are included in the package, we should act as if all are included. I feel like that question is a preface for asking for a comment but I'm having a hard time thinking of what to comment because the intent is so "obvious". Maybe its the curse of knowledge as I also wrote all of this code that is being modified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like it is the same problem that the intent of packaged_files
is unclear. Basically it does some checks and emits warnings, and we want to suppress warnings, hence unwrap_or(true)
.
I don't think it really needs a code comment. Thanks for the clarification!
"links": null, | ||
"name": "bar", | ||
"readme": "README.md", | ||
"readme_file": "../README.md", | ||
"readme_file": "README.md", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a side effect that fixes another bug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I considered tweaking things to not have this happen but it seemed more correct now.
@@ -2554,7 +2554,7 @@ fn unused_dep_keys( | |||
pub fn prepare_for_publish( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is pretty obscure what the included
argument is for. Could we document this function as well as arguments to make it clear? Something like
pub fn prepare_for_publish( | |
/// Makes the given [`Package`] into a self-contained, publish-ready `Package`. | |
/// | |
/// The `included` argument is for optionally checking if a given path in a field is reachable. | |
/// | |
/// See below for more details on what will be processed: | |
/// | |
/// * [`prepare_toml_for_publish`] | |
/// * [`to_real_manifest`] | |
pub fn prepare_for_publish( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to_real_manifest
is just to reuse the Package
/ Summary
generation logic. At that point, I don't feel like calling out prepare_toml_for_publish
really gains much as its name is so tied to this and it immediately follows it (in code, in rustdoc side bar which is alphabetical, and in rustdocs items which are in code-order).
I'm trying a rename of included
to see if that clarifies it. I feel weird saying too much more without also specifying all of the other behavior.
local_pkg: &Package, | ||
registry_id: SourceId, | ||
) -> CargoResult<NewCrate> { | ||
let deps = local_pkg | ||
let included = None; // don't filter build-targets |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is unclear why the argument affects build target filtering.
@bors r+ |
☀️ Test successful - checks-actions |
test(publish): More dev-dep stripping cases This is a follow up to #14325
Update cargo 15 commits in 257b72b8adfb1f2aa9916cefca67285c21666276..fa646583675d7c140482bd906145c71b7fb4fc2b 2024-07-30 15:08:27 +0000 to 2024-08-02 16:08:06 +0000 - refactor(toml): Rename 'resolved' to 'normalized' (rust-lang/cargo#14342) - faq: rephrase offline usage. (rust-lang/cargo#14336) - docs(unstable): Improve nightly link (rust-lang/cargo#14344) - Fix a typo in 1.81 changes (rust-lang/cargo#14343) - Change tests to support `rustc` wording changes (rust-lang/cargo#14341) - chore(deps): update rust crate windows-sys to 0.59 (rust-lang/cargo#14335) - chore(deps): update rust crate gix to 0.64.0 (rust-lang/cargo#14332) - chore(deps): update compatible (rust-lang/cargo#14331) - chore(deps): update rust crate rusqlite to 0.32.0 (rust-lang/cargo#14334) - fix: also build manpage for cargo.md (rust-lang/cargo#14339) - fix(config): Adjust MSRV resolve config field name / values (rust-lang/cargo#14296) - fix(toml): Resolve regression from toml_edit 0.22.18 (rust-lang/cargo#14329) - test(publish): More dev-dep stripping cases (rust-lang/cargo#14327) - Use gmake on AIX (rust-lang/cargo#14323) - fix(publish): Don't strip non-dev features (rust-lang/cargo#14325) r? ghost
What does this PR try to resolve?
First, we added support for stripping of local-only dev-dependencies.
This was dual-implemented for
Cargo.toml
andSummary
.This left off stripping of
dep/feature
that reference dev-dependencies(enabling features within dev-dependencies).
When we fixed this, we again dual-implemented it.
The
Cargo.toml
version was correct but theSummary
version wasinstead stripping too many features,
particularly features that reference renamed dependencies.
We didn't have tests for this case and it wasn't caught earlier because
crates.io re-generates the
Summary
fromCargo.toml
, ignoring what wepost.
That makes this only show up with custom registries that trust what
Cargo posts.
Rather than fixing the
Summary
generation, I remove thedual-implementation and instead generate the
Summary
from thepublished
Cargo.toml
.As a side effect, this also fixed it so the index lists filenames according to their location in
.crate
, rather than their location in the source.Fixes #14321
How should we test and review this PR?
Additional information
Unfortunately, we don't have access directly to the packaged
Cargo.toml
.It could be passed around and I originally did so, hoping to remove use
of the local
Package
.However, the local
Package
is needed for things like reading theREADME
.So I scaled back and isolate the change to only what needs it.
This also makes it easier for
prepare_transmit
callers.Fully open to someone exploring removing this extra
prepare_for_publish
in the future.