chocolatey/winget installation option
DRSchlaubi opened this issue · comments
@DRSchlaubi should we publish to scoop or chocolatey?
Everyone I know uses Choco so I guess that would be nice
OK, currently, I'm trying to find how to create such a package and send a PR for creating the choco package. If you have additional info: you're very welcome to share it!
Originally, I wanted to try this myself, and it was really painful, but you can try having more luck here: https://docs.chocolatey.org/en-us/create/create-packages
There now is a native package manager in Windows (great it only took them ages to add it)
So we should add KI to here too: https://github.com/microsoft/winget-pkgs
I am voting for scoop!
I propose using https://jreleaser.org/ as it allows publishing to SDKMAN!, brew, Scoop, Chocolatey and many more with only minimal configuration.
/cc @aalmiray
It doesn't support winget, which is now preinstalled on Windows 10 and 11
FWIW this project already has JReleaser configured.
Winget support has been on our radar but so far no one has requested it jreleaser/jreleaser#185
One more thing, it looks like Winget expects installer files (.exe) while Chocolatey can accept Zip files (no installers). This would mean you'll have to create a suitable installer file first (likely using jpackage) if you want to publish to Winget.
FWIW this project already has JReleaser configured. Winget support has been on our radar but so far no one has requested it jreleaser/jreleaser#185
One more thing, it looks like Winget expects installer files (.exe) while Chocolatey can accept Zip files (no installers). This would mean you'll have to create a suitable installer file first (likely using jpackage) if you want to publish to Winget.
Yes, you're right, winget expects installer files, but imo every project which runs on Windows should have one anyway.
However, wouldn't it work to make the Installer using the new jpackage command? I am not sure whether you can add ki to the path using jpackage automatically though
Yes, you're right, winget expects installer files, but imo every project which runs on Windows should have one anyway.
Should they? Package managers such as Scoop, Chocolatey, and Gofish don't require it. They can install Zips as is. Scoop even supports single JAR installs (where the JAR is an uber executable one).
However, wouldn't it work to make the Installer using the new jpackage command?
Yes. You can create a Windows installers (.exe) using jpackage as an external tool https://docs.oracle.com/en/java/javase/16/jpackage/packaging-overview.html or the JReleaser jpackage assembler https://jreleaser.org/guide/latest/configuration/assemble/jpackage.html
https://akman.github.io/jpackage-maven-plugin/ appears to be the choice for invoking jpackage from Maven (as KI's build is based on Maven) however I've never used so had no clue how it would work out.
I am not sure whether you can add ki to the path using jpackage automatically though
What do you mean with this?
I am not sure whether you can add ki to the path using jpackage automatically though
What do you mean with this?
An installer for a CLI should modify the systems PATH environment variable so it contains the installation path to the CLIs binaries and remove it if you ininstall it, otherwise you can't really execute it, because most people don't remember where they installed it
Should they? Package managers such as Scoop, Chocolatey, and Gofish don't require it. They can install Zips as is. Scoop even supports single JAR installs (where the JAR is an uber executable one)
- there should be an easy way to install it even without a package manager, as this is still Windows and b) Now you gotta hand craft install scripts for all those different package managers, even though most of them already have support to just call installers
there should be an easy way to install it even without a package manager, as this is still Windows
Agreed, in which case you do need an installer. Jpackage would be the recommended way to create such installers.
Now you gotta hand craft install scripts for all those different package managers, even though most of them already have support to just call installers
Eh, no, that's why JReleaser exists, to avoid creating such files by hand.
@aalmiray thank you for looping in! May I please ask you to review the following jreleaser TOML?
[packagers.sdkman]
active = "ALWAYS"
continueOnError = true
releaseNotesUrl = "https://github.com/Kotlin/{{projectName}}/{{tagName}}"
command = "MINOR"
For me, it looks correct, but my fear is SDKMAN requires a special format of an archive — with a directory called like ki-a.b.c inside. Or do I understand it incorrectly?
The snippet looks OK to me. You can drop the releaseNotes property if it follows the conventions, which I believe this project does.
Now regarding the file structure within the archive, it's quite common to have a root entry matching the filename so that ki-1.2.3.zip has a root entry ki-1.2.3. However it might be the case this root entry is not required. Perhaps @helpermethod can help here.
Thank you!
Now I'm curious if I should change the structure of the build archive and thus force all packagers to fix their distributions, and, likely, bump the major version :/ Somehow I was not aware of this convention
FWIW the recent sdkman announcements for 0.4.0 and 0.4.1 point to a 404 release notes url. github.com/Kotlin/ki does not exist.
Oh shoot. Thank you for your notice. Interesting question: is it possible to update the release notes URL retrospectively?
@aalmiray AFAIK the root entry is required.
The requirements are:
- there needs to be a root directory
- with a bin directory underneath
@helpermethod thank you! Also, I already know that the name of the root entry is not that important. It should just be there.
@asm0dey I think you can't update an existing sdkman announcement. But you could post a new one. However I'd suggest to leave it as is, fix the url for the next release.
Remember you may invoke mvn jreleaser:config at any time to display the current model configuration. You may also run a release on dryrun mode with mvn jreleaser:release -Djreleaser.dryrun.
OK folks, I've added SDKMAN support, the next step is Scoop, I believe :)
Who is familiar with publishing there?
Publication to Scoop is similar than for Homebrew. You can publish to the core repo or to your personal bucket/tap. JReleaser prefers the 2nd method for both packagers.