Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Artifacts instead of BinaryProvider/build.jl #75

Closed
aviks opened this issue Oct 9, 2020 · 2 comments · Fixed by #76
Closed

Use Artifacts instead of BinaryProvider/build.jl #75

aviks opened this issue Oct 9, 2020 · 2 comments · Fixed by #76

Comments

@aviks
Copy link

aviks commented Oct 9, 2020

It would be useful to use Artifacts and jll packages, instead of creating a build.jl and using Binaryprovider to download the depdendencies.

Using Artifacts has a couple of advantages: 1) it reduces duplication in download and storage of the native depdendencies, and 2) it works via the package server mechanism, which provides a globally replicated CDN, better caching, and better support for proxies.

This would mean however that only Julia 1.3 and above are supported, but I noticed that Turing.jl already has 1.3 as minimum bound, so should be fine to limit this pakage to that lower bound.

@devmotion
Copy link
Member

IMO it would make sense to move away from BinaryProvider and drop support for Julia < 1.2, since it is not supported anymore by Turing (and many other TuringLang packages).

Libtask is a bit special since it requires a specific library for every Julia version (which leads to hickups when e.g. updating Julia, and requires special handling in build.jl). Can such a dependency on the Julia version be handled nicely in the Artifacts system? Is the way to go just to build and distribute all libraries for all Julia version and select the correct one at loading time in the same way as in

@static if VERSION < v"1.0.9999" # (-, v1.1)
const libtask = libtask_v1_0
elseif VERSION < v"1.1.9999" # [v1.1, v1.2)
const libtask = libtask_v1_1
elseif VERSION < v"1.2.9999" # [v1.2, v1.3)
const libtask = libtask_v1_2
else # [v1.3, +)
const libtask = libtask_v1_3
end
? Or can this be done more smoothly nowadays?

@ViralBShah
Copy link

I thought Project.toml can encode the exact versions or range of versions of dependencies for every release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants