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

Use locally cached wheels during install #5871

Merged
merged 2 commits into from
Jul 3, 2022

Conversation

dimbleby
Copy link
Contributor

Related to #2415, though it only addresses one of the many repeated downloads which that issue reports.

If we have a url dependency pointing at a wheel eg

hu-core-ud-lg = {url = "https://github.com/oroszgy/spacy-hungarian-models/releases/download/hu_core_ud_lg-0.3.1/hu_core_ud_lg-0.3.1-py3-none-any.whl"}

then poetry performs the download during poetry install, even though it has a perfectly good cached version in ~/.cache/pypoetry/artifacts.

get_cached_archive_for_link looks kinda confused: returning the original input Link to mean "no cached archive found" is odd. So I have tweaked it to return None instead which seems a lot clearer.

It's always possible that I am the confused one, certainly I am struggling to understand what the intention of the changed code can have been. So do please think about that when reviewing!

src/poetry/installation/chef.py Outdated Show resolved Hide resolved
Comment on lines -45 to -31
# If the archive is already a wheel, there is no need to cache it.
if link.is_wheel:
return link
Copy link
Member

Choose a reason for hiding this comment

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

Considering the comment, I can only imagine that might be a shortcut for local wheels? Maybe, you can examine if the change has some side effects on wheels as path dependencies. 🙏

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The only place this is called is in the executor _download_link() code path, which means that it is never relevant for path dependencies.

I'm quite unsure about what this is supposed to be doing - Chef isn't a name that helps much. At first I'd thought it was going to be some general purpose artifact cache, but its extremely limited scope is puzzling to me.

Copy link
Member

Choose a reason for hiding this comment

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

I need to look at this when I have more time. But I suspect the original intent was to cache the environment specific when built. Useful when the link is an sdist.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@dimbleby dimbleby force-pushed the cached-wheels branch 3 times, most recently from 2847e9a to d34eae4 Compare June 19, 2022 17:02
@dimbleby
Copy link
Contributor Author

As a sort-of convincer that it's fine to use the cache for wheels: this is what poetry 1.1.13 has been doing all along.

The comment and the code were mismatched prior to #4967, which jumped in the direction of favouring the comment. But this MR suggests that's the wrong way to jump, and the fact that poetry 1.1.13 had been "wrong" all that time is some sort of evidence that it's safe to undo that.

@dimbleby dimbleby mentioned this pull request Jul 2, 2022
Copy link
Member

@radoering radoering left a comment

Choose a reason for hiding this comment

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

Convincing enough for me. I see no reason to put this PR off any longer.

@radoering radoering merged commit 711ddd8 into python-poetry:master Jul 3, 2022
@dimbleby dimbleby deleted the cached-wheels branch July 3, 2022 12:39
@mkniewallner mkniewallner mentioned this pull request Jul 12, 2022
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 29, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants