Repository navigation
Require hashes for build dependencies - #287
Conversation
This comment has been minimized.
This comment has been minimized.
| { requirement = "flit-core==4.0.2", hashes = [ | ||
| "sha256:8d80717e28d982b41594ed5b14d4e89fbc5bad55473fde27994a3101db18a94e", | ||
| "sha256:b6929defd93884b584d7c87829e0e7b5c26ed6be17b0b873979019314aa841c8", | ||
| ] }, |
There was a problem hiding this comment.
same question as https://github.com/astral-sh/astral-bot/pull/142#discussion_r4262016653: what's the advantage to pinning flit-core twice in the pyproject.toml file? This is going to break Renovate upgrade PRs; can we not pin the declared dependency on line 2 to a hash and avoid this second pin?
There was a problem hiding this comment.
we can't pin a hash there because it's not supported by standards, additionally, that pin does not apply transitively, just to the build backend for this package and not any subsequent package which may use flit-core for builds
breaking renovate for build dependencies is an expected consequence / acceptable trade-off until we have real build dependency locking
There was a problem hiding this comment.
okay that makes sense, can we disable updates of flit-core in the renovate config in that case?
|
This change has no effect on the docstrings that would be added to typeshed. 🤖🎉 |
3 participants
Enable
require-build-hashesand pin isolated build dependencies with hashes in the project configuration. Use compatible bounds forflit_corein[build-system].requiresso downstream projects can select their own verified backend version without conflicting with an exact package-level pin.