GeezerVison

Note, I did not convert some of the other places that seem to replicate the PYTHONPATH pattern, specifically the wasm paths:

I expect those should still work as is, though they could certainly change to using _PYTHON_SYSCONFIGDATA_PATH if their intent is purely to import sysconfig and not any other modules that may be in that directory.

@FFY00 @erlend-aasland @corona10 please let me know if there is any other information I can provide to help move this along.

@vfazio, I don't have the bandwidth to review this any time soon :( Hopefully in a few weeks.

Tested-by: Yann E. MORIN <[email protected]>

🤖 New build scheduled with the buildbot fleet by @FFY00 for commit 68e931a 🤖

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

@vfazio, thank you so much for working on this, and sorry for the delay it took to get the PR reviewed. Also, thanks to everyone who tested it.

The proposed solution seems okay, I am just gonna trigger the tests to run on the buildbots to make sure nothing is unexpectedly broken there before merging.

@FFY00 Thanks for taking a look and kicking this off!

If this gets accepted, is there any chance i could follow it up with a patch for 3.12 or other earlier versions?

At the time of writing, one test is failing due to a disk space error and another due to PEG generator errors which I cant imagine are related to my PR.

I don't think any of the failures are related to this MR. Im not sure if any of the buildbots attempt to cross compile, it may be worth adding a couple of those scenarios at some point in the future.

@FFY00 Do you want me to rebase this PR on main or can this be merged as is?

@FFY00 @erlend-aasland @corona10 please let me know if there is any other information I can provide to help move this along.

Apologies in advance for the bump, but I just want to make sure there's no additional followup necessary from me on this PR.

@FFY00 @erlend-aasland @corona10 just wanted to reach out again on this PR and see if there are changes necessary and if there's a chance of getting it merged and ported to 3.12/3.13. It will require minor tweaks to target 3.12 I think.

@vfazio: I'll review this at the PyCon sprints next week! Thanks for your patience.

@vfazio: I'll review this at the PyCon sprints next week! Thanks for your patience.

Thanks, I realize you're all busy people so I apologize for the pings, I just want to make sure there's nothing blocking on me.

@erlend-aasland should i rebase this PR occasionally?

i'm using spec = FileFinder(path, (SourceFileLoader, SOURCE_SUFFIXES)).find_spec(name) but i wonder if it would be better to use importlib.util.spec_from_file_location ?

Some of this machinery is still opaque to me, when to use one or the other. I've noticed that the spec generated from FileFinder seems to behave subtly differently than spec generated from spec_from_file_location in other development i've done... I'd prefer to use the recommended method for this solution.

@FFY00 @erlend-aasland @corona10 friendly ping

Sorry for the delay! GIthub notifications are out of hand and it's difficult to keep track of everything.

Sorry for the delay! GIthub notifications are out of hand and it's difficult to keep track of everything.

I totally understand. Thanks again for your help with this, I sincerely appreciate it!

Do you think there's a chance of porting this back to 3.13?

Personally, I am fine with it, though I would like the release manager to approve it since it introduces a behavior change when the _PYTHON_SYSCONFIGDATA_PATH environment variable is specified.

@Yhg1s what do you think?

Yeah, I'm okay with this being backported. It seems like a reasonable bugfix and it shouldn't affect anything else. (Anything already setting _PYTHON_SYSCONFIGDATA_* environment variables should realise they're explicitly meddling with Python sysconfig internals ;p)

Yeah, I'm okay with this being backported. It seems like a reasonable bugfix and it shouldn't affect anything else. (Anything already setting _PYTHON_SYSCONFIGDATA_* environment variables should realise they're explicitly meddling with Python sysconfig internals ;p)

The last time i backported something, miss Islington did the grunt work. Im not sure if it ports back cleanly, im out of town so wont be able to check for a couple of weeks.

Thanks @vfazio for the PR, and @FFY00 for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

@vfazio Do not rebase PRs ever. Update merges on your working copy branch before pushing edits to your fork are a good idea to make sure no conflicts have arisen and to test locally with current code. The merged 3.13 backport should have been listed after the 'working' message.

@vfazio Do not rebase PRs ever. Update merges on your working copy branch before pushing edits to your fork are a good idea to make sure no conflicts have arisen and to test locally with current code. The merged 3.13 backport should have been listed after the 'working' message.

Every repo/maintainer has a different flow. I'm now aware of CPython's workflow so it shouldnt be a problem going forward.