-
Notifications
You must be signed in to change notification settings - Fork 69
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
Create and publish app #599
Conversation
building releases from tags sounds fine to me, any reason not to do it that way? |
Not really. I always do it that way. |
So how does this work, would someone be able to download it like a binary and run it as a command line tool? |
The easiest way will be to release the entire app's folder, which can be downloaded and run like: /path/to/JuliaFormatter-0.22.10-x86_64-Linux/bin/JuliaFormatter [PATHS...] We'll need to release an artifact for each platform-arch combination. |
another question, how would this interact with VSCode using JuliaFormatter. VSCode has it's own build release process would these be included in that or is it entirely separate? |
If the vscode extension team wants to include this in their releases, they are welcome to, but I am just focused on getting artifacts published to the releases on this repository. |
@davidanthoff would this change anything for you folks? |
I will mention that this would make the extension's formatting faster for the first few runs, but slower overall as this involves invoking a separate binary, doing argument parsing, etc. It would be more optimal to compile the entire vscode extension. |
This PR is already quite nice, but I guess you didn't know Comonicon, it actually takes care of a CLI application, e.g build system images, generating shell autocompletion, handling the CLI's Julia environment, packing tarballs for the application. I made a simpler subcmd for Ion as For windows, I'm wondering how you pack the entire build? I'm not sure it's legit to just ask the user to unzip a set of binaries on Windows? This is why I set up a For *nix systems, I think at least a tarball makes more sense which is also missing from this PR |
Ok, Comonicon could be a better option here. Though it needs at least one new feature; this cpu target needs to be customizable https://github.com/comonicon/Comonicon.jl/blob/master/src/builder/install.jl#L60.
What is wrong with it? Building a proper installer is a huge pain and asking the user to build it themselves is also problematic because it requires they have the time to run the compiler (which takes about 15 minutes). This means you couldn't use this CLI in CI jobs. |
That's not the build pipeline for applications, because of the packing issue, there are two modes, one builds the system image locally, the other builds the tarball the builder CLI has the corresponding help msg for this, basically julia --project deps/build.jl app tarball and you can of course configure the build target for applications in [application]
cpu_target="whatever" but this is not necessary, as I already handled it for you https://github.com/comonicon/Comonicon.jl/blob/master/src/configs.jl#L90
I think for *nix, a tarball or single executable is fine, I'm not a Windows expert, but I hardly see any windows applications installed directly by copying a folder. But I can be wrong. So if the intention is to build the application as an official release of this package on Windows I'd say it's better to do the recommended way otherwise you can just build and host it on your own (I think depends on @domluna ) But at least do a tarball and checksum for *nix build in this PR. This at least helps checking if the download is complete with the original files.
Yes, I understand this is annoying, but Julia doesn't have a mature toolchain for releasing binaries. Comonicon has a feature to download the system image from GitHub release CDN, but that was painful since it's not compatible with things like JLLs. On the other hand, the built application sometimes has issues (compile result is incorrect) after the tag on CI, which is why I decided not to release built apps for IonCLI until it gets more mature: https://github.com/Roger-luo/IonCLI.jl/releases. If we can get stable binaries packed and released on all platforms, no one would want to do so. |
and FYI: JuliaLang/Pkg.jl#1962 |
This shouldn't impact the extension at all since we're just loading JuliaFormatter as a package. It would be nice not to have to deal with any additional dependencies, but using Comonicon seems like it would solve that issue. |
to use Comonicon for Windows, I just need someone to tell me what to do with the installer, or that's not a thing comonicon/Comonicon.jl#175 if that's not a thing, we can just pack a zip file instead of erroring |
I think in general it would be nicer if |
@Roger-luo So if I understand these docs correctly, the best way to approach this project is to create a JuliaFormatterCLI.jl project separate from this one. That project can release tarballs containing the CLI binaries. Users could also add that project and run the installer themselves for other use cases. @domluna Does this approach work for you? I also believe this approach addresses the concerns of @pfitzseb and @davidanthoff as it moves all the changes out of this project. |
sounds like a very good compromise to me |
Yes, the best way to build a CLI application is to have it inside a project module. It can be inside either JuliaFormatter or a new package JuliaFormatterCLI. But I guess to address the concern on VSCode side, we can do it in JuliaFormaterCLI. |
I recently had time to revisit the rewrite of this project. It currently lives in this repo. The proof of concept is implemented. I'll be refining it over the next weeks. |
Status of this? Would be great to have a |
I believe the native code caching in 1.9 will make this work out of the box. Load time will be a little slower than a sysimage though. Worth measuring |
I got a build going based on Comonicon. It works, but the problem is the sysimage size. It's so big that downloading it in a CI job (my main use case) is slower then just eating the time-to-first-format. |
Do the settings |
Using non-incremental mode would increase the binary size. |
how does that work? |
I don't think Julia is in a state to make this PR go anywhere useful. Maybe in the future the binaries can be small enough. |
This PR uses PackageCompiler to create a relocatable app. On my system, the time to run the app is short; using it to format this codebase takes 3 seconds. This isn't blazing fast, but it's substantially better than running the REPL.
There are some remaining questions/tasks before this PR should be merged:
Closes #580. Closes #483.