-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Rebase #4501 to resolve merge conflicts #4562
Conversation
Thanks @alex for picking this up :-) |
@takluyver No problem! I'm very excited about pip 10, so I'm trying to help as I can :-) |
pip/cache.py
Outdated
@@ -27,45 +29,61 @@ def __init__(self, cache_dir, format_control): | |||
binaries being read from the cache. | |||
""" | |||
self._cache_dir = expanduser(cache_dir) if cache_dir else None | |||
# Ephemeral cache: store wheels just for this run | |||
self._ephem_cache_dir = tempfile.mkdtemp(suffix='-pip-ephem-cache') |
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.
Please use pip.utils.temp_dir.TempDirectory
, instead of this. :)
@pradyunsg done. |
pip/wheel.py
Outdated
@@ -591,6 +591,8 @@ def __init__(self, requirement_set, finder, build_options=None, | |||
self.requirement_set = requirement_set | |||
self.finder = finder | |||
self._cache_root = requirement_set._wheel_cache._cache_dir | |||
self._ephem_cache_root = ( | |||
requirement_set._wheel_cache._ephem_cache_dir.path) |
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 looks pretty bad. 😕
I guess this can stay for now because I would be moving caches around as a part of my GSoC project, so, all this would likely change that time anyway.
Hello! I am an automated bot and I have noticed that this pull request is not currently able to be merged. If you are able to either merge the |
I've added this to the 10.0 milestone, in exchange of #4501, since this is basically that PR taken forward. |
pip/commands/install.py
Outdated
try: | ||
self.populate_requirement_set( |
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 don't think that this change is needed - populate_requirement_set moving inside the try.
Am I missing something?
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 think there was a test failure because of temporary files not getting cleaned up; it's in the try
block so that the finally
fires on failure and calls the cleanup. I don't remember the details, though, and I might have confused it with something else.
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'll try moving it out of try and let you know what happens.
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.
Seems like it's needed - https://travis-ci.org/pradyunsg/pip/jobs/249302943.
This isn't a blocker then for this PR - if someone would be able to explain to me why this is needed though it'd be nice.
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.
AssertionError: temp files not expected
I think it's like this:
- Before the code in question, a temporary directory has been created to store ephemeral wheels. This is new in this PR.
- The tests you see failing are those which exercise an error case, e.g. no requirements specified.
- If
self.populate_requirement_set(...)
fails, we want to call the cleanup code to remove that temporary dir. - The cleanup code is in the
finally
block, so we need the step that can fail to be in thetry
.
The change in this PR is that a temporary directory is created before this; previously it only created temporary files later, so there was no need for cleanup if the earlier stage failed.
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.
Ah, Okie... Thanks @takluyver for the explanation!
I haven't really looked into this PR, I've just been skimming over it for the most part.
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.
Just one more question - the wheels are still being built after the population of the RequirementSet, correct?
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, it's still the WheelBuilder
a few lines below that builds wheels for the requirement set. The crucial difference is that previously it only built wheels if they could be cached (e.g. if we've downloaded an sdist, so the wheel corresponds to a particular version). Now it also builds ephemeral wheels that won't be cached, e.g. if you install from a local directory.
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.
Cool. I thought so too but just felt like confirming. :)
Thanks again!
Follow up from pypagh-4144 To allow build system abstractions, we want installation to go through wheels in more cases. In particular, installing packages from a local directory or a VCS URL currently runs 'setup.py install'. The aim of this PR is to have it build a wheel, which is stored in an ephemeral cache directory, used for installation, and then discarded. We can't cache it permanently based on the path/URL, because the code there might change, but our cache wouldn't be invalidated.
When there's a previous build directory, no_clean is set
@dstufft woudl it be helpful if I split some of the conflict prone bits into their own PR? |
Sorry! I'm actually refactoring the cache rn... There's probably more PRs I'm gonna make that'll conflict with this PR, after that I'll probably stop moving stuff around so much and start building on new things that got added. If it's fine by you to wait a week or so and then fix the conflicts, I'll happily ping here once the refactor work is done. :) |
@pradyunsg if you'd like to take over this PR, that'd be great. |
Sure! I'll happily take it ahead from here. :) |
Any ETA, @pradyunsg? I am as excited about pip 10 as anyone else :) |
I'm working on another issue in pip rn... Once that is done, this is next in the stack. Alas, that means not within the next 3 weeks, at least. |
Hi what's the current status on this? @pradyunsg are you working on this? My understanding is that this is needed both for its own sake, and to complete PEP 518 support (because Is someone in a position to fix the merge conflicts? I'm willing to review the PR once that's done (although I'll admit I'm pretty unclear as to what's landed and what's in-progress in this area - @pradyunsg mentions using the new cache API from #4623, I assume that's not yet been incorporated here?) |
Right now actually. |
Cool - I'll try to review that this evening. |
@pradyunsg Please close. |
Closing since this has been carried forward in #4764 and that links back here. :) |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Fixes #4501