-
Notifications
You must be signed in to change notification settings - Fork 344
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
Markdown is not always converted to python in multiprocessing/threading #9134
Comments
Thanks for the report. I get a different error:
It seems that I'm just confused here, because it seems that if runpy is parsing the input, then there's no way it would work for .ipynb files either. (I believe you that it works; it just means that something else is going on) |
The relevant code from def _fixup_main_from_path(main_path):
# If this process was forked, __main__ may already be populated
current_main = sys.modules['__main__']
# Unfortunately, the main ipython launch script historically had no
# "if __name__ == '__main__'" guard, so we work around that
# by treating it like a __main__.py file
# See https://github.com/ipython/ipython/issues/4698
main_name = os.path.splitext(os.path.basename(main_path))[0]
if main_name == 'ipython':
return
# Otherwise, if __file__ already has the setting we expect,
# there's nothing more to do
if getattr(current_main, '__file__', None) == main_path:
return
# If the parent process has sent a path through rather than a module
# name we assume it is an executable script that may contain
# non-main code that needs to be executed
old_main_modules.append(current_main)
main_module = types.ModuleType("__mp_main__")
main_content = runpy.run_path(main_path,
run_name="__mp_main__")
main_module.__dict__.update(main_content)
sys.modules['__main__'] = sys.modules['__mp_main__'] = main_module Note the specific code paths to handle IPython execution there. I think this means that |
Ok, I can now reproduce this error as well. |
I managed to find an (exceedingly ugly) workaround for the issue when rendering to a terminal. The terminal caseFor reasons I don't at all understand, our subprocess that calls 🤷 The interactive caseI believe @cameronraysmith refers here to executing the cells inside VS code using the Quarto extension. Although this is then a bug to be reported at The problem seems to be happening in the way that the VS code Jupyter extension communicates the global module to the subprocess. Quarto's VS Code extension uses the Jupyter extension for interactive cell execution. In this situation, somehow the Jupyter extension communicates to |
@cscheid many thanks for investigating this.
Yes that's the error in what was formerly the
Yes that's correct.
Happy to post a link to or copy of this issue on |
That'd save me some time, thank you. |
The |
@cscheid this issue has reappeared for me by quarto AttributeError: module '__main__' has no attribute '__spec__' Let me know if you can reproduce whether you'd like to reopen this issue or have me create a new one. Thank you! |
@cameronraysmith Sorry for the late response. I can repro, and more damningly, I see this: 2710c41 The proper fix actually does the right thing. This will go in 1.6. Sorry about the mess. |
See quarto-dev/quarto#401 regarding the impact of the same issue on the Quarto VS Code extension.
Bug description
I recognize this is not an ideal design pattern, but calling a third-party library that uses multiprocessing and threading as shown in the minimal example below, results in an error suggesting the markdown may be passed to the process without being converted to python. The source code in the example works as expected in a python interpreter or jupyter kernel.
Steps to reproduce
near-minimal example
Expected behavior
The notebook should render without error.
Actual behavior
The following error is surfaced from the cli
while
a different error occurs from the VS Code extension
Your environment
environment
Quarto check output
quarto check
The text was updated successfully, but these errors were encountered: