Artifact compile-time constancy vs relocatability?

[tkf]

According to 2b2ee1f which is part of #37320

Compile-time constancy; when @artifact_str is given a constant String, it optimizes the generated code by looking up the appropriate hash at compile-time and embedding just that hash into the resultant code, saving on both lookup time and objects that must be serialized to the eventual precompilation .ji file.

Wouldn't this make system images less relocatable in 1.6? That is to say, IIUC, PR #37320 makes it hard to use a system image compiled in one machine to other machines. This might not be a big issue since building system images is still an advanced Julia usage. But I think it'd be nice to make it easier to re-distribute system images at some point.

I'm guessing the compile-time constancy is an implementation detail for an optimization. If so, this is a rather low-priority "issue" since it can be changed at any point. But I'm bringing this up since run-time lookup could be a better approach for relocatability (and I couldn't find a relevant discussion by skimming #37320 and JuliaLang/Pkg.jl#1780).

Is there a plan to make packages with artifact as relocatable as possible? (Or maybe it's already the case in 1.6-DEV and I'm missing something?)

cc @staticfloat @KristofferC

[KristofferC]

Wouldn't this make system images less relocatable in 1.6? That is to say, IIUC, PR #37320 makes it hard to use a system image compiled in one machine to other machines.

Why? As far as I understand, its only the hash lookup that is done at compile time, the computation of the final path is still runtime and depends on DEPOT_PATH.

[staticfloat]

Kristoffer is right; none of this affects relocatability since the actual path is always computed at runtime as relative to the current set of depots.

[tkf]

OK, I saw the full path (artifacts_toml) is passed to _artifact_str but I suppose it's only used for error reporting? Anyway, thanks for the explanation.

[staticfloat]

Yes, that’s correct!