https://pantsbuild.org/ logo
Join Slack
Powered by
Hi folks, a reminder that the monthly Pants develo...
# development
h
Hi folks, a reminder that the monthly Pants developer team meeting is tomorrow, at 1 PM PST, as a huddle in this channel. This is where we discuss the development of Pants itself, and all are welcome to participate or just lurk. If you have any agenda items, please let me know by DM!
c
I won't be able to make the call today. Re Python 3.14 I hope to land the science PR after Veterans Day when I am back at a regular computer, and then add scies to the GitHub release workflow to prove this all works. I have not looked at teaching scie-pants to use them. @wide-midnight-78598 joked about how easy it would be so maybe he was ;-)
w
I think I suggested getting rid of scie-pants in lieu of something wayyyyyy smaller šŸ˜†
@curved-manchester-66006 If we keep using regular 
scie-pants
- we'll probably want to keep the same pex-based approach that we use today, as there's no real value in re-factoring to using 
scies
since it already works. Our update process is ensuring there is a valid 3.14 interpreter available, and then setting whatever defaults we want/need. I updated the assless-chaps repo with a rust runner, instead of the python one. Big reason being, it highlights how little code we could choose to run (and how few deps we'd need to maintain) for a golden path run. Obviously no backwards compat... Also no auto-downloading the correct scie - but that's trivial. We could get it to a point where we pull the runner into the mainline Pants repo and not have a separate scie-pants project at all. I just wanted to ensure we're separating: ā€¢ the machinery inside Pants to create scies (e.g. plumbing the --scie flags from Pex) ā€¢ from the act of creating a scie OF Pants (which my assless-chaps repo does by downloading 
science
and generating a lift file if we want) ā€¢ from the scie-pants runner, itself
In fact, the whole scie-pants project (with Pants deployed as scies) would likely just be the 3 files here: https://github.com/pantsbuild/scie-pants/blob/main/src/main.rs
c
as there's no real value in re-factoring to using scies since it already works.
I think there would be tremendous value in being able to unambiguously assert what version of Python+PBS we are using. To do that today we have this awkward two step update where we need to update scie-pants and then update the version of scie-pants to use in Pants. I think the feedback we have gotten is that needing to update scie-pants is confusing to users and should be done as sparingly as possible. As you said I don't think it is that much code to say "download this scie and run it" vs all the -- critical for backwards compatibility -- things scie-pants can do today.
w
Ah, to be clear, that quote was prefixed with "If we keep using regular 
scie-pants"
As in, the one we have today - and trying to retrofit that to point at scies instead of pexes. If the intention is to gut the current scie-pants down to effectively just the 3 files that would make up the "runner", then yeah, I'm 100% on board with that (aka a more sophisticated assless-chaps"
I also dicovered the slow performance I was seeing there was due to me being an idiot: https://github.com/sureshjoshi/assless-chaps/issues/2
c
I think we might be tripping over what "using scie-pants means". I think "switching to a new launcher" would be highly disruptive, and hard to do while maintaining compatibility with prior Pants releases. So my mental model was along the lines "add an if statement to scie-pants that does something like assless-chaps".
w
Yeah, sort of - we already mostly just have forwards compatibility with pants and scie-pants. You can't use below 0.12.2 (or 0.12.5) with Pants supporting Python 3.11, and then there will likely be another bump for python 3.14. My idea would be to version this scie-pants as 1.0.0 at some point, and then maybe release a stripped back 2.0.0. Just from looking at the repo and the open issues, it doesn't really get much TLC - so adding a conditional burden to it might even make that maintenance worse. We can make scies going very far back if we want, so a new runner could even work on older Pants
c
I mean that scie-pants 0.12.5 supports old version of Pants, so there is no "switch the launcher" step if using an old version. Adding scies for old releases is interesting. (Tangent: I recently learned that GitHub releases are not immutable by default :-/)
w
> Tangent: I recently learned that GitHub releases are not immutable by default Lol, not even close - which is why we should be doing some more attestation checks more often šŸ˜† I think we might be typing past each other here. scie-pants on 0.12.5 can currently use it for basically any version of pants 2.20+ (probably older, but whatever). If we go the route of a pants-runner that exclusively uses scies and nothing else as 0.13, and we backport scies to every github release, then (I think), we're in a position where existing scie-pants users are left untouched, and newer scie-pants users wouldn't really know anything has changed (caveating for some of the extra busy box commands current scie-pants has). So, in my mind, would a user ever know the launcher changed underneath them, other than being a version bump? I guess the thing I'm wondering is, why we would keep any part of the codebase we don't use (ie. with an "if" statement), if the end user wouldn't know the difference.
A flaw in my logic is if a user downloads pexes separately, and uses pants to run them in isolation of the github release.
I might be wrong in some of my assumptions above, too, so I might just be flagrantly missing something
4 Views
Open in Slack
PreviousNext
Powered by