Eagerness to avoid LazyArtifacts #444
Conversation
|
Also, this makes me think we should slightly change our post 1.6 support policy: Tier 1: Last LTS release All of this subject to the condition that there aren't critical new features in Currently, our plan is to take current Tier 1 (1.4, 1.5) and make it Tier 2 upon the 1.6 LTS release and make the LTS Tier 1. This is changing plans a bit and going back on a vague support committment, but we also haven't really defined what Tier 1 and Tier 2 support mean anyway... |
Codecov Report
@@ Coverage Diff @@
## master #444 +/- ##
=======================================
Coverage 92.71% 92.71%
=======================================
Files 23 23
Lines 1716 1716
=======================================
Hits 1591 1591
Misses 125 125
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Thanks for picking up on the use of lazy in the Artifacts.toml file. If I understand correctly, it would not have any effect to change it back to lazy=true for julia v1.6.0+ because the artifact is used in the __init__ function. Would the only difference be that the artifact is downloaded at installation time rather than when the package is first used? If so, it doesn't seem very important to make it lazy.
|
@dmbates Your assessment is exactly correct. |
It seems challenging to have lazy artifact downloading be compatible with Julia < 1.6 and 1.6+, see recent test failures and Discourse. However, we use the
TestDataartifact in__init__so they're downloaded with the very firstusing MixedModels, which we can assume most users will want to do not too much after]add MixedModels. So we can avoid all the laziness issues and just be eager. Slightly longer download times upon initial install, but since the artifacts system has its own caching, there shouldn't be any real performance issues as long as we don't changeTestDatatoo often.