-
Notifications
You must be signed in to change notification settings - Fork 54
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
Relocatability no longer given due to link to TZJData.ARTIFACT_DIR and storing path in const string reference #467
Comments
Thanks for bringing this up. An alternate solution could be to utilize Something we want to avoid is having the artifacts downloaded at runtime within a Docker container. Ideally, precompilation and artifacts are installed during the If you want to create PRs with such approaches you should be able to validate they work in your specific setup (use |
We probably do want to calculate the artifact location at runtime so that overrides are applied. I'll need to think about this more yet. |
I am also encountering relocability issues having a relocated artifacts directory, and the current approach fails precompilation. Has there been updates on this topic ? |
Maybe the |
We have encountered a relocatability issue when creating a multi-stage docker container where we copy an app created by
PackageCompiler
to a clean image after having built it.It now looks for the artifact in the old directory which was valid at build time and is no longer available in the final container.
The hash of the artifact is
520ce3f83be7fbb002cca87993a1b1f71fe10912
and I have verified that this is the hash of the artifact created when imporingTZJData
.Looking for this problem I have found a post with a similar problem with a solution in the following commit.
The problem seems to be the definition of a constant in
TZJData.jl
:which is referenced in
TimeZones.jl
(again, with theconst
keyword, but this time on the reference, so the value is very much mutable):According to the comment in the post mentioned above, "Is it because the const makes the path fixed at compilation, whereas we need it to load and find the artifact each time?", this seems to be a bad idea when trying to keep a package portable.
The solution seems to make both
const
definitions functions instead, i.e., inTZJData.jl
:(not sure about the necessity to put this into a function in the first place), and in
TimeZones.jl
:BUT I am not really sure how this works when building with a different
tzdata
version: InTimeZones.jl
, it says:I have absolutely no clue how/whether this changed content of the referenced string ends up in my compiled app... and if it does (which I assume) how portability could still be ensured, because now it is definitely an incorrect path on my final docker image.
But I guess for the vanilla user not requesting a special version of
tzdata
, my solution would work, but I would need an extra string reference to the new compile dir if the user chooses a different version. That would be quite ugly and still not portable for specialtzdata
requirements...I assume / hope more experienced Julia programmers have better ideas?
The text was updated successfully, but these errors were encountered: