Release strategy for juliac?

Palli · April 5, 2024, 5:01pm

@mbauman, why do you say that? And what would it involve? I mean, I see no movement on the PR, plus it’s just a “placeholder”:

github.com/JuliaLang/julia

cli: Add infrastructure for new CLI drivers `juliax` and `juliac`

JuliaLang:master ← JuliaLang:kf/newclidrivers

opened 11:51AM - 21 Sep 23 UTC

Keno

+183 -4

Following the discussion in #50974, it became clear that there is significant ob…jection to changes to the behavior of the julia CLI driver. Some commenters found changes to the behavior acceptable if they were unlikely to impact existing code (e.g. in the case of #50974 using `__main__` instead of `main`), while other were worried about the reputational risks of even changing behavior in the corner case. In subsequent discussion it became relatively clear that the only way forward that did not raise significant objection was to introduce a new CLI driver for the new behavior. This may seem a bit drastic just for the change in #50974, but I actually think there's a number of other quality-of-life improvements that this would enable us to do over time, for example: - Autoloading/caching of all packages in the manifest - auto-selection of julia versions (integrate juliaup?) In addition, it doesn't seem so bad to have some CLI design flexibility to make sure that the `juliac` driver is aligned with what we need. This PR is the minimal infrastructure to add the new drivers. In particular, it does the following: 1. Adds two new cli drivers, `juliax` and `juliac`. At the moment, `juliac` is a placeholder and just errors, while `juliax` behaves the same as `julia` (except to error on the deprecated `--math-mode=fast`, just as an example of a behavior difference). 2. Documents that the behavior of `julia` (but not `juliax` or `juliac`) is pat of the julia public API. 3. Switches the cli mode based on the argv[0] of the binary. I.e. all three binaries are identical, except for their name, the same way that, e.g. `clang` and `clang++` are the same binary just with different names. On Unix systems, these are symlinks. On windows, separate copies of the same (small) binary. There is a fallback cli option `--cli-mode` that can be used in case the argv[0] detection is not available (e.g. for some fringe embedded use cases). 4. There is currently no separate `-debug` version of the new drivres. My intention is to make this dependent on the ordinary debug flags, rather than having a separate driver. Once this is merged, I intend to resubmit #50974 (chaning `juliax` only), and then finish and hook up `juliac` shortly thereafter.

Adds two new cli drivers, juliax and juliac. At the moment, juliac is a placeholder and just errors

That’s just supposed to be a CLI “driver” yes, so I’m not sure where to look for actual work on the actual compiler improivments, that is at JuliaLang (I know of I think all the outside efforts). Plus, I thought that in effect juliac would just be a standard way, just invoking what’s more or less possible already with PackageCompiler.jl (PC), i.e. not a huge improvement.

Julia precompiles packages already, so it alone can do that, and I DO want arbitrary scripts to be compilable also, it doesn’t seem like a huge leap to do that (and including its dependencies), since PC does that, into one file. But it doesn’t seem it would be better or worse than with PC, it might even be done by it, by juliac downloading it for you and, invoking PC. For now people need to know of it, I suppose it’s documented in Julia’s official docs, or could be with a link.

There’s also AppBundler.jl in case people only want packages easily distributable apps in one file. I belive PG only gives you precompiled in one directory, not file, and you need to distribute it or in a manual step make an installer (e.g. for Windows, it’s documented how in a YouTube video at least). AppBundler does NOT compile (it’s not always needed), and it could be used with PC, at least theoretically.