FWIW I know we're all excited about

scie-pants

and what it implies, but I don't think we need to rush it, per-se. It's new, and likely

experimental

-by-another-name, so thorns may exist. My 2c

Do you have a concrete proposal on how to not rush it and work out kinks at the same time? That would be helpful. I too thought the pantsbuild.org doc update may have been a bit rushed; i.e.: directing users to use it as 1st class, but I was also not the one doing the work there and I'm loathe in general to toss an opinion unless I back it up with details at the least and the actual work in the best,

(This post is semi-related to https://pantsbuild.slack.com/archives/C0D7TNJHL/p1675450441549639 above.)

i’m not certain that #18135 is caused by

scie-pants

, per-se… we also see those errors in CI.

I’m sure we’ll live with both the old pants bootstrap script and

scie-pants

in the wild for quite some time..

While I don't recommend it, I would find it mildly amusing to see:

pants eject

-> creates

./pants

script in repo (with probably a punnier, non-create-react-app name (takeoff, strip, disrobe, etc) My 1.34 cents (man, CAD to USD conversion is a killer) would be that any useful "not rushed" solution basically comes down to our documentation and how promotional the scie-pants approach is. e.g. In the installation, in lieu of replacing the existing

./pants

script solution, that still stays front and centre, while below it we show off the "cool, new awesome, xtreme `scie-pants`" route. Leave it to new users to decide. But I think the practical and pragmatic reality is that the existing user base will stick with the bootstrap script, and if they switch over - pain points might rear their head after any expected amount of testing. The one surprise to me was around in-repo plugins workflow, where I think we still need a system python 3.9 interpreter? That's all fine, I just didn't see it in the new docs.

The docs update was in 2.15.x, which is not the current version, so only the more adventurous would be exposed to it. We had already been through rounds of asking people to test scie-pants out, and it felt like it was time to take it up a notch, and that seemed like a way to do so.

wasn’t the external interpreter requirement only if your plugin required ext module compilation ?

Well, you need some interpreter to run black on to format your plugin code

oh, for that.. yea. fits under the Python development umbrella. guessing the thing being that you need one matching the IC used to bootstrap pants with..

The one surprise to me was around in-repo plugins workflow, where I think we still need a system python 3.9 interpreter? That's all fine, I just didn't see it in the new docs.

You need a system interpreter to run Pants on python code. That is true whether the code is plugin code or business code or whatever. If you don't want to lint and test your plugin code with Pants, you absolutely do not need a system Python interpreter - the in-repo plugin code will run just fine. This is no different than today and is actually only required to guards against in-repo plugin code with platform-specific dependencies only distributed as sdists. A pretty narrow class I'd think. I took the PBS off PATH for this reason alone. I could add the option to add it back of course.

I agree it makes logical sense when given some thought - it's just one of those weird cases that you don't really think about until you need to think about it.

Agreed. I do want to point out thought that it is not one of the rocky bits. You'd both have to switch from

./pants

to

pants

and nuke other configuration to bust your already working in-repo plugins.

Do pants plugins need to be able to run against the same interpreter that is embedded with scie-pants (3.9.x right now)?

Yes. As they do anyhow. Pants as distributed today on PyPI requires plugin code is compatible with 3.{7,8,9}

Yep. Makes sense. It's just one of those workflows I don't give much thought to when it works. After I brew installed Pants, I upgraded my interpreters (3.10, 3.11) and wiped out the 3.9 one as being "unnecessary, since I only used it for pants anyways" Since that time, I haven't had to run it on a repo with an in-repo plugin, so I haven't run into this use case.If I did, I'm sure my brain would rub two sticks together to figure out all this mentioned above - but yeah, I just compartmentalized all Pants stuff into a bucket.

Makes sense. It may make sense to re-introduce PBS on PATH with a knob. I think that wouldn't be too hard. The danger is stating the caveats takes more than 1 small sentence; so people won't read it well or at all, enable it for convenience, go boom since their plugin uses psutil on a platform with no wheels released and complain in Slack.

PBS?

So Pants ships a hermetic interpreter. It is ~impossible to do so and have that interpreter have a functioning distutils module due to system paths that get set at CPython build time. The hermetic interpreter it happens to use right now is provided by the PyOxidizer guy and is Python Build Standalone: https://github.com/indygreg/python-build-standalone

cool

So, basically, scie-pants suffers a subset of the problems PyOxy does. PyOxy also has a disfigured distutils capability. It does not suffer lack of the availability of

__file__

though which presented @ancient-vegetable-10556 plenty of pain.

Oh good. Some of my pants-plugins use

__file__

.

Yeah - that would be problematic otherwise. The PBS are full real CPython. The only thing that doesn't work is using them to build platform-specific sdists. That is all. You can even run the embedded IDLE tkinter hermetic and all.

__file__

is a cheap way to get the full path to a script and record an inferrable dependency at the same time. So, I'm glad this will continue to work: https://github.com/StackStorm/st2/blob/master/pants-plugins/uses_services/mongo_rules.py#L40

(in-repo Plugins would've always had

__file__

)

@wide-midnight-78598 You missed the ideal pun:

pants drop

(instead of "eject")

🤮

(in-repo Plugins would've always had

__file__

)

Not if the Python embeds Rust -> Rust embeds Python ticket had been resolved with PyOxy. Handling

__file__

was already a bear for Pants itself in the work Chris did there. I don't believe there was a solution for in-repo plugins. I may be wrong there though.

It would have required stdlib changes on the Python side, which I had discussed with the author of runpy.py, but two years for a change to become available was a tad too long

Hah!

the tl;dr: is that making pex work with an embedded Python interpreter was limited by Python not exposing the command line arguments that were actually sent to Python in a certain way whose details I don’t remember