Skip to content

Refactor: Create uninstall submodule #6557

New issue

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

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

Already on GitHub? # to your account

Merged
merged 9 commits into from
Jan 19, 2019
Merged

Conversation

k-nasa
Copy link
Contributor

@k-nasa k-nasa commented Jan 17, 2019

Since 'uninstall' was found in the 'install' module, it split.
And I moved duplicate functions to utils.

@rust-highfive
Copy link

r? @dwijnand

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

Copy link
Member

@dwijnand dwijnand left a comment

Choose a reason for hiding this comment

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

I like this change because cargo_install is a big module (871 lines, second best to cargo_compile, at 884) and this moves just shy of 400 lines of it into a 250 line shared module and a smaller 150 line uninstall module.

I'd love if we could find a better name for the shared module, and I have a small question on a publically defined struct field.

For these repo refactoring PRs I'd love if a more senior maintainer could drop a note with their thoughts.

mod fix;
mod lockfile;
mod registry;
mod resolve;
mod utils;
Copy link
Member

Choose a reason for hiding this comment

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

Can we find a better name? I generally try to avoid generic names like "utils" because they end up containing anything (because everything is intended to bring utility :D). But particularly in cargo seeing as we already have a cargo::util (and a cargo::sources::git::utils).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay. I will have time to fix it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ops::utils -> ops::common_for_install_and_uninstall
Somewhat verbose name, but how about this?

) -> CargoResult<()> {
let mut to_remove = Vec::new();
{
let mut installed = match metadata.v1.entry(pkgid) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@dwijnand I needed to refer to v1 here, so I changed the field to public.
I am not familiar with Rust so much, so please tell me if there is a better way.

Copy link
Member

Choose a reason for hiding this comment

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

Add a v1() "getter" method to metadata, that simply returns the v1 field.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed it!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@dwijnand I'm sorry. Why is it not good to make the struct's field public?
I am sorry to hear it late. 😭

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure precisely. I've seen advice against it, but I can't remember the motivation. I'd want to understand better myself too.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see. thank you for answering! 🎉

@k-nasa
Copy link
Contributor Author

k-nasa commented Jan 19, 2019

@dwijnand As I fixed it, would you see it again when there is time❓

@dwijnand
Copy link
Member

I'm really enjoying your "common between install and uninstall" module name! :D. It's specific enough to avoid being a catch-all module, but it's long enough that I expect it'll find a nicer name sooner or later (hopefully not utils!).

So it's a good enough working title to land this, for me. Thank you for the PR.

@bors: r+

@bors
Copy link
Contributor

bors commented Jan 19, 2019

📌 Commit 6a197fb has been approved by dwijnand

@bors
Copy link
Contributor

bors commented Jan 19, 2019

⌛ Testing commit 6a197fb with merge 2a15e57...

bors added a commit that referenced this pull request Jan 19, 2019
Refactor: Create uninstall submodule

Since 'uninstall' was found in the 'install' module, it split.
And I moved duplicate functions to utils.
@bors
Copy link
Contributor

bors commented Jan 19, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: dwijnand
Pushing 2a15e57 to master...

@bors bors merged commit 6a197fb into rust-lang:master Jan 19, 2019
@k-nasa k-nasa deleted the move_uninstall branch January 19, 2019 11:36
bors added a commit to rust-lang/rust that referenced this pull request Jan 21, 2019
Update cargo

Pull in fix for #57774.

6 commits in ffe65875fd05018599ad07e7389e99050c7915be..907c0febe7045fa02dff2a35c5e36d3bd59ea50d
2019-01-17 23:57:50 +0000 to 2019-01-20 22:31:07 +0000
- Put mtime-on-use behind a feature flag. (rust-lang/cargo#6573)
- Fix a typo in the unstable docs (rust-lang/cargo#6569)
- Perhaps you meant: foo, bar or foobar (rust-lang/cargo#6550)
- Refactor: Create uninstall submodule (rust-lang/cargo#6557)
- Fix spurious Windows errors with switch_features_rerun. (rust-lang/cargo#6561)
- Stop building on master on Travis. (rust-lang/cargo#6562)

r? @Mark-Simulacrum
@ehuss ehuss added this to the 1.34.0 milestone Feb 6, 2022
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants