-
Notifications
You must be signed in to change notification settings - Fork 10
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
Comments
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 Lines 16 to 24 in 66104ba
|
I thought Project.toml can encode the exact versions or range of versions of dependencies for every release. |
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.
The text was updated successfully, but these errors were encountered: