Ability to version-lock Dash.jl and required core component libraries

[rpkyle]

In both Dash for R and Python, dash requires the three core component libraries be loaded first. In Dash.jl, the reverse is currently (as of this writing) true.

While there are multiple possible solutions to "locking" release versions of Dash.jl with DashTable, DashCoreComponents, and DashHtmlComponents, the following conditions must be resolved before this issue can be considered closed:

• when you install Dash.jl, the core component libraries DashTable, DashCoreComponents and DashHtmlComponents should automatically be downloaded and installed
• the versions of the core component libraries which are installed must be compatible with the installed version of Dash.jl
• upgrading Dash.jl automatically triggers an update to the three installed core component libraries
• regardless of the chosen approach, we should try to avoid warning messages/errors

A relevant discussion about addressing "reverse dependency" issues may be found here: plotly/dash#1062 (comment)

[waralex]

I experimented with dependencies and found out that I didn’t have a very good idea of how they worked in Julia. There is much to discuss.
First of all, if Dash has dependency DashHtmlComponents, this does not mean that the user will be able to do using DashHtmlComponents after Pkg.add("Dash"), as we probably expected. The user still needs to do Pkg.add("DashHtmlComponents") . This dependency means that the version that fits Dash will be added by default to current environment at Pkg.add("DashHtmlComponents"). If the user tries to install an incompatible version, he will get an error. On the other hand, if DashHtmlComponents are already added to the current environment and the user tries to add Dash whose dependencies these components do not satisfy, he will also get an error. (edited)

It works, as I understand it, in the following way. Julia can store multiple versions of packages at the system level, and each environment has a Manifest.toml file that specifies which version of the package is used in this environment.
Pkg.add adds the package to the namespace. Checks its dependencies with other dependencies in the current environment and writes versions for all dependencies to the manifest, or returns an error if there is an unresolved version conflict. The dependencies themselves are not added to the namespace.

Therefore, 2 solutions seem to be suitable for solving our problem.

• Include the component code itself in the package as submodules and export them to an external namespace
• Add a DashBase package, reverse dependencies, and leave the components as separate packages, but again export them from Dash to an external namespace, something like:

using DashHtmlComponents
export .DasHtmlComponents

in Dash.jl file

In both cases, the user can include components using one of the following methods:

using Dash.DashHtmlComponents

or

using Dash
using .DashHtmlComponents

[Byrth]

I would suggest looking into the Artifact system. It would restrict your compatibility to Julia 1.3+, but it should solve this problem even though your package isn't registered in JuliaRegistries/General.

As a basic overview of Artifacts, you can define the artifact name, git-tree-sha1 (for the right version) and download URL. It is intended to be used for non-Julia resources like your DashCoreComponents. Here is an example from Timezones.jl, which downloads a lot of artifacts. This also should make your project absolute path independent, which would make apps including dashboards easier to ship.

[rpkyle]

@waralex has successfully addressed this following his work on creating and loading DashBase.jl, so I believe that I may close this one as resolved.