Repository navigation
Custom frozen modules get ignored. #89559
Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/ericsnowcurrently'
closed_at = None
created_at = <Date 2021-10-06.20:22:14.892>
labels = ['interpreter-core', 'type-bug', '3.11']
title = 'Custom frozen modules get ignored.'
updated_at = <Date 2021-10-28.21:34:52.384>
user = 'https://github.com/ericsnowcurrently'bugs.python.org fields:
activity = <Date 2021-10-28.21:34:52.384>
actor = 'eric.snow'
assignee = 'eric.snow'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2021-10-06.20:22:14.892>
creator = 'eric.snow'
dependencies = []
files = []
hgrepos = []
issue_num = 45396
keywords = ['patch']
message_count = 4.0
messages = ['403336', '403337', '403705', '405277']
nosy_count = 3.0
nosy_names = ['gvanrossum', 'brett.cannon', 'eric.snow']
pr_nums = ['28776', '28778', '29301']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue45396'
versions = ['Python 3.11']
Activity
ericsnowcurrently commentedon Oct 6, 2021
Recently we added the "-X frozen_modules" CLI option to control whether or not (non-essential) frozen modules get used. Currently the default is "off", though the plan is to make the default "on". Regardless, this is problematic for executables with custom frozen modules (where PyImport_FrozenModules is overridden). If there are custom frozen modules then they should always be used.
Note that there are already other problems with custom frozen modules, to be addressed separately. (See bpo-45395.)
ericsnowcurrently commentedon Oct 6, 2021
(This was motivated by #28633 (comment).)
gvanrossum commentedon Oct 12, 2021
I'm not convinced by the comment you linked to.
It seems Brett is referring to the case where at the C level someone overrides
PyImport_FrozenModules(a global in frozen.c) -- though it is never explicitly named in the thread. And that variable is ignored when the -X flag is set to off (at least, it is ignored when use_frozen() is false and we're not talking about an "essensial" frozen module; and I think use_frozen() corresponds to whether the -X flag is on or off, or its default). So I think the -X flag is named correctly.ericsnowcurrently commentedon Oct 28, 2021
The behavior has been addressed in the fix for bpo-45395. However, I'd like to change the name of the -X option from "frozen_modules" to "frozen_stdlib", to avoid any confusion in the future. After that this issue is done.
kumaraditya303 commentedon Jul 27, 2022
Do we still want to pursue this? I don't think we should change the name as it is been this way for the past beta and alphas.
gvanrossum commentedon Jul 27, 2022
Agreed, let's not change this. Closing as "fixed" because everything else is taken care of.
erlend-aasland commentedon Jul 27, 2022
I assume this implies also closing the linked open PR. I'm marking it as pending close.
gvanrossum commentedon Jul 27, 2022
Yes please.