Epic bug: Please support my favorite package manager!

[bitspittle]

In order to avoid everyone creating one off bugs for the same package manager, this bug will act as a home to collect all such requests received so far. (Of course, once someone starts working on adding support for one of them, that could be a good time to create an individual bug).

Here is the current list of package managers we are considering (but not actively working on):

• apt
• chocolatey
• flatpak
• gofish
• macports
• rpm
• snapcraft
• spec
• winget

---

NOTE: Some of these package managers may never get supported, as I'm not sure how many people actually want to use them, and supporting more releases results in more work on our end.

So even if you see your package manager on this list, it still may be worth leaving a comment below like "Yes, I want that one please! I use it particularly because..."

If you see a comment below from someone expressing support for a package manager that you also want, please give their comment a thumbs up so we can better roughly understand what people are using.

[russellbanks]

It would be nice to have this on Winget! Currently however, Winget doesn't accept zip files but rather installers so we'd have to either wait until they do support zip files (it's an open issue) or create an executable (exe or msi).

[bitspittle]

Thank you @russellbanks for your comment. I updated the initial list to include winget.

Hmmm, it might be possible to create an exe... but at that point I think I would be bundling a jre which might balloon the final size a bit, which may be unfortunate since to use Kobweb the user pretty has to have Java installed on their machine already.

Hopefully, though, winget decides to support .zip files. It is so convenient and would reduce so much friction!

[russellbanks]

I'm not the most well-versed in packaging JVM applications (in terms of bundling the JRE, etc) but is it possible to create an executable without bundling the JRE? If this is not feasible, we could just bite the bullet and bundle the JRE with it, specifying that the recommended option is still the zip file?

Even if this is a temporary solution, I still think I would be advantageous to look into ways we can get an executable working in order to get this on Winget as it is the official package manager for Windows.

P.S. Just a correction to the updated initial list - the link for Winget is https://github.com/microsoft/winget-cli.

[bitspittle]

@russellbanks Thanks for letting me know about the wrong link. I fixed the original comment.

Even if we could build an .exe, just keep in mind I'd want a flow where this could all be done automatically every time I released a new version. With existing package managers, this is basically a one click operation for all of them so far. So we'd need to figure out how to automatically 1) unzip the file, 2) bundle it up into an exe, 3) and publish this to winget.

I personally won't have time to look into this for quite a while, but if someone knows how to do it, and/or has an example of this happening already, please add a comment -- that could help a lot!

P.S. Russell, you may want to check out the https://github.com/jreleaser/jreleaser project and file an issue with them to support winget. I'm relying on them pretty heavily for my other releases, and if winget is the official package manager for windows, they may be interested in getting some signal that people would want it supported.

[russellbanks]

Not much more I can comment on this other than I hope that either Winget supports zip files in the future or JReleaser adds support for Winget. There is an open issue on JReleaser already to ask for support for winget as a packager, but it doesn't seem to have any activity.

[bitspittle]

Great, thanks for the update! With JReleaser leading the way, I will definitely take a look.

…

On Fri, 6 May 2022 at 10:12, Begula ***@***.***> wrote: JReleaser now has an MSI installer which can be published to WinGet. I think we can now proceed. — Reply to this email directly, view it on GitHub <#11>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKNONAWHPPHGI6JK3EKE66TVIVHINANCNFSM5NJWQPUQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[russellbanks]

As of winget 1.4, there will be support for installing zip files. However, this is just a preview at the moment, with the stable version being 1.3. But, this means that Kobweb can be put on winget; it's just a matter of time.

[aalmiray]

FWIW you can use jpackage (on its own or via JReleaser) to create Windows installers (exe, msi) that may be used in combination with Winget.

[bitspittle]

(Sorry for the recent radio silence, folks. I just moved, which wiped out my schedule for a couple of weeks).

As I catch up on stuff, I do intend to look into Winget, although I have a few other priorities to get through first. I'm hoping to get to this by end of September ('22) at the very latest, so feel free to ping this bug if it's later with no progress.

[bitspittle]

Finally, I'm back to this bug and looking into adding winget support. Thanks again for everyone's patience.

@aalmiray I'm trying to follow the Gradle syntax for jpackage from here: https://jreleaser.org/guide/latest/reference/assemble/jpackage.html

but "jpackage" contents aren't autocompleting for me:

