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

test(priv_dep): add test for verify public is respected recursively #13183

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

linyihai
Copy link
Contributor

@linyihai linyihai commented Dec 18, 2023

What does this PR try to resolve?

This PR want to verify public is respected recursively by rustc.
The original idea came from here: rust-lang/rust#44663 (comment).

How should we test and review this PR?

you can review and test on per commit.

Additional information

test case wait for add:

@rustbot
Copy link
Collaborator

rustbot commented Dec 18, 2023

r? @ehuss

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 18, 2023
tests/testsuite/pub_priv.rs Outdated Show resolved Hide resolved
@linyihai linyihai force-pushed the recursive_pri_dep branch 2 times, most recently from d5fa7e2 to 10ff613 Compare December 19, 2023 07:47
@rustbot rustbot added the A-testing-cargo-itself Area: cargo's tests label Dec 19, 2023
@epage epage added the Z-public-dependency Nightly: public-dependency label Dec 20, 2023
@epage
Copy link
Contributor

epage commented Dec 27, 2023

Thanks for doing this investigation!

Any thoughts on what test cases are worth merging now vs waiting on rust-lang/rust#119428?

@linyihai
Copy link
Contributor Author

Thanks for doing this investigation!

Any thoughts on what test cases are worth merging now vs waiting on rust-lang/rust#119428?

I think both test cases make sense. IMO, the test case recursive_package_pub_no_warning verifies the recursively public API does not cause warnings. recursive_package_priv_warning It's also a use case and a reminder of our current processing logic. It's ok to be updated recursive_package_priv_warning when this issue rust-lang/rust#119428 has any progress.

And now I have no plans to add more use cases. If there is nothing else missing, I suggest a combined submission

@linyihai
Copy link
Contributor Author

linyihai commented Dec 28, 2023

In the commit I add a public field when publish a crate, but this is only for test.

We should also support upload the public field when publish crates to cratess-io and so on.

At least one public needs to be added here: https://github.com/rust-lang/cargo/blob/master/crates/crates-io/lib.rs#L67,
and optional: dep.is_public() in https://github.com/rust-lang/cargo/blob/master/src/cargo/ops/registry/publish.rs#L353C45-L353C45

@linyihai linyihai changed the title test(priv_dep): add test for verify public is respected recursively WIP: test(priv_dep): add test for verify public is respected recursively Dec 29, 2023
@linyihai linyihai marked this pull request as draft December 29, 2023 02:07
@ehuss
Copy link
Contributor

ehuss commented Jan 2, 2024

r? epage

@rustbot rustbot assigned epage and unassigned ehuss Jan 2, 2024
@linyihai linyihai changed the title WIP: test(priv_dep): add test for verify public is respected recursively test(priv_dep): add test for verify public is respected recursively Jan 2, 2024
@linyihai linyihai marked this pull request as ready for review January 2, 2024 15:45
@@ -558,6 +558,7 @@ pub struct Dependency {
package: Option<String>,
optional: bool,
default_features: bool,
public: bool,
Copy link
Contributor

Choose a reason for hiding this comment

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

Feel free to break this out into its own PR for us to merge immiedately

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok

@@ -479,3 +479,220 @@ fn allow_priv_in_custom_build() {
)
.run()
}

// A indirectly add D as private dependency.
Copy link
Contributor

Choose a reason for hiding this comment

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

These tests don't make it too clear that they are not expected behavior but that some help show existing bugs. We should call that out, linking to the issue in question

@@ -479,3 +479,220 @@ fn allow_priv_in_custom_build() {
)
.run()
}

// A indirectly add D as private dependency.
Copy link
Contributor

Choose a reason for hiding this comment

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

I've been unsure whether these should be merged before the related fix. Thinking on it more, and with rust-lang/rust#119428 being moved to the rust repo, I suspect we should hold off on tests that demonstrate bad behavior. The problem is that the fix would be merged into the rust repo but they can't update the tests in the same commit, adding more frustration to the process of fixing the bugs.

Sorry that I hadn't thought of it before you had put more time into polishing this up.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is ok to close this PR or add WIP to the title until the issue fixed in rust repo.

@linyihai
Copy link
Contributor Author

linyihai commented Jan 3, 2024

In the commit I add a public field when publish a crate, but this is only for test.

We should also support upload the public field when publish crates to cratess-io and so on.

At least one public needs to be added here: https://github.com/rust-lang/cargo/blob/master/crates/crates-io/lib.rs#L67, and optional: dep.is_public() in https://github.com/rust-lang/cargo/blob/master/src/cargo/ops/registry/publish.rs#L353C45-L353C45

and what do you think this? Maybe this is not what you need to do now, because this will add a 'public' field to the user's local file

bors added a commit that referenced this pull request Jan 3, 2024
test: support publish package with a `public` field.

### What does this PR try to resolve?

This PR add a `public` alike method to support add a dependency as public/private,
```
Package::new("foo", "0.1.0")
        .cargo_feature("public-dependency").add_dep(Dependency::new("bar", "0.1.0").public(true))
```

and then get it from registry in test.

This PR was seperated from the #13183.

### How should we test and review this PR?
You can review on per commit.

After running the test case `publish_package_with_public_dependency`,  you can check a "public" field in `./target/tmp/cit/t0/registry/3/b/bar`.

### Additional information
r? epage
bors added a commit that referenced this pull request Jan 3, 2024
test: support publish package with a `public` field.

### What does this PR try to resolve?

This PR add a `public` alike method to support add a dependency as public/private,
```
Package::new("foo", "0.1.0")
        .cargo_feature("public-dependency").add_dep(Dependency::new("bar", "0.1.0").public(true))
```

and then get it from registry in test.

This PR was seperated from the #13183.

### How should we test and review this PR?
You can review on per commit.

After running the test case `publish_package_with_public_dependency`,  you can check a "public" field in `./target/tmp/cit/t0/registry/3/b/bar`.

### Additional information
r? epage
@epage
Copy link
Contributor

epage commented Jan 3, 2024

and what do you think this? Maybe this is not what you need to do now, because this will add a 'public' field to the user's local file

Sorry, had overlooked that message. Yes, we need to add publish support. Looking at bindeps and artifacts, it looks like we do that for unstable features today.

We will also need to make sure the crates.io side is implemented.

@bors
Copy link
Collaborator

bors commented Jan 3, 2024

☔ The latest upstream changes (presumably #13245) made this pull request unmergeable. Please resolve the merge conflicts.

@linyihai
Copy link
Contributor Author

linyihai commented Jan 8, 2024

Sorry, had overlooked that message. Yes, we need to add publish support. Looking at bindeps and artifacts, it looks like we do that for unstable features today.

We will also need to make sure the crates.io side is implemented.

After talking in t-crates-io channel, I've gathered the information as below:

  • the crates-io currently not suport public field.
  • if they plan to support that they may ignore the public in metadata carried with the publish api.

So is it deserves to make a PR to add public field when publish crates?

@epage epage added the S-blocked-external Status: ❌ blocked on something out of the direct control of the Cargo project, e.g., upstream fix label Jan 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testing-cargo-itself Area: cargo's tests S-blocked-external Status: ❌ blocked on something out of the direct control of the Cargo project, e.g., upstream fix S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. Z-public-dependency Nightly: public-dependency
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants