Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpo-45582: Port getpath[p].c to Python #29041

Merged
merged 29 commits into from
Dec 3, 2021
Merged

bpo-45582: Port getpath[p].c to Python #29041

merged 29 commits into from
Dec 3, 2021

Conversation

zooba
Copy link
Member

@zooba zooba commented Oct 18, 2021

@zooba
Copy link
Member Author

zooba commented Oct 18, 2021

This is very very WIP, but I wanted to share it now for discussion.

My plan is to set it up so that getpath isn't actually a module, but is frozen bytecode that we execute during startup. The top of the file has the expected globals, and I'll use C code to create the dict for it. Then we exec the code, and pull the results out of it.

The next step is to write tests, which can execute it directly without having to modify C code and prove correctness/etc. Because it's all possible to stub out, we can isolate it entirely from any real filesystem and simulate whatever layout/build settings we want.

It may be logical to also merge in some of site.py's functionality, and potentially sysconfig (looking at the install schemes), but those can be deferred to a later PR.

@zooba
Copy link
Member Author

zooba commented Oct 18, 2021

Ping @vstinner

@vstinner
Copy link
Member

If I understood correctly, this code doesn't remove getpath.c yet. It's a WIP.

@vstinner
Copy link
Member

For me, the most important part is to write unit tests to test that the same always produce the same . The code should be stateless, but can use the current working directory, environment variables, etc.

I wrote down all I know about the "Python Path Configuration" at: https://docs.python.org/dev/c-api/init_config.html#python-path-configuration

@zooba
Copy link
Member Author

zooba commented Oct 20, 2021

If I understood correctly, this code doesn't remove getpath.c yet.

Correct. I just started removing it, and obviously everything is broken :) But I'll come back to it tomorrow.

I wrote down all I know ...

Thanks. I think I've re-discovered most of that by parsing the logic from getpath.c, but what you've got there will help me understand how you designed the config mechanism. I want to remove as much as possible, but hopefully without breaking anyone trying to use it directly.

return 0;
}
/* If dirname() is the same for both then it is a dev build. */
if (len != _Py_find_basename(stdlib)) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ericsnowcurrently FYI, if my change doesn't make it in, you'll want to fix this check. On Windows, executable and stdlib have the same basename in a release build (e.g. C:\Python39\{Lib//python.exe}), but different in a dev build (C:\cpython\Lib // C:\cpython\PCbuild\amd64\python.exe)

@@ -1,14 +1,19 @@
/* Return the initial module search path. */
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is a complete rewrite - don't try and analyse the diff. Just go to "View File" under the triple-dot menu for it instead.

@zooba zooba changed the title bpo-42260: Port getpath[p].c to Python bpo-45582: Port getpath[p].c to Python Oct 22, 2021
@zooba zooba marked this pull request as ready for review October 22, 2021 23:42
@zooba zooba requested a review from a team as a code owner October 22, 2021 23:42
@zooba
Copy link
Member Author

zooba commented Oct 22, 2021

This is definitely not ready to merge yet, even if by some chance all the tests pass, but I'm happy to have reviews and comments/discussion.

Any significant discussion should go to the bpo issue, please. Also, if I need to be pinged, please do it on bpo.

Python/fileutils.c Outdated Show resolved Hide resolved
Python/fileutils.c Outdated Show resolved Hide resolved
Copy link
Member

@ericsnowcurrently ericsnowcurrently left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's a partial review. I haven't dug into the bigger pieces of this PR.

Lib/site.py Show resolved Hide resolved
Lib/site.py Show resolved Hide resolved
Lib/sysconfig.py Show resolved Hide resolved
Lib/test/test_embed.py Outdated Show resolved Hide resolved
Lib/test/test_embed.py Show resolved Hide resolved
Lib/test/test_embed.py Show resolved Hide resolved
Programs/_freeze_module.c Outdated Show resolved Hide resolved
Modules/getpath.py Outdated Show resolved Hide resolved
if (isdev >= 0) {
config->use_frozen_modules = !isdev;
}
config->use_frozen_modules = !config->_development_env;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I purposefully left it -1 if we couldn't figure it out. So this change implies that we are always able to figure it out. Is that the case?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the rules we've got for figuring out if we're in a dev build or not, yes. Those rules may be insufficient, but it's all a heuristic anyway - if you put those files into a regular install, we'll assume it's a dev build.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we'll assume it's a dev build.

That's what I did at first too. However, I found that it was helpful to know if we were not able to figure it out, which is what the -1 indicates in this case.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, we either find the build landmarks or we don't... what other checks do you have? If the build landmarks aren't there, it's not a dev build, and if they are but the stdlib isn't, it's all going to crash down anyway.

Modules/getpath.py Outdated Show resolved Hide resolved
@zooba
Copy link
Member Author

zooba commented Nov 12, 2021

I'm expecting another dumb error (on my part) or two, but I'm very close to having this working.

Reviews would be appreciated! Bear in mind that I'm trying to match the current (quirky) behaviour, rather than streamline anything by changing it (yet). We can do those once we know we've got something working.

@zooba
Copy link
Member Author

zooba commented Nov 15, 2021

There was nothing helpful in that history anyway ;-)

Tests all pass now, reviews appreciated!

Include/cpython/initconfig.h Outdated Show resolved Hide resolved
Include/internal/pycore_fileutils.h Outdated Show resolved Hide resolved
Python/initconfig.c Outdated Show resolved Hide resolved
Python/initconfig.c Outdated Show resolved Hide resolved
@bedevere-bot bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Dec 1, 2021
@zooba zooba added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Dec 2, 2021
@bedevere-bot
Copy link

🤖 New build scheduled with the buildbot fleet by @zooba for commit 5962947 🤖

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

@bedevere-bot bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Dec 2, 2021
@zooba
Copy link
Member Author

zooba commented Dec 2, 2021

Found the leak! So it's ready to merge once these tests pass.

@zooba zooba merged commit 99fcf15 into python:main Dec 3, 2021
@zooba zooba deleted the bpo-42260 branch December 3, 2021 00:08
ales-erjavec added a commit to biolab/orange3-installers that referenced this pull request Apr 2, 2024
Problem on MacOS exec_prefix is not resolved when symlink to
bin/python3.11

Probably due to python/cpython#29041
ales-erjavec added a commit to biolab/orange3-installers that referenced this pull request Apr 2, 2024
Problem on MacOS exec_prefix is not resolved when symlink to
bin/python3.11

Probably due to python/cpython#29041
markotoplak pushed a commit to Quasars/quasar that referenced this pull request Jun 27, 2024
Problem on MacOS exec_prefix is not resolved when symlink to
bin/python3.11

Probably due to python/cpython#29041
markotoplak pushed a commit to Quasars/quasar that referenced this pull request Jun 27, 2024
Problem on MacOS exec_prefix is not resolved when symlink to
bin/python3.11

Probably due to python/cpython#29041
markotoplak pushed a commit to Quasars/quasar that referenced this pull request Jun 27, 2024
Problem on MacOS exec_prefix is not resolved when symlink to
bin/python3.11

Probably due to python/cpython#29041
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants