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

Cleanup download-related code in the rustup_dist crate #1131

Merged
merged 3 commits into from
May 23, 2017

Conversation

jelford
Copy link
Contributor

@jelford jelford commented May 22, 2017

This PR is probably easiest to read if you do it commit-wise: the first commit just removes the old, unused download module from rustup_dist. The second commit pulls DownloadCfg (and friends) out into a new download module.

The only other change in there is that I've tried to kill some of the instances where the notify_handler gets needlessly passed around by moving functions to be methods on DownloadCfg + using the field it's already got. I suspect the only reason these weren't done before is that it was difficult to reason about the code, so hopefully this is an improvement.

There aren't any (intentional) functional changes in this, so I haven't made any changes to the tests (aside from those required to get it to compile). No rush to get this merged for the same reason.

jelford and others added 3 commits May 22, 2017 11:07
The actual code for handling downloads for rustup-dist is
in `dist`, which in turn hands off to `rustup-utils` and
`download` (the crate). Hopefully this clean-up makes it
a little easier to figure out what's going on with downloads
for future work.
The idea here is to reduce the API surface of `dist`, while
consolidating download-related code into a single place. Was also able
to remove a number of pointless pass-arounds of the
`notification_handler` attached to DownloadCfg (haven't caught them all
yet).
target_file.with_file_name(
target_file.file_name().map(|s| {
s.to_str().unwrap_or("_")})
.unwrap_or("_")
Copy link
Contributor

Choose a reason for hiding this comment

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

Hm, I know you didn't add this, but falling back to underscore seems like a bad idea, and the filename is supposed to be the hash anyway, so this should be an expect instead.

@Diggsey
Copy link
Contributor

Diggsey commented May 22, 2017

This LGTM, thanks! The underscore thing I commented on should probably be fixed separately.

@bors r+

@bors
Copy link
Contributor

bors commented May 22, 2017

📌 Commit 61f641a has been approved by Diggsey

@bors
Copy link
Contributor

bors commented May 22, 2017

⌛ Testing commit 61f641a with merge d1b851f...

bors added a commit that referenced this pull request May 22, 2017
Cleanup download-related code in the rustup_dist crate

This PR is probably easiest to read if you do it commit-wise: the first commit just removes the old, unused `download` module from rustup_dist. The second commit pulls `DownloadCfg` (and friends) out into a _new_ `download` module.

The only other change in there is that I've tried to kill some of the instances where the `notify_handler` gets needlessly passed around by moving functions to be methods on `DownloadCfg` + using the field it's already got. I suspect the only reason these weren't done before is that it was difficult to reason about the code, so hopefully this is an improvement.

There aren't any (intentional) functional changes in this, so I haven't made any changes to the tests (aside from those required to get it to compile). No rush to get this merged for the same reason.
@bors
Copy link
Contributor

bors commented May 23, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: Diggsey
Pushing d1b851f to master...

@bors bors merged commit 61f641a into rust-lang:master May 23, 2017
@jelford jelford deleted the download_cleanup branch May 23, 2017 13:04
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.

3 participants