https://pantsbuild.org/ logo
Join Slack
Powered by
Two questions: 1. Does anyone know why `scie-pan...
# development
w
Two questions: 1. Does anyone know why 
scie-pants
(the Rust code specifically) exists right now? I thought that Pants can output itself as a pex, and we could use 
science
or (now) 
pex
to bundle that with a Python interpreter? I wasn’t sure if 
scie-pants
was needed strictly to handle the case where we want to run the bundled interpreter vs when we sometimes want to run the pants script 2. Is there anything that’s preventing us from using Python 3.12 on pants? Like, something in the repo that’s causing a problem? I feel like we might be leaving some perf on the table. In-repo plugins seem to be the only thing I can think of at the moment (having not yet setup a branch to try this on). I thought there was some work going on, but I can’t find the associated PR anymore
b
Re 1, it’s valuable to have a single simple binary that can run the version of pants specified in pants.toml: upgrading pants for a whole team means just editing that file, rather than getting people to download and install a new version. If we could rely on pants always being a scie that provides its own interpreter, the launcher could likely be simpler (wouldn’t have to install Python interpreters).
There’s some (closed) issues about this, but I’m not in a position to find them.
w
Right, but I guess the question was moreso - is that what the purpose of the scie-pants repo is? To facilitate both running the local ./pants script (if present) or bundling an interpreter and then using that? I use 
scie
files rather heavily in my production work, so that’s not in question - but we’re not using the more “traditional” mechanisms for creating said 
scie
files (
science
binary or now, 
pex
). If we were, the pants repo itself could create and deploy a bundled version of itself (for example).
If we could rely on pants always being a scie that provides its own interpreter, the launcher could likely be simpler (wouldn’t have to install Python interpreters).
So, what I take this to mean is that, the repos that still use the 
./pants
script (which launches using a local interpreter) are the reason for the complexity of our 
scie-pants
repo? It must be more than that, no?
Ahhhh, okay okay, I think I got it. It’s a shim to grab and download the associated pants.pex, and unwrap that locally - so it’s basically an isolated runner that doesn’t depend on Pants, but rather grabs, unpacks, and runs pex. Rather than what I was thinking, where the scie-pants would be (mostly) tightly coupled to a pants version
I had it in my mind, for some reason, that when we modded the pants.toml, we were pulling down a custom pants.scie (pants.pex + interpreter FOR THAT pants version). Which then just means we would be downloading and unpacking the same python interpreter over and over again… I guess unless we had a lazy ptex downloaded interpreter which would be some double indirection I think. Hmm… I need to scratchpad this - I’m stuck in interpreter recursion hell 😆
b
It’s a shim to grab and download the associated pants.pex, and unwrap that locally - so it’s basically an isolated runner that doesn’t depend on Pants, but rather grabs, unpacks, and runs pex
Yep.... but with an extra step (that you're aware of, but just being explicit): "download the associated pants.pex, install an appropriate interpreter and _execute the pex using the interpreter_"
Which then just means we would be downloading and unpacking the same python interpreter over and over again
Yeah, if we had "eager" scies rather than lazy/ptex ones, as you say
👍 1
c
Also, repos that use 
./pants
will not be respected when using 
scie-pants
.. i.e. it doesn't invoke the 
./pants
script at all. The pants repo is an exception to this rule (triggered by the config in pants.toml):
Copy code
[DEFAULT]
# Tell `scie-pants` to use our `./pants` bootstrap script.
delegate_bootstrap = true
w
@happy-kitchen-89482 @curved-manchester-66006 ^^ Some notes on the 3.12 scie-pants stuff from today. Just to keep the thread
So, I finally decided to revisit something and make a dumb little poc. My idea is, if Pants (the pexes) are packaged as scies with lazy interpreters, then the runner itself is a scie - I feel like the scie-pants runner code could be simplified to a couple of python (or whatever) files and leverage the built-in scie functionality wherever else. Fundamentally, using the 
scie
commands
functionality to act as multiple entry-points - one when there is no version passed in, another when you know the version (and build root, and all the metadata that scie-pants currently takes). So, like a blank 
pants-runner.scie --version
would find the pants.toml, grab the version, and re-call as 
pants-runner.scie pants 2.22.0 --version
(or whatever the current pattern is)
Copy code
def main(argv: list[str]) -> None:
    pid = os.getpid()
    args = argv[1:]
    print(f"{pid}: Launched pants-runner with args: {args}")
    
    if not args:
        version = get_version()
        subprocess.run([f"{os.getcwd()}/pants-runner.scie", "pants", version], check=True)
        sys.exit(0)
    
    version = args[1]
    print(f"{pid}: Attempting to run using version {version}")
    
    # "Download" (e.g. pick) correct scie from local releases and run it (ignoring args)
    subprocess.run([f"{os.getcwd()}/releases/{version}/pants.{version}-cp39-darwin_arm64.scie", "--version"], check=True, env={"SCIE_PANTS_VERSION": "0.12.0"})
    sys.exit(0)
https://github.com/sureshjoshi/assless-chaps/
18 Views
Open in Slack
PreviousNext
Powered by