(I'm using latest, Jreleaser v1.5.0)

I'm using kotlin script BTW. Maybe "app" is some dynamic thing that works only in groovy scripts?

Is there any demo code for using jreleaser + jpackage I can look at?

Also, according to @russellbanks , winget should support .zip files now (1.4 was released in Jan). Are there plans to add support for that into JReleaser, or will jpackageing be the way to go for a while?

[russellbanks]

@bitspittle

jreleaser/jreleaser#185

https://jreleaser.org/guide/latest/reference/packagers/winget.html#_distribution_support

[bitspittle]

Right, that's what I'm looking at. winget doesn't support .zip file targets according to that distribution support list, so I assume at this point I still need to try running jpackage to create an .exe for now.

[aalmiray]

Zip support in Winget was added in 1.4 but the team has decided to wait until a critical mass of users has migrated to 1.4. See jreleaser/jreleaser#185 (comment)

Once that happens we'll support releasing zips with Winget.

re: auto-completion. app is a free name which you can choose to be anythign you want. It identifies a named element inside a NamedContainer, thus you must use regular KotlinDSL such as

jreleaser {
  assemble {
    jpackage {
      create("kobweb-installer") {
        ...
      }
    }
  }
}

[bitspittle]

Ah perfect, it was a Kotlin script thing. Thanks for the quick reply!

[russellbanks]

Zip support in Winget was added in 1.4 but the team has decided to wait until a critical mass of users has migrated to 1.4. See jreleaser/jreleaser#185 (comment)

@aalmiray zip's were turned on in the pipelines a month or so ago:
microsoft/winget-pkgs#87300

[aalmiray]

@russellbanks gotcha. Will have a look at zips on Winget in the next couple of weeks.

[aalmiray]

Filed a new ticket to keep track of zip support on Winget jreleaser/jreleaser#1253

[bitspittle]

I think I'll hold off on winget until zip support is ready.

It looks like supporting building an MSI/EXE installer will be rather tricky, involving a bunch of structure just for winget that no other package manager has needed. For example, to run jlink / jpackage, I think I would need to set up a special CI workflow using Java 16, since everything else I've done works fine with JDK11 (or older).

And given the extra complexity around this, I have other priorities I should attend to first.

[russellbanks]

I can manually submit kobweb to winget for the time being if you'd like @bitspittle

[aalmiray]

Understood. If it helps at a later stage, have a look a JReleaser's release workflow and configuration which take care of multiple targets during a release.

[bitspittle]

Thanks @russellbanks , I appreciate the offer!

However, I'd want to make sure that everything is handled in the build script so whenever I update the Kobweb binary, I can do everything with a single jreleaserPublish.

Probably best to figure everything out the correct way all at once (or otherwise I might release future versions of Kobweb and winget would fall behind)

[russellbanks]

Anything you do do to automate winget should take the previous manifest and update the values with that of your new artifacts, so a pre-existing manifest shouldn't stop you doing that in the future.

[bitspittle]

@aalmiray Yeah I was using one of your simple workflows as a guide, but seeing that I'd need to set up a bunch of runtime JDKs just for winget seems like a lot of work.

Also, I can just jlink / jpackage a windows binary right? If I don't care about the other platforms?

And if I am building an installer for windows, do I need to make sure to run jreleaser on a Windows machine?

[bitspittle]

@russellbanks where does the winget manifest live? Currently, I have some local repositories (e.g. for homebrew) which jreleaser overwrites for me. Is winget different? (I was skimming the docs but haven't looked too closely yet)

[aalmiray]

Also, I can just jlink / jpackage a windows binary right? If I don't care about the other platforms?

Correct.

And if I am building an installer for windows, do I need to make sure to run jreleaser on a Windows machine?

Correct, again.

[russellbanks]

@russellbanks where does the winget manifest live? Currently, I have some local repositories (e.g. for homebrew) which jreleaser overwrites for me. Is winget different? (I was skimming the docs but haven't looked too closely yet)

microsoft/winget-pkgs

Pull requests are just made to winget-pkgs, usually using and created with a tool like Komac, YamlCreate or WinGetCreate.

P.S. I'm a moderator for winget-pkgs so you can ask me any questions

[bitspittle]

@russellbanks Ah thanks, really helpful info! I don't think I'd mind you submitting an initial manifest for me, then, if it doesn't block me from updating or overwriting it later.

I was trying to search randomly through the manifests.... do you know of a manifest out there which uses the new zip type?

FYI latest Kobweb zip is here: https://github.com/varabyte/kobweb/releases/tag/cli-v0.9.11

However, it's not a standalone zip file. The user will need to have Java 11 (or newer) installed on their machine.

Does winget support the idea of specifying "Java 11" as a dependency, at which point it handles installing things automatically? Or would it be up to me to bundle Java 11 into the zip file?

@aalmiray Does this mean when I run jreleaser targeting winget, it won't immediately update anything but will submit a PR on my behalf?

[russellbanks]

Ah, winget doesn't support dependencies currently. It is planned as a "soon" feature. See Dependencies.md on winget-cli.

For the time being, you could make a second zip that has a stripped JRE using JLink bundled with it? I believe that's what Compose does when you run createDistributable (My compose project is on desktop so may just be for that). That's entirely up to you though.

[aalmiray]

@aalmiray Does this mean when I run jreleaser targeting winget, it won't immediately update anything but will submit a PR on my behalf?

Not by default, no. The original idea was to push to an intermediate repository (winget-kobweb for example) and trigger a GH workflow that pull create a branch and push. The PR would still have to be done manually unless the workflow were to use the gh command. This is how https://github.com/jreleaser/jreleaser-macports is handled.

However, I just added an option to specify a branchPush property on taps/repositories (jreleaser/jreleaser#1129) which would give you the ability to directly create a branch on a target repository such as winget-pkgs, bypassing winget-kobweb. The actual PR would still have to be created manually at the moment.

[bitspittle]

@Skaldebane thanks! I updated the original comment.

Do you have any experience with either of those package managers? At one point, I checked out snap and it was a wasted day.

[Skaldebane]

@bitspittle I've previously created an .rpm for a specific purpose, but nothing really proper.
As for Flatpak, I do have some experience with it (for making a GTK app), but not in the Java ecosystem.

However, I'll try to package Kobweb into one of them when I find some time!

Edit: Both are apparently supported by JReleaser.

[aalmiray]

FWIW JReleaser supports both packagers.

The Native Installer assembler relies on Jpackage to create an .rpm that bundles a Java Runtime along with the app.

The Spec packager OTOH builds an .rpm as expected by Fedora COPR’s build infrastructure.

Lastly, Flatpak may be used to package CLI and/or desktop apps

[bitspittle]

(Ah sorry @aalmiray meant to reply last week!)

Just wanted to say thanks for the last comment. If we can do everything with JReleaser, that's definitely the way to go.

@Skaldebane if you were going to try to experiment with this yourself, the jreleaser config / kobweb binary is actually in a different project. You can find it here. No pressure if you don't have time to work on it; if you ever do, feel free to reach out to me for any help you need.

[Ayfri]

Any update on winget support?

[bitspittle]

Thanks for the reminder @Ayfri . I added it to my near-term todo list to revisit, to see if it will work seamlessly now with latest JReleaser.

I probably have a week or so more of Kobweb work to get through, and then I'll see if I can get winget support working after that. I'll report back here whether it goes well or if there are still obstacles.

[bitspittle]

I probably have a week or so more of Kobweb work to get through, and then I'll see if I can get winget support working after that. I'll report back here whether it goes well or if there are still obstacles.

Just checking in that I've been slammed by a handful of surprises after posting this comment, so my week estimate has apparently ballooned into a month. However, I haven't forgotten this issue, and I am hoping to take a look into it later this week or next.

[Ayfri]

Haha I see, no problem, unforeseen events happen to anyone !

[bitspittle]

Just an update to my winget folks, I do not think the attempt to support winget could be going more poorly.

I've got a bunch of other tasks on my plate, so I'm going to abandon this for now. Apologies at it seems like this is the most requested package manager at the moment.

I will enumerate my concerns below. People with more knowledge of the matter can certainly point out flaws in my thinking or outright mistakes.

• jreleaser doesn't seem to support a Dependencies block (@aalmiray am I missing something here?). It seems like I would probably want to add a PackageDependencies entry for Microsoft.OpenJDK.11 in my case.
  • Note that I briefly looked into jlink but it doesn't seem trivial and I really don't have many hours right now to chase it down. If someone is willing to add jlink support to kobweb-cli that might help unblock winget support.
• jreleaser seems to drop its code into a root directory when I believe should be dropping it under a manifests directory in accordance with the winget PR requested format.
  • e.g. v/Varabyte/kobweb/0.9.13 should probably be manifests/v/varabyte/kobweb/0.9.13?
  • @aalmiray instructions in the docs walking you through uploading a PR for a winget project could be extremely beneficial IMO.
  • Also @aalmiray you mentioned something about using branchPush to push directly to the winget-pkdgs repo but that sounds scary and could also potentially use some docs.
• At this point, winget would be the first package manager that would require me to open an update PR each time I release a new version of Kobweb, which is a HUGE point of friction.
  • Normally, after I release a new version of Kobweb, I update a file which will send a message to Kobweb CLI users that a new version is ready. With winget, I'd have to wait for the PR process to finish before tweaking this file. Otherwise, windows users would be getting a "You should upgrade!" message before they can actually upgrade.
  • What if users report a bug with a new version that I have to fix quickly? If I'm blocked by a winget PR, I can't notify people that a new version is out.
  • Unless I could get a guarantee from winget-pkgs folks that PRs for version updates were automatic and I had a 100% guarantee that I'd get approved on the order of minutes, this lack of control is a dead end to me.
• When I tested installing the zip file of my Kobweb CLI using a local copy of a winget manifest, winget gave me a big scary red error that malware was detected in my zip file. I had to override it to proceed, but.... won't users see that error? The last thing I need when releasing Kobweb software is windows users piling on to tell me my software has malware in it.
• Once I finally installed kobweb locally using winget, it didn't even run. I got an error message popup: "Cannot start or run due to incompatibility with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available." and pressing OK caused windows to flash.

---

My recommendation at this point for Windows folks is to just use scoop or sdkman.

If winget would consider supporting external manifests added manually via remote repositories, and if it wouldn't incorrectly report my code has malware, AND if I could figure out why I was getting those weird "This software is not compatible with 64-bit windows", then maybe I could be convinced to revisit winget support in the near future.

[aalmiray]

@bitspittle I've raised jreleaser/jreleaser#1596 and jreleaser/jreleaser#1597 for the first 2 items.

Using branchPush allows you to create a branch other than the current one when pushing to a given repository. JReleaser lets you by default to push to a winget package repository of your own. It would be your responsibility to create a PR to the shared package repository on your own.

By using the branchPush you may be able (if access rights have been granted) to create such branch directly on the shared package repository. Take note that JReleaser does not yet provides the means to create PRs automatically. Even if a branch were to be created in this way you'd still have to manually create the PR.

The only advantage of using branchPush in this way is to skip your own package repository.

[aalmiray]

One more thing, the report as malware is likely caused by an unsigned package. jreleaser/jreleaser#689 keeps track of this issue

[bitspittle]

Thank you, as always @aalmiray , for the insanely fast response and turnaround time.

If the malware error comes from the lack of signing, it's a shame that winget isn't taking the 256 sha into account. I mean, I'm essentially confirming that my artifacts are hosted in my own repo. I know that just because you're hosting open source software on github, that doesn't mean it can't have malware, but then again, I could always sign my own software which has malware in it, so it's not like it provides that much of an extra benefit as far as I can tell.

That said, I have set up signing for maven in a bunch of places, so if it was clear to me exactly what file winget wanted me to sign and where that key should be found, I could look into adding it, assuming it's some standard signing technology and not something that is windows only. (I have gpg set up in other projects of mine)

[aalmiray]

😅 Thanks. It was fun adding what was missing for winget.

Regarding signing, if this is indeed the case then I'm afraid you must use Windows' signtool which is setup way differently to PGP (what Maven Central requires at the moment).

[Treetrain1]

Would you consider supporting an AUR package?

There is a package on the AUR, but it's very out of date. The latest supported version is 0.9.12.

[aalmiray]

@bitspittle you may recall we have pending support for AUR in JReleaser jreleaser/jreleaser#693

[bitspittle]

@aksh1618 are you still around? The AUR work you did for Kobweb so many years ago broke when I had to move the kobweb CLI out into a different repository. Would it be easy to fix up the script you wrote to use this new repository location?

[aksh1618]

Hey @bitspittle! Ah I see, I think the action should work in this repository as well without too many changes, let me double check and get it back up this weekend. I'll reach out to you on discord if I need anything w.r.t. permissions etc.

[bitspittle]

@aksh1618 I found that you actually shared the private key with me many years ago which I forgot I had. Looking over the old github workflows, I believe I have everything I need to update the AUR package on my end. Thanks!! I'll see if I can get the AUR package updated in the next day or two.

[bitspittle]

@Treetrain1 would you mind trying now to see if AUR is correctly hooked up again? (@aksh1618 you might be able to check as well but no pressure)

Here are some old instructions, which I'll add back into the Kobweb README if this is confirmed working.

---

Arch Linux

With an AUR helper:

$ trizen -S kobweb

Without an AUR helper:

$ git clone https://aur.archlinux.org/kobweb.git
$ cd kobweb
$ makepkg -si

[aksh1618]

@bitspittle I just checked it on my machine, seems to be working perfectly! The instructions also look good 👍

[bitspittle]

Thank you @aksh1618 for confirming!

By the way, when a new version of Kobweb comes out, if you already have a previous version installed, what is the proper way to update?

(I'm asking because I need to update this section)

[aksh1618]

In this case there is no separate command to update, it will basically be the same as the installation command. So maybe you can put the same command. (Usually on arch you periodically run updates using the aur helper and everything that has an update gets updated in one go)

[bitspittle]

@Treetrain1 thanks for leaving a comment! Arch Linux should be supported now (again). At this point, moving forward, the AUR kobweb entry should get automatic updates again.

Instructions added into the README here: https://github.com/varabyte/kobweb#arch-linux

@aalmiray thanks for considering AUR support in jreleaser. At the moment, I don't need it, and I definitely don't expect you to prioritize it, but if it ever makes it in, let me know, and I can migrate over to it. Feel free to reach out to me if you want me to share all the steps I'm currently doing at the moment to automate an AUR package publication.

[bitspittle]

Uh whoops, I have no recollection of closing this issue (which I mean to keep open forever basically). I must have misclicked on mobile. Maybe I should move it to a discussion someday instead. Anyway, reopening.