Compatibility with `PackageCompiler.jl`
MichaelHatherly opened this issue · comments
Currently Dash.jl (and the related component packages) hardcode paths to resources into globals, see https://github.com/plotly/Dash.jl/blob/dev/src/Dash.jl#L5-L6 for example. This means that the package cannot be used along with https://github.com/JuliaLang/PackageCompiler.jl since that paths are not "relocatable" (https://julialang.github.io/PackageCompiler.jl/dev/devdocs/relocatable_part_3/#Relocatability-of-Julia-packages-1).
The two standard approaches to solving this issue are to either:
- store the actual content of the files located in the resource folders directly into the module's globals, rather than just the paths to those resources, or
- make use of the
Artifactssystem (https://pkgdocs.julialang.org/dev/artifacts/) to provide the resources inPackageCompiler-friendly paths.
Would this allow Julia Dash apps to be compiled into desktop executables? Sounds pretty neat if so.
Yes, pretty much that. We have a workaround at the moment to force the resulting executables to be relocatable, but it's not something I'd like to keep around for too long 😆 I'm happy to look into it a bit more deeply when time allows, it'll likely require adjustments to the component generation code to avoid the hardcoding.
Hi @MichaelHatherly! I wrote the PR #111 with the concept of solving this problem for the dash core. I would be grateful for your feedback and participation in its discussion. If this concept is accepted, then we can do something similar with the components
Hi, @Felix-Gauthier and I recently made dash-textarea-autocomplete work in PackageCompiler compiled apps.
In etpinard/dash-textarea-autocomplete#26, I wrote down some info on how we made things work and some thoughts on how to potentially improve the dash-generate-components command and/or dash-component-boilerplate.
Cheers! (this will be my last PackageCompiler-related comment 😏 )