You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Writing down some info and thoughts that might useful to other Dash component developers that want to support Julia
Release v1.3.1 is the first release which made DashTextareaAutocomplete functional in PackageCompiler compiled apps.
We did so by adding a Artifact.toml to this project (more info on Julia Artifacts here). Julia artifacts only support publicly-available URLs of tarballs as targets, so we tar'ed the min.js and min.js.map files in deps/ in an extra buildsub-command. After npm publish, this tarball is then available on unpkg.com e.g. at https://unpkg.com/dash-textarea-autocomplete@1.3.1/deps/deps.tar.gz
include the Pkg.Artifacts module in src/DashTextareaAutocomplete.jl and addPkg in the Project.toml deps
use the artifact"" string macro to include the tarball content in src/DashTextareaAutocomplete.jl upon initialisation (see Resolve resource path during init #21)
update the Artifact.toml specifications accordingly
PR #25 may eventually streamline this process a little bit more and perhaps make it more robust as well.
Drawbacks
We can't install DashTextareaAutocomplete before we npm publish (as Pkg.add requires the unpkg.com URL to download the artifact). That is, we can't install a dev version of DashTextareaAutocomplete from e.g. a github URL.
Using RelocatableFolders.jl as demonstrated in Try RelocatableFolders.jl #20 would fix this problem, but this would perhaps uncover new problems such as adding a 0.x dependency to DashTextareaAutocomplete and potentially leading to slower performing apps.
Some of the operations in postbuild_fixups.sh are non trivial.
The modifications of src/DashTextareaAutocomplete.jl by the postbuild_fixups.sh script could eventually make their way to dash's dash-generate-componentsjulia component logic. Creating a tarball with min.js and min.js.map files from python wouldn't be too hard either.
But trying to replicate the "update Artifact.toml specifications" step in python might be tricky (can we replicate the behaviour of Tar.tree_hash and sha256 identically in python?) and a bit of a moving target (what if Julia artifacts undergo a breaking change in a future release?). So, I think it would be safer to use a Julia script, but then maybe asking for all Dash component devs to have julia installed to build their components is too much?
The text was updated successfully, but these errors were encountered:
Hi, @etpinard , @Felix-Gauthier !
I have been working on a new system for generating/publishing component packages for Julia from Python packages for quite some time. Unfortunately, the work is not going very fast - because my main job takes up a lot of time and working on the current issues of Dash.jl also distracts from this task.
If you have the time and desire - could you check how your package will be generated and whether it will work with PackageCompiler out of the box?
The development version of components generator is here: https://github.com/waralex/DashComponentsBuilder.jl
For more operational communication, you can write to Julia's slack in the #dash channel, or directly to me there (my nickname is waralex)
Writing down some info and thoughts that might useful to other Dash component developers that want to support Julia
Release
v1.3.1
is the first release which madeDashTextareaAutocomplete
functional inPackageCompiler
compiled apps.We did so by adding a
Artifact.toml
to this project (more info on Julia Artifacts here). Julia artifacts only support publicly-available URLs of tarballs as targets, so wetar
'ed themin.js
andmin.js.map
files indeps/
in an extrabuild
sub-command. Afternpm publish
, this tarball is then available on unpkg.com e.g. at https://unpkg.com/dash-textarea-autocomplete@1.3.1/deps/deps.tar.gzIn
postbuild_fixups.sh
, we:Pkg.Artifacts
module insrc/DashTextareaAutocomplete.jl
and addPkg
in theProject.toml
depsartifact""
string macro to include the tarball content insrc/DashTextareaAutocomplete.jl
upon initialisation (see Resolve resource path during init #21)Artifact.toml
specifications accordingly(along with patching for #11)
PR #25 may eventually streamline this process a little bit more and perhaps make it more robust as well.
Drawbacks
We can't install
DashTextareaAutocomplete
before wenpm publish
(asPkg.add
requires the unpkg.com URL to download the artifact). That is, we can't install a dev version ofDashTextareaAutocomplete
from e.g. a github URL.Using
RelocatableFolders.jl
as demonstrated in TryRelocatableFolders.jl
#20 would fix this problem, but this would perhaps uncover new problems such as adding a0.x
dependency toDashTextareaAutocomplete
and potentially leading to slower performing apps.Some of the operations in
postbuild_fixups.sh
are non trivial.The modifications of
src/DashTextareaAutocomplete.jl
by thepostbuild_fixups.sh
script could eventually make their way to dash'sdash-generate-components
julia component logic. Creating a tarball withmin.js
andmin.js.map
files from python wouldn't be too hard either.But trying to replicate the "update Artifact.toml specifications" step in python might be tricky (can we replicate the behaviour of
Tar.tree_hash
andsha256
identically in python?) and a bit of a moving target (what if Julia artifacts undergo a breaking change in a future release?). So, I think it would be safer to use a Julia script, but then maybe asking for all Dash component devs to have julia installed to build their components is too much?The text was updated successfully, but these errors were encountered: