Well GitHub said the "expanded_assets" URL isn't t...
# development
b
Well GitHub said the "expanded_assets" URL isn't technically a "stable" one. So we'll have to get creative!
I think our options are to use the un authenticated REST API (limited to 60 requests per hour, likely based on IP) or upload custom html to S3 and use that (which I was REALLY hoping to avoid 🫠
b
There’s the option of uploading a HTML file to GitHub releases and then downloading that locally to pass to
--find-links
b
This problem is specifically for the pants_requirements target. scie-pants can do pretty much anything 🤪
Which, I suppose this is only a problem for lockfiles generation. Actually yeah I think ab S3 index is likely the easiest solution, client-wise
OK, I'm thinking that after we "publish" a release we can run a GHA job that downloads the index html, adds the new links and uploads it back to S3. We cna leverage https://docs.github.com/en/actions/using-jobs/using-concurrency so we don't step on our own toes
That has the nice benefit of one
--find-links
for all of our wheels. So if someone is using a custom way of generating lockfiles, they'll find easy support as well.
p
We can use github pages to host the page instead of S3
b
I thought about that. I'll probably look into it. But I'm not sure if everything we need is there
👍 1
(we already use S3 for stuff that's what powers binaries.pantsbuild.org)