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

download .tar.xz if python3 is used #65932

Merged
merged 2 commits into from
Nov 13, 2019
Merged

Conversation

guanqun
Copy link
Contributor

@guanqun guanqun commented Oct 29, 2019

fixes #65757

@rust-highfive
Copy link
Collaborator

r? @alexcrichton

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 29, 2019
@alexcrichton
Copy link
Member

Thanks! Is there something that we should test for in Python to see if xz decompression is supported? Is it possible to configure that off in python 3? Are we sure that all Python 3 versions support this?

@alex
Copy link
Member

alex commented Oct 30, 2019

Off hand, I'm almost certain it's possible to compile without it, and you can check for availability by seeing if import lzma raises an ImportError.

@guanqun
Copy link
Contributor Author

guanqun commented Oct 30, 2019

Good catch, I added an extra check for the version, according to the python documentation here: https://docs.python.org/3/library/tarfile.html

Changed in version 3.3: Added support for lzma compression.

If we trust this info, checking the version is enough, we don't have to try to import lzma.

@tesuji
Copy link
Contributor

tesuji commented Oct 30, 2019

We could use docker run --rm -it python:3.3 and test xz support in there.

@Mark-Simulacrum
Copy link
Member

Can we just check for lzma support directly, and not do any version detection? That seems more reliable and avoids these questions.

@tesuji
Copy link
Contributor

tesuji commented Oct 30, 2019

Maybe:

tarball_suffix = '.tar.xz'
try:
    import lzma
except ImportError:
    tarball_suffix = '.tar.gz'

@guanqun
Copy link
Contributor Author

guanqun commented Oct 31, 2019

updated to import check, please help review again.

btw how can we update the azure pipelines to do a full verification?

@alexcrichton
Copy link
Member

Is it certain that if lzma exists as a module that the tarball extraction module supports it as a decompression format?

This seems like it's getting somewhat complicated, so I'm not sure if it's worth having so many checks to avoid a few megabytes on the download? (presumably the git repo is much larger than the snapshots at this point?)

@guanqun
Copy link
Contributor Author

guanqun commented Nov 1, 2019

According to the tarfile's implementation from python, it internally uses lzma, see the source code here: https://github.com/python/cpython/blob/master/Lib/tarfile.py#L387-L397

but in python2, even we have lzma, I doubt it can work with tarfile out of box.

So that's why I originally think it's better to do the version check, it's simple and it can always work though it might be a more conservative estimate.

@alexcrichton
Copy link
Member

That's what I'm sort of getting at with maybe not doing this at all because it doesn't save all that much and it's pretty complicated. The import lzma trick won't work because if the lzma package is defined it doesn't imply the tarfile package uses it. The version check won't work because it doesn't imply that lzma support is compiled in. The least common denominator is gz-compressed tarballs.

Perhaps a configuration option could be used to opt-in to this? Or something like that?

@alex
Copy link
Member

alex commented Nov 1, 2019

I think if you change return True after import lzma to return sys.version_info[0] >= 3 then this is correct under all practical circumstances.

@guanqun
Copy link
Contributor Author

guanqun commented Nov 1, 2019

@alex we can do that, but I'd argue the logic is a bit unclear at first glance, just checking the python version is >= 3.3 is much clear.

@alexcrichton I don't see why the version check won't work, as lzma is part of the standard library of Python after that version.

@alexcrichton
Copy link
Member

Presumably though lzma support can be disabled when python is compiled right? Sorry but this is where it all just seems like this is perhaps a bit too much effort with respect to the change proposed here?

@alex
Copy link
Member

alex commented Nov 4, 2019 via email

@JohnCSimon
Copy link
Member

Ping from triage - this PR has sat idle for the last few days...
@alex @alexcrichton @guanqun
Can you post what else needs to happen with this PR?

Thanks!

@guanqun
Copy link
Contributor Author

guanqun commented Nov 10, 2019

I come up with a slightly better idea. We can try to create a .tar.xz file, if it can succeed, then on the other hand, the decompression should be fine. With this approach, we can bypass the version check or the import check.

Code is pushed, but I need to test that with Python3, will report back.

@guanqun
Copy link
Contributor Author

guanqun commented Nov 10, 2019

I tried python2 and python3, they both can figure out the right file types. These are pre-built version, not custom built, I believe it would cover most of the use cases.

@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Nov 11, 2019

📌 Commit 8d56bcc has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 11, 2019
@alexcrichton
Copy link
Member

@bors: r-

er actually, let's keep this out of the hot path. This shouldn't be calculated every time ./x.py build is run.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 11, 2019
@guanqun
Copy link
Contributor Author

guanqun commented Nov 11, 2019

thank you for the review. I've moved the check to the downloading function. locally it's fine for python 3. let's see if the CI job works. it's using python 2.

@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Nov 12, 2019

📌 Commit 0019371 has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 12, 2019
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Nov 13, 2019
bors added a commit that referenced this pull request Nov 13, 2019
Rollup of 13 pull requests

Successful merges:

 - #65932 (download .tar.xz if python3 is used)
 - #66074 ([mir-opt] Turn on the `ConstProp` pass by default)
 - #66094 (Fix documentation for `Iterator::count()`.)
 - #66166 (rename cfg(rustdoc) into cfg(doc))
 - #66227 (docs: Fix link to BufWriter::flush)
 - #66292 (add Result::map_or)
 - #66297 (Add a callback that allows compiler consumers to override queries.)
 - #66317 (Use a relative bindir for rustdoc to find rustc)
 - #66330 (Improve non-exhaustiveness handling in usefulness checking)
 - #66331 (Add some tests for fixed ICEs)
 - #66334 (Move Session fields to CrateStore)
 - #66335 (Move self-profile infrastructure to data structures)
 - #66337 (Remove dead code for encoding/decoding lint IDs)

Failed merges:

r? @ghost
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Nov 13, 2019
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Nov 13, 2019
bors added a commit that referenced this pull request Nov 13, 2019
Rollup of 14 pull requests

Successful merges:

 - #65932 (download .tar.xz if python3 is used)
 - #66094 (Fix documentation for `Iterator::count()`.)
 - #66166 (rename cfg(rustdoc) into cfg(doc))
 - #66186 (Add long error explanation for E0623)
 - #66227 (docs: Fix link to BufWriter::flush)
 - #66248 (add raw ptr variant of UnsafeCell::get)
 - #66292 (add Result::map_or)
 - #66297 (Add a callback that allows compiler consumers to override queries.)
 - #66317 (Use a relative bindir for rustdoc to find rustc)
 - #66330 (Improve non-exhaustiveness handling in usefulness checking)
 - #66331 (Add some tests for fixed ICEs)
 - #66334 (Move Session fields to CrateStore)
 - #66335 (Move self-profile infrastructure to data structures)
 - #66337 (Remove dead code for encoding/decoding lint IDs)

Failed merges:

r? @ghost
@bors bors merged commit 0019371 into rust-lang:master Nov 13, 2019
@guanqun guanqun deleted the download-xz branch November 13, 2019 22:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

use xz files for stage0 download if on system with xz
8 participants