Return of the build script via Preferences #483
Conversation
|
Wayland issues xref: sciapp/gr#141 |
Codecov ReportBase: 40.71% // Head: 38.00% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #483 +/- ##
==========================================
- Coverage 40.71% 38.00% -2.72%
==========================================
Files 7 8 +1
Lines 2692 2892 +200
==========================================
+ Hits 1096 1099 +3
- Misses 1596 1793 +197
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
|
cc: @sjkelly , it turns out the alternate binaries are still useful for Wayland support. |
|
I think that the build script can be simplified, instead of just copy-paste what was removed in #465. |
|
This sounds reasonable to me. I appreciate everyone filling in the gaps in my artifacts PR. I assume this doesn't break precompilation on 1.8+? |
Yes, I'm working on it. I just wanted to develop a proof of concept to see if the old script still works before I starting cutting it down.
I have not modified the To decide:
|
Xref timholy/SnoopCompile.jl#295, this would have to be tested against |
|
Yes, this would simplify the installation of the GR tarball for many users. However, the runtime problem under Linux still exists. I could only achieve correct results with the |
Addressing #484 may resolve the issue. Basically if we use |
|
@mkitti : Thanks for your PR. Would it be possible to "control" the behaviour from outside Julia, e.g. The background of my question is: We use Julia in a read-only network environment with pre-installed packages (which are maintained daily) for all users. Possibly a strange requirement, but the process has proven itself. |
Yes. Essentially you could preconfigure by providing an Overrides.toml in the depot and a LocalPreferences.toml in the project. Depot based Overrides.tomlThe first mechanism is older and allows for overriding the binary locations via a depot based Overrides.toml [1]. julia> using GR
[ Info: Precompiling GR [28b8d3ca-fb5f-59d9-8090-bfdbd6d07a71]
julia> GR.GRPreferences.use_upstream_binary(; force = true, override = :depot)
┌ Info: Downloading pre-compiled GR 0.69.1 Ubuntu binary
└ file = "/tmp/jl_rbiTw2/gr-0.69.1-Ubuntu-x86_64.tar.gz"
┌ Info: grdir
└ grdir = "/home/mkitti/.julia/dev/GR/deps/gr"
[ Info: Please restart Julia to change the GR binary configuration.
What that does is create an Overrides.toml in the Julia depot: Thus, one option that you have is to simply create that Overrides.toml in the depot. The UUID there is that of GR_jll: julia> GR_jll.libGR
"/home/mkitti/.julia/dev/GR/deps/gr/lib/libGR.so"
julia> GR_jll.libGR3
"/home/mkitti/.julia/dev/GR/deps/gr/lib/libGR3.so"
julia> GR_jll.libGRM
"/home/mkitti/.julia/dev/GR/deps/gr/lib/libGRM.so"
julia> GR_jll.gksqt_path
"/home/mkitti/.julia/dev/GR/deps/gr/bin/gksqt"
julia> DEPOT_PATH
3-element Vector{String}:
"/home/mkitti/.julia"
"/home/mkitti/src/julia-1.8.1/local/share/julia"
"/home/mkitti/src/julia-1.8.1/share/julia"Note that above not only have we instructed GR to load the alternate binaries, but we've now also redirected GR_jll to alternate binaries. This should comprehensively take care of the binary issue. You should not need Recall also that depots stack on the system depots. You could also locate the Overrides.toml in It also still makes the modification to the LocalPreferences.toml stored in the same directory as the Project.toml to memorize this configuration setting: Project based LocalPreferences.toml configurationAnother option involves only using LocalPreferences.toml, stored in the project [2]. Here I've installed GR into Here the paths to the individual binaries is stored in the LocalPreferences.toml. SummaryYes, you can control which binaries are loaded by defining either References[1] Overrides.toml in the Pkg.jl documentation. https://pkgdocs.julialang.org/v1/artifacts/#Overriding-artifact-locations |
To clarify, the |
|
@mkitti : Thanks for the detailed explanations. If I can merge, just give a quick shout. |
| function get_version() | ||
| _version = version | ||
| if "GRDIR" in keys(ENV) | ||
| if isempty(ENV["GRDIR"]) | ||
| _version = "latest" | ||
| end | ||
| end | ||
| return _version | ||
| end |
There was a problem hiding this comment.
Can't we pin GR_jll in https://github.com/jheinen/GR.jl/blob/master/Project.toml, and remove this ?
There was a problem hiding this comment.
Any thoughts about this @jheinen . Do we need the version to be latest if the GRDIR environment variable is set?
There was a problem hiding this comment.
No, for development purposes, there are probably better ways to test the latest run-time. End users don't need this.
More concise! Co-authored-by: t-bltg <tf.bltg@gmail.com>
|
The functionality is where I would like it. However, I think we should still do the following:
What is the best way to update the Sphinx documentation at gr-framework.org? Otherwise, I'll just update the README. Perhaps we should implement Documenter.jl based documentation? |
To get ahead quickly, the README file should be updated. The official GR documentation is unfortunately only in a private repo.
Would probably make sense in the medium term. I would have to find out how to integrate this sensibly. |
I can help open another pull request on this after we merge this. |
|
There definitely seems to be some kind of race condition going on with |
This restores the build script to facilitate downloading the GR binary. It is currently imported via GRPreferences. The main purpose of restoring the build script is as a fallback when the BinaryBuilder binary does not work. For example, Wayland support is currently lacking in the BinaryBuilder QT builds.
Currently, this script can be invoked via
I'll probably change the function name to make it clearer that this downloads a binary.
cc: @t-bltg