varabyte/kobweb

Find better ways to distribute the kobweb binary

Closed this issue · 22 comments

bitspittle commented

How to get onto package managers in Linux or Homebrew in Mac? What's the equivalent for Windows?

Support and/or intentionally reject the following package managers:

  • homebrew
  • scoop
  • chocolatey (1)
  • gofish (2)
  • macports (2)
  • snapcraft (3)
  • spec (4)
  • docker (5)
  • sdkman
  • strikethrough means not now, we can close this bug without them, but I'd always be open to supporting them later
  1. The process for Chocolatey feels a bit heavy handed for now. I can't simply self-host, instead I have to go through a whole process with their team, getting a review, etc. Plus, I found it hard to navigate the instructions. I'll leave this off for now, since Scoop is working, but can revisit this again in the future if Kobweb actually becomes regularly used.
  2. Requires setting up PRs on specific repositories, not low hanging fruit
  3. Strict mode is killing me. Snap sets up a whole environment just for Kobweb, making the download 100MB, and yet is getting killed by Snap and snappy-debug isn't really giving me useful information.
  4. Not too familiar with Fedora or spec, but I'm considered adding support for it is diminishing returns and therefore isn't my highest priority.
  5. A docker image is probably overkill. Users will be expected to have java on their machine anyway to compile Kobweb (Kotlin) projects, so I don't need to support an image where Java is included.
helpermethod commented

Hi!

The best way to make the binary available to a large audience would be via JReleaser, which already provides the necessary functionality to publish to SDKMAN!, Scoop, Brew, Chocolatey and many other package managers!

https://jreleaser.org/guide/latest/configuration/packagers/index.html

helpermethod commented

If you need any help, feel free to reach out!

bitspittle commented
  • 👍1
bitspittle commented
helpermethod commented

I'd also add SDKMAN! (which works on Mac, Linux, Cygwin, git-bash, ...) and possibly Scoop, which seems to be popular on Windows.

