Skip to content

add size to pylock.toml #13395

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

Open
wants to merge 10 commits into
base: main
Choose a base branch
from
Open

add size to pylock.toml #13395

wants to merge 10 commits into from

Conversation

stonebig
Copy link
Contributor

to resolve #13393

@notatallshaw
Copy link
Member

pre-commit.ci autofix

try:
session = PipSession()
response = session.head(self.url, allow_redirects=True)
response.raise_for_status()
Copy link
Member

@uranusjr uranusjr May 17, 2025

Choose a reason for hiding this comment

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

This probably should be handled. Does ValueError cover this? It is not obvious.

@@ -508,6 +508,23 @@ def hash_name(self) -> str | None:
def show_url(self) -> str:
return posixpath.basename(self._url.split("#", 1)[0].split("?", 1)[0])

@property
def size(self) -> int | None:
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 convinced we should do additional network access to get the sizes.

I would rather envision an approach where we add a size attribute to InstallRequirement.download_info (as in a subclass of DirectUrl, or another class that would be more specialized to record the provenance URL, PEP710-style), and populate it at the same time as we currently populate download_info. This also means storing the original size in the cache (origin.json) next to the hashes.

It's more complex but like more efficient and robust.

That's just an intuition though, as I have not investigated deeply.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it's a patch over an "experimental" feature. you need the "complex" and "efficient" version at this point ?

Copy link
Member

Choose a reason for hiding this comment

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

My understanding is the term experimental means here is that pip may change the CLI or semantics of the feature between releases. Not that the solution isn't expected to be robust.

I have the same concern here, particularly for the use case of locking a large existing environment, doing hundreds of extra network requests may cause the lock to be significantly slower or fail.

Copy link
Member

Choose a reason for hiding this comment

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

Another reason is that it would make sense for file sizes to follow the same flow as hashes, as they are closely related. I believe the could be obtained and verified at the same places in the codebase. It will likely make things easier to follow and understand.

Copy link
Contributor Author

@stonebig stonebig May 18, 2025

Choose a reason for hiding this comment

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

OK, I agree, but that is a bigger change, will need time. Competitive PR is welcomed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

suggestion: shouldn't pip lock also provide the size of objects ?
4 participants