For the discussion on <https://github.com/pantsbui...
# development
b
For the discussion on https://github.com/pantsbuild/pants/discussions/19443 I think the only real solution is for a
python_requirement
to have a
find_links
field that points to a URI that would then be used when generating the lockfile. Does that seem... OK?
āœ… 1
p
Related: •
find_links
is a repo-wide setting today, but should probably be at least resolve-level: https://github.com/pantsbuild/pants/issues/17565 ā—¦ Your suggestion goes even farther to expose
find_links
for individual
python_requirement
targets. Would you also need to add
indexes
? • We might also need to track
find_links
and/or
indexes
in the lockfile somehow, possibly via a hash: https://github.com/pantsbuild/pants/issues/16576
Another possibility is for
pants_requirement
to use a (new) hook that allows injecting additional
find_links
for the resolve that includes it. So, plugins could use it, but it would not be exposed directly on the target to avoid overly complex BUILD data.
b
Yeah in order for the GitHub-release support to work semalessly, it'd need to be per-requirement (per-resolve, but that'd be hard to do). It turns out the fix is like a handful of lines to support it šŸ˜‚
That's true, we could hide the field with a leading underscore
OK one hiccup. Pex seems to be reading the hash of the project from PyPI but that doesn't match the hash of the wheel on GitHub 😮
But that can easily be remedied. More GitHub action scripts 🤣
Ok so I'll go with @proud-dentist-22844 s suggestion of scoping this change to a hidden flag just for pants requirements