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)

Most upvoted comments

@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 when getsource fails - want to give that a shot? Actually… we might even want to always include callback_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?