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

On Julia nightly: ERROR: LoadError: Artifact "tzdata2020d" is a lazy artifact; package developers must call using LazyArtifacts in TimeZones.TZData before using lazy artifacts. #310

Closed
DilumAluthge opened this issue Nov 23, 2020 · 6 comments · Fixed by #312

Comments

@DilumAluthge
Copy link
Contributor

DilumAluthge commented Nov 23, 2020

This only happens on Julia nightly.

@staticfloat Does this need to be fixed in the TimeZones.jl package? Or is it something that needs to be fixed in Julia itself?

    Building TimeZones → `~/.julia/scratchspaces/44cfe95a-1eb2-52ea-b672-e2afdf69b78f/69f312cdb1b3145761d4e5866034efde4608735d/build.log`
ERROR: Error building `TimeZones`: 
ERROR: LoadError: Artifact "tzdata2020d" is a lazy artifact; package developers must call `using LazyArtifacts` in TimeZones.TZData before using lazy artifacts.
Stacktrace:
  [1] error(s::String)
    @ Base ./error.jl:33
  [2] _artifact_str(__module__::Module, artifacts_toml::String, name::SubString{String}, path_tail::String, artifact_dict::Dict{String, Any}, hash::Base.SHA1, platform::Base.BinaryPlatforms.Platform, lazyartifacts::Any)
    @ Artifacts /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Artifacts/src/Artifacts.jl:548
  [3] #invokelatest#2
    @ ./essentials.jl:707 [inlined]
  [4] invokelatest
    @ ./essentials.jl:706 [inlined]
  [5] macro expansion
    @ /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Artifacts/src/Artifacts.jl:684 [inlined]
  [6] build(version::String, regions::Vector{String}, archive_dir::String, tz_source_dir::String, compiled_dir::String; verbose::Bool)
    @ TimeZones.TZData ~/.julia/packages/TimeZones/CNOFt/src/tzdata/build.jl:52
  [7] build(version::String)
    @ TimeZones.TZData ~/.julia/packages/TimeZones/CNOFt/src/tzdata/build.jl:115
  [8] build(version::String; force::Bool)
    @ TimeZones ~/.julia/packages/TimeZones/CNOFt/src/build.jl:11
  [9] build
    @ ~/.julia/packages/TimeZones/CNOFt/src/build.jl:11 [inlined]
 [10] top-level scope
    @ ~/.julia/packages/TimeZones/CNOFt/deps/build.jl:3
 [11] include(fname::String)
    @ Base.MainInclude ./client.jl:444
 [12] top-level scope
    @ none:5
in expression starting at /home/runner/.julia/packages/TimeZones/CNOFt/deps/build.jl:3
@staticfloat
Copy link
Contributor

staticfloat commented Nov 23, 2020

@vtjnash it looks like your recent PR did not make this a deprecation warning, but instead an error.

X-ref: JuliaLang/julia#37844

@DilumAluthge
Copy link
Contributor Author

Should I close #311 in favor of fixing this in Julia?

@staticfloat
Copy link
Contributor

Okay, looking more closely, it appears that the source here is redefining the @artifact_str macro themselves:

macro artifact_str(name)
# Load Artifacts.toml at compile time, so that we don't have to use `__source__.file`
# at runtime, which gets stale if the `.ji` file is relocated.
local artifacts_toml = find_artifacts_toml(string(__source__.file))
if artifacts_toml === nothing
error(string(
"Cannot locate '(Julia)Artifacts.toml' file when attempting to use artifact '",
name,
"' in '",
__module__,
"'",
))
end
local artifact_dict = load_artifacts_toml(artifacts_toml)
return quote
# Invalidate .ji file if Artifacts.toml file changes
Base.include_dependency($(artifacts_toml))
# Use invokelatest() to introduce a compiler barrier, preventing many backedges from being added
# and slowing down not only compile time, but also `.ji` load time. This is critical here, as
# artifact"" is used in other modules, so we don't want to be spreading backedges around everywhere.
Base.invokelatest(do_artifact_str, $(esc(name)), $(artifact_dict), $(artifacts_toml), $__module__)
end

This is not Jameson's PRs' fault. :P If this package is complex enough to redefine that, they can either import Pkg completely or import LazyArtifacts on 1.6+.

@DilumAluthge
Copy link
Contributor Author

DilumAluthge commented Nov 24, 2020

they can either import Pkg completely

They already do this. Should importing Pkg be sufficient to fix this error?

@DilumAluthge
Copy link
Contributor Author

Ah. So I need to also import Pkg into the submodule.

@DilumAluthge
Copy link
Contributor Author

Okay, this issue will be fixed by #312

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.

2 participants