Chicken and egg problem with 3.14 - to put a test ...
# development
w
Chicken and egg problem with 3.14 - to put a test in scie-pants that exercises the Pants version + Python interpreter, I need a release of 3.14 with a release version to target. To get a release of 3.14 - we should really have a way to run it 😆 Not sure what was done on 3.11 and Pants 2.25 Thoughts?
f
release of scie-pants, pants, or both?
w
exactly
According to how the scie-pants tests work (using PANTS_VERSION), we would need to release Pants, THEN test scie-pants, and then release Or, release scie-pants as-is, then pants, then add the test to scie-pants after the fact and hope nothing bad happens. There is likely another workaround somewhere, where we like, use PANTS_BOOTSTRAP_URLS to fake the version with a 3.14 pex to apply the test first
I thought PANTS_SOURCE was the move, but that'll use system python
f
Maybe you could do a custom release of Pants? I have a modified version of the release workflow for non-official releases. You would just need to update the URLs env var used by scie-pants to point at the alternate release.
PANTS_BOOTSTRAP_URLS
You may not even have to do a custom release workflow. Just build a Pants pex with an existing version and set
PANTS_BOOTSTRAP_URLS
to your custom pex for that version.
w
That’s how I’m currently testing it to confirm it works locally, but the scie-pants tests use PANTS_VERSION, which points to pantsbuild/pants. An intermezzo workaround would be to host the pants-pex I use somewhere, and then do the bootstrap urls approach… Then, flip that around once we release
f
bootstrap URLS can be file:// I believe
so "host" local
w
Yeah, it can be - but do you mean, commit the pex to the scie-pants repo, and use it there? I was thinking to just host it on my fork and point there (untested, but seems possible)
f
Where are you testing?
Laptop or in cloud?
w
Locally it works, no problem. What I'm referring to is getting it into scie-pants CI. So making a test much like this 3.11 one