Make WebIO statically compilable (relocatable): don't run include()s in __init__

[NHDaly]

If you statically compile an application that uses WebIO, it will attempt to run this Module init at runtime, but of course those source files will no longer be present once the application has been downloaded to a user's computer.

Please see these sections from the PackageCompilerX for an overview of relocatability:

• https://kristofferc.github.io/PackageCompilerX.jl/dev/apps/#Relocatability-1
• https://kristofferc.github.io/PackageCompilerX.jl/dev/devdocs/relocatable_part_3/

(I made this code change months ago but never sent it for review, so i don't remember what the errors were. But rereading the diff, it seems reasonable. I'll rebase and update it now..)

[NHDaly]

@travigd Can i request a review from you? 😁

---

Updated to use include_string instead of eval so that the filenames are still preserved, exactly as if it was a normal include:

julia> which(Base.isopen, (WebIO.WSConnection,))
isopen(p::WebIO.WSConnection) in WebIO at /Users/nathan.daly/.julia/dev/WebIO/src/providers/generic_http.jl:13

[codecov]

Codecov Report

Merging #378 into master will increase coverage by 0.18%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #378      +/-   ##
==========================================
+ Coverage    62.1%   62.29%   +0.18%     
==========================================
  Files          16       16              
  Lines         599      602       +3     
==========================================
+ Hits          372      375       +3     
  Misses        227      227

Impacted Files	Coverage Δ
src/WebIO.jl	80.95% <100%> (+3.17%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e261042...915c36c. Read the comment docs.

[twavv]

Does this work with frontends? The JavaScript is still just static files that we include on the JS side for the most part.

I'm not familiar enough with the package compilation to even know where to begin with answering that. 🤓

[NHDaly]

Does this work with frontends? The JavaScript is still just static files that we include on the JS side for the most part.

I don't fully understand the question, unfortunately. What do you mean "the frontends"?

Anyway, I think this shouldn't change anything for normal julia execution.. we're just preloading the strings from the files during precompilation, and evaling them at runtime, instead of reading the files at runtime. This is needed because for a "shipped" executable, those files are no longer present at runtime.

But other than that, there should be no change! :)

[twavv]

(preamble: I know nothing about the package compilation stuff so these might be rather basic questions and/or represent a faulty understanding of how things work)

My concern (or uncertainty, I guess) is around how the package compilation process will handle asset files.

For example, in Blink, we have some static JS and HTML and CSS files and they're references at runtime. For example, whenever a window is loaded, we require the WebIO JS bundle, which lives at ~/.julia/packages/WebIO/packages/webio/dist/webio.js (or something like that). We use the pretty standard (afaict) way of referencing them:

WebIO.jl/src/WebIO.jl

Line 17 in e7585c5

const packagepath = normpath(joinpath(@__DIR__, "..", "packages"))

My question is whether or not that is going to cause issues when we try to load it.

[NHDaly]

Ah, thanks for explaining. Yes, that is definitely a problem as well! 😁

The ApplicationBuilder.jl package has some infrastructure set up to let you list "assets" like these, which get copied into the final .app bundle, and then you have to manually add some code in your project that says basically if _is_static_compiled_() @eval WebIO const packagepath = "assets/webio/packages" or wherever you had them moved to. It's super hacky and dumb, but this is how it is for now.

However, that doesn't work for things that are referenced in the __init__() function of a module, because the __init__() is run before your code gets a chance to override the path! So basically, the rule is that references to absolute paths from within __init__() functions are hostile to relocatability of Applications. (Thus, this PR)

---

That said, the ultimate best approach would probably be to make any assets like that into Artifacts through Julia's new Artifacts system, since those are totally path-agnostic and relocation-friendly, but I dunno if that would be overkill for something like what you're describing...

[twavv]

I have no opposition to making assets into artifacts (though ideally, I'd like to keep compatibility with Julia 1.0 - I'm not sure if that's an issue?).

I don't really want to do that work myself though. :^)

[twavv]

LGTM.

[NHDaly]

Yeah agreed. And i'd say there isn't really much reason to. For those who care about it, the hacks i described above are mostly good enough for now...

[shashi]

Nice PR! :-)

About frontend assets, @ranjanan once got an app to compile. The main idea is to keep the assets in some path and setup a const like @NHDaly showed, then AssetRegistry.register them in __init__, or just use them in Scopes so it's automatic.