People want compiled binary executable for a few reasons, some good, some bad:
- To distribute just one file, already possible, but it’s not small. It can also be tiny with my idea.
- To have everything needed in that file, and it being an .exe. There’s strictly no need that everything is in that file, it just needs to feel that way, give that illusion.
- To hide (all) the source code. Already possible. Would still be possible. Or you could choose to have source and/or binaries for some files, there’s really no need to hide the source code of e.g. open-source dependencies.
- To include all dependencies in that one file. That’s just something NOT needed, a (bad) convention, not shared by executables in all operating systems, nor for all on the same operating system, e.g. on Windows.
- Not need an internet connection after you get the file. Do we really still live in the floppy disk world?
What I propose is that every .jl file you run compiles to .ji binary file, and if you run a .jl file then the cached code in .ji file is used if the timestamp is newer. If there’s a missing corresponding .jl file then it might be an error, maybe be default, or not.
You still get lots of files this way, you could distribute any combination of .ji, or jl files, or both (for all files e.g. if you use GPL) for your whole project. Julia would provide an archive possibility into one file, similar to "[Windowed] Python ZIP Applications”, i.e. .pyz and .pyzw extensions. Are those common? They were new to me, so I thought not.
You COULD if you wish distribute source code and/or binaries of your dependencies, if you wish, e.g. if you think they might go away. On of those dependencies is Julia itself, and it may be the largest one. It’s not hugely important, even much better to skip Julia; and all other dependencies, for smaller files.
But then your one Julia “executable” is not complete.But who cares? You distribute the Manifest.toml file with so you know all of them, and SHAs of all of them. You can download them from all the relevant places that have them available, or if you’re paranoid, from your own website. You need to do that, but only on first use.
Instead of using .jlz similar to Python, which isn’t a registered file type, nor Python’s file types, so you can’t run the file… it will be a self-extracting .exe file, which means in practice a standard ZIP file, but with x86 prefix code to self-extract AND additionally download all binaries. That file could be recognized even on e.g. Linux, ignoring the header (somehow), and if would download everything for Linux for the dependencies. And recompile your code (would assume you do not strip out your source code; theoretically, well very much in practice too, it could just emulate the x86 code).
Python has had the ability to execute directories or ZIP-format archives as scripts since version 2.6
.pyz and .pyzw extensions as “Python ZIP Applications” and “Windowed Python ZIP Applications”, and providing some simple tooling to manage the format.
When should extensions be linked against libpython?
Yes, on Windows. No on POSIX platforms, except Android, Cygwin, and other Windows-based POSIX-like platforms.
I felt I needed to explain the name PackageCompiler:
I don’t know the full history of it, but would you consider renaming the package, may just to Compiler.jl?
What do people think, are people put off by the name, or overlook it, since it implies something it doesn’t (only)?
By now as of Julia 1.9 packages are actually (pre)compiled by default. There’s not huge need for a tool with a name doing that only, or implying it does it only.
What people want is an [app]compiler, i.e. the already existing one.
What I would want for Julia, not an external package, is for even scripts compiled to .ji, as I explained at Reddit. Any reason why it wouldn’t be an easy addition?