Activity

1. FFY00

   added

   type-featureA feature request or enhancementA feature request or enhancement

   buildThe build process and cross-buildThe build process and cross-build

   topic-installation

   OS-wasi

   topic-sysconfig

   3.14bugs and security fixesbugs and security fixes

   on Mar 26, 2025
2. zooba commented on Mar 28, 2025

   

   zooba

   on Mar 28, 2025

   Member

   More actions

   Is it better to freeze it? Or generate native code to extend _sysconfig with the values?
3. FFY00 commented on Mar 28, 2025

   

   FFY00

   on Mar 28, 2025

   MemberAuthor

   More actions

   I would like to keep things the same with -Xfrozen_modules=off. Unless the freezing implementation gets too complex, I think it would be better to keep it as a module.
4. picnixz

   removed

   3.14bugs and security fixesbugs and security fixes

   on Mar 28, 2025
5. zooba commented on Mar 31, 2025

   

   zooba

   on Mar 31, 2025

   Member

   More actions

   I'd expect the build order to get complex - I'm pretty sure _sysconfigdata gets generated after CPython is built, but to freeze it you need to generate it halfway through the build. All the variables must be available at that point, so it's doable, but it might be a pain.

   Then again, having a .py version of the data is no doubt incredibly helpful for some users, as they can get information about an install without having to run it (which may not even be possible). So generating the .py earlier and using the existing freeze infrastructure may be best for everyone.

   Although the frozen modules are there to improve startup time, so they have to balance binary size with likelihood of being imported. I don't know that _sysconfigdata gets loaded every time? If it does, then sure, but if it's only imported on occasion then it might be better to keep it totally separate.

   👍React with 👍1Reacted by Adam Turner
6. FFY00 commented on Apr 1, 2025

   

   FFY00

   on Apr 1, 2025

   MemberAuthor

   More actions

   I'd expect the build order to get complex - I'm pretty sure _sysconfigdata gets generated after CPython is built, but to freeze it you need to generate it halfway through the build. All the variables must be available at that point, so it's doable, but it might be a pain.

   It's not much of a pain really, it just depends on Makefile and pyconfig.h, so we can use the bootstrap or --with-build-python interpreter to run the script that generates _sysconfigdata_*.py.

   Then again, having a .py version of the data is no doubt incredibly helpful for some users, as they can get information about an install without having to run it (which may not even be possible). So generating the .py earlier and using the existing freeze infrastructure may be best for everyone.

   I am not proposing to remove the .py file. Additionally, we are already shipping a JSON file on POSIX (GH-127302), it shouldn't be difficult to also add this to the Windows build.

   Although the frozen modules are there to improve startup time, so they have to balance binary size with likelihood of being imported. I don't know that _sysconfigdata gets loaded every time? If it does, then sure, but if it's only imported on occasion then it might be better to keep it totally separate.

   Right, that's a good point. It doesn't get loaded every time. Depending on how folks feel about it, we can either use the existing freeze infrastructure, or split it into an extension.
7. zooba commented on Apr 1, 2025

   

   zooba

   on Apr 1, 2025

   Member

   More actions

   Depending on how folks feel about it, we can either use the existing freeze infrastructure, or split it into an extension.

   We already have a _sysconfig extension, so I'd rather see it "split" into there rather than another extension.