Closed t-bltg closed 2 years ago
Ping @jheinen for the offending line in GR.jl
: https://github.com/jheinen/GR.jl/blob/a79963f1170115d538115587a0ac3af6584086a7/src/funcptrs.jl#L32.
I have a WIP PR to fix moves that moves GR to Artifacts and Preferences that should fix this: https://github.com/jheinen/GR.jl/pull/465
I will try to pick this up shortly.
Awesome, thanks for working on this !
So this means, we can no longer use a common distribution with full feature built binaries for different languages/environments? I don't want to oppose this MR, but is it really worth it when other packages have load times that are many times longer?
@jheinen You still can. You can use Preferences or overrides in Pkg to distribute your own binaries. If this is regarding my PR in GR; I have not yet completed it yet, as documentation of the new process is the most important part.
From what I can tell, the core problem here is that we can no longer eval
in dependencies. So for the case of GR we will always load GR_jll
. We then instead use the mechanisms in Pkg (such as Preferences) to change what is dlopen
ed in GR_jll
.
You can use Preferences or overrides in Pkg to distribute your own binaries
It would be great to add a Preferences
usage example in https://github.com/jheinen/GR.jl/pull/465 (maybe in the docs).
@sjkelly : Thanks for the explanations - I understand. As mentioned by @t-bltg, a Preferences
usage example would be great. Hopefully, we can then still use one GR version for different pre-configured REPL environments in our JupyterHub (Julia, Pluto, Python, ...).
With Preferences
, you mean Preferences.jl
?
Yes, Preferences.jl
is meant here.
A real world example (that I often use) is MPI.jl
where they have a small package called MPIPreferences.jl
which uses Preferences.jl
to select different MPI
implementations (mpich
, openmpi
, craympich
, ...) and different binaries (artifacts
, local builds, ...).
Hopefully, we can then still use one GR version for different pre-configured REPL environments in our JupyterHub
Having an example of usage in a public repository somewhere might help @sjkelly to cover all the specific / targeted GR
cases with Preferences.jl
.
@sjkelly : Would the current GR development branch be OK for you?
I can confirm that the develop
branch solves this issue and would allow https://github.com/JuliaPlots/Plots.jl/pull/4334.
Very cool. Nice work, both! Should this be closed or are there outstanding issues to resolve?
I'll close this once https://github.com/JuliaPlots/Plots.jl/pull/4334 is merged ;)
@jheinen it looks good to me if you would like to merge. I will circle back around sometime this weekend with some cleanups to the docs and such.
@timholy, I am trying to rewrite the pre-compilation process for
Plots.jl
usingSnoopPrecompile
and@precompile_setup
and@precompile_all_calls
(after https://github.com/JuliaPlots/Plots.jl/issues/4079#issuecomment-1047716834).Here is my attempt:
src/Plots.jl
Running
$ julia -e 'using Plots'
, fails with:I tried moving the GR
import
s to the@precompile_setup
section but it fails as well (import GR; GR.init()
).