But you can start with just one packager (as a Mac user I'd start with Homebrew) and then add more packagers over time.

Once the initial setup works, adding more packagers is mostly a two-line config change.

bitspittle commented
  • 👍1
aksh1618 commented

Hi! As an arch linux user, I'd love to have kobweb in the AUR (Arch User Repository), and I'd love to contribute a package for the same (akin to a brew formula). But if the plan is to go the JReleaser way, I am willing to add and maintain an unofficial binary package (a lot of packages in the AUR are unofficial). Please let me know if that's fine!

bitspittle commented
  • 👍1
helpermethod commented

Hi @aksh1618! The maintainer of JReleaser is very responsive and always open for ideas, so it may be a good idea to propose to add AUR packaging support.

  • ❤️1
aksh1618 commented

Hi @helpermethod! Yes, I was considering that, but I wasn't sure because they already have snap support and AppImage & Flatpak support seems to be under consideration, but I guess doesn't hurt to discuss! Created issue for the same.

  • 👍2
aalmiray commented

@bitspittle you are correct. JReleaser can help you getting started with the package managers it supports. Should there be additional targets that are not managed by JReleaser you can still adapt your release process to make that happen, of course the additional packagers would have to be handled outside of JReleaser.

FWIW GoFish is yet another packager that you can use on mac, linux, and windows, which happens to be supported by JReleaser.

Be aware that publication to some packagers is quite straight forward whereas others require signing up for an account, request access keys/tokens, or send a PR following specific guidelines. JReleaser supports:

  • homebrew, scoop. Published to your own tap/bucket. easy.
  • chocolatey. Requires an account and access key.
  • gofish, macports. Requires setting up a PR on specific repositories
  • snapcraft. Requires and account and build setup.
  • spec. Goal is to use with Fedora COPR build service, hence account and build setup.
  • docker. Requires login/password for target registry.
  • sdkman. Requires access tokens.

You don't have to use all of them at once, just letting you know what's possible at the moment. JReleaser let's you configure just what you need.

  • ❤️1
bitspittle commented

@aalmiray I may be running into jreleaser/jreleaser#142 (which is marked closed)

I have a multi-module project here, as documented in the project's ARCHITECTURE.md

The kobweb binary project is under /cli/kobweb/, so what's happening is I'm failing the config step because the basedir is wrong.

(Note, I anonymized my paths, below -- the output from your plugin does not have ... in it)

> Task :cli:kobweb:jreleaserConfig FAILED
[INFO]  JReleaser 1.0.0-M1
[INFO]    - basedir set to /.../kobweb/cli/kobweb

Execution failed for task ':cli:kobweb:jreleaserConfig'.
> Could not determine git HEAD

* Try:
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':cli:kobweb:jreleaserConfig'.
Caused by: org.jreleaser.util.JReleaserException: Could not determine git HEAD
	at org.jreleaser.engine.context.ModelConfigurer.configure(ModelConfigurer.java:45)
	at org.jreleaser.engine.context.ContextCreator.create(ContextCreator.java:75)
	at org.jreleaser.gradle.plugin.tasks.AbstractJReleaserTask.createContext(AbstractJReleaserTask.groovy:103)
	at org.jreleaser.gradle.plugin.tasks.JReleaserConfigTask.displayConfig(JReleaserConfigTask.groovy:66)
Caused by: org.eclipse.jgit.errors.RepositoryNotFoundException: repository not found: .../kobweb/cli/kobweb
	at org.eclipse.jgit.lib.BaseRepositoryBuilder.build(BaseRepositoryBuilder.java:627)
	at org.eclipse.jgit.api.Git.open(Git.java:93)
	at org.eclipse.jgit.api.Git.open(Git.java:73)
	at org.jreleaser.sdk.git.GitSdk.open(GitSdk.java:66)
	at org.jreleaser.sdk.git.GitSdk.head(GitSdk.java:164)
	at org.jreleaser.engine.context.ModelConfigurer.configure(ModelConfigurer.java:42)
	... 121 more

It's not clear what the right path forward for me is. I guess I wish I could pass a path value to jreleaser, or maybe it could query Gradle for what the root path is, or maybe it could navigate up my path looking for a .git folder. Or maybe instead I'm just supposed to declare my jreleaser config in the root project build.gradle? Hmmm, but I don't really want to do that, though.

I'll keep digging and update this thread if I figure it out.

bitspittle commented

Of course one minute after I write my comment I find gitRootSearch in the docs 😜

Unblocked again.

  • 😄1
bitspittle commented

I have to say, JReleaser is a really cool project. I'll definitely tweet about it when this is all hooked up.

I'm going to take a break for tonight and jump back in it tomorrow.

Here's what I have so far. I'm using Gradle to configure things. If any jreleaser folks skim it and can call out anything I'm obviously missing, let me know!

The next steps for me are to:

  • figure out signing (and if I need to do it). I have PGP credentials set up on my machine.
  • get packagers added (brew first, snap second)
  • figure out how to integrate with github workflows to autodeploy when I publish a release using the github UI

@aksh1618 FYI right now my releases look like this: https://github.com/varabyte/kobweb/releases/tag/v0.9.1 but I think starting with v0.9.2 I'll be naming them "Kobweb CLI v0.9.2" for the binary and "Kobweb v0.9.2" for the rest. I decided that when working on my jreleaser configs, which you can see on line 53

bitspittle commented

Oh, @helpermethod and/or @aalmiray I did have one question about releasing projects. Is it normal for people to push SNAPSHOT builds? It seems like the defaults enabled them but I turned them off. I assumed that I would only push out kobweb upgrades after ever release.

aalmiray commented

You can push snapshots as early-access releases using the same configuration (JReleaser does this for its own releases) but you won't be able to push packages using package managers (well except for JBang and Docker) as it makes more sense to use non snapshot releases for those.

bitspittle commented

OK, I think Homebrew support is working. I've put out a few feelers to my friends to see if anyone can try installing it to make sure, but it's late so no responses yet.

I've quietly updated the README (new section here) and will announce Homebrew support on Twitter (and calling attention to JReleaser) after getting confirmation from at least one or two others that it seems to be working fine for them.

brew install varabyte/tap/kobweb in case anyone in this issue discussion would like to try for themselves.

As an aside, this would have taken me so much longer without JReleaser! @aalmiray it's clear you spent a ton of time on the project. It's one of those things that now that I've used it, I don't know how it hasn't existed before. The output of jreleaserConfig is 👌 Eventually I plan to move my changelog / release generation logic to using it.

@aalmiray @helpermethod I've added links to your github names in the README section I linked above as thanks. If you'd prefer I didn't do that for any reason let me know and I can remove them.

@aksh1618 I ended up splitting the releases now instead of waiting to post 1.0 like I originally said I was planning to. The kobweb binary-specific release is now: https://github.com/varabyte/kobweb/releases/tag/cli-v0.9.2 and moving forward should keep that format. This means that the download link is https://github.com/varabyte/kobweb/releases/download/cli-v0.9.2/kobweb-0.9.2.tar

Check out the build config for various values.

I'll keep this bug open until I have support for all the packages suggested earlier.

  • ❤️3
helpermethod commented

@bitspittle The Homebrew installation works perfectly!

image

  • 👍1
  • 🎉1
bitspittle commented

Tried to get snap working today. I learned a lot, but it's harder than I thought to get strict mode working (kobweb calls into gradle and git for various operations, which may or may not be the reason kobweb installed via snap is barfing). I'm going to back off for now.

Next going to look at scoop (since @aalmiray mentioned it's easy), then sdkman (looks like @helpermethod is super involved in that project, nice!), and finally chocolatey, for Windows. I'm not sure yet I'll aim to add support for spec, since at that point it might be diminishing returns?

I've updated the first comment in this issue chain into a checklist to represent these decisions.

  • 🎉1
bitspittle commented

Hey @helpermethod -- I was reading up on SDKMAN! today and had two questions...

  1. My understanding from the docs is that this is a package manager for larger projects where people might want to intentionally maintain multiple versions side by side and change the active version at a moment's notice. Do small binaries like kobweb fit into the model? (Where basically, if you can upgrade, you always should!)

  2. I assume I should be looking at SDKMAN! as a vendor? If so, according to: https://sdkman.io/vendors#access, I should be contacting the team. Could you be my contact? Or am I looking at the wrong instructions? Should I be starting at a different page?

Thanks for any guidance!

helpermethod commented

Hey @helpermethod -- I was reading up on SDKMAN! today and had two questions...

  1. My understanding from the docs is that this is a package manager for larger projects where people might want to intentionally maintain multiple versions side by side and change the active version at a moment's notice. Do small binaries like kobweb fit into the model? (Where basically, if you can upgrade, you always should!)

  2. I assume I should be looking at SDKMAN! as a vendor? If so, according to: https://sdkman.io/vendors#access, I should be contacting the team. Could you be my contact? Or am I looking at the wrong instructions? Should I be starting at a different page?

Thanks for any guidance!

I've seen you've already opened a PR to add the kobweb candidate, good start! For the Vendor API credentials it's best to contact @marc0der via the SDKMAN! Slack channel.

bitspittle commented
  • 👍1
  • 🎉1