dash: [BUG] long_callback fails when bundling python code
Describe your context Please provide us your environment, so we can easily reproduce the issue.
- replace the result of
pip list | grep dash
below
dash 2.0.0 A Python framework for building reactive web-apps. Developed b...
dash-bootstrap-components 1.0.2 Bootstrap themed components for use in Plotly Dash
dash-core-components 2.0.0 Core component suite for Dash
dash-table 5.0.0 Dash table
Describe the bug
When using Pyinstaller to bundle a Dash app using long_callback as a single MacOS .app file, the app fails to register the long_callback. The error occurs in https://github.com/plotly/dash/blob/78ca3ec1752f6178fe25a02753b8a9f9946a5772/dash/long_callback/managers/__init__.py#L38 with the call to inspect.getsource, which throws an OSError, stating that the source code cannot be retrieved. In this case, the long_callback calls external libraries used to query a database. The error only occurs when packaging with Pyinstaller. Although the Pyinstaller packaging is probably a fairly rare use case, I was wondering why access to source is needed, and of course whether there might be an obvious workaround.
Expected behavior
Expect the long_callback to register correctly.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 1
- Comments: 22 (4 by maintainers)
@JonThom I missed this issue when you first raised it, apologies and thanks for bringing this case to our attention. The problematic line you link to is in building a cache key for this function invocation, I believe the reason we’re using the function source for that is so the cache will invalidate if you modify the callback code itself. Clearly not a concern if you’ve wrapped the app up and shipped it, it’s really only for apps being actively developed.
@T4rk1n I bet we can fall back on
callback_id
whengetsource
fails - want to give that a shot? Actually… we might even want to always includecallback_id
in generating that cache key, and only add the source if it’s available. It would be weird, but I think you could construct two functions with identical source and identical arguments that nevertheless behave differently - maybe because they’re in different modules and call out to different inner functions, or maybe because there’s a factory function creating these long callbacks and the meat of the operation is passed in to the outer scope.I run into the same problem under Windows 10. Any updates on the issue here?