Publish to package managers
volllly opened this issue · 16 comments
I would like to add Rotz to some package managers to ease installation.
My initial thoughts are:
- scoop and winget for windows
- homebrew on macos
- nix, snap or flatpak for linux.
but this is open for debate 😄
I have a prelimnary PKGBUILD for the arch user repo, if you want to get it published there. I'll be willing to take a look into flatpak as well.
Thank you, please share :)
I would use this github action to publish it to the AUR
For flatpak I would use flathub.
I'll set up the repo https://github.com/flathub/flathub/wiki/App-Submission#how-to-submit-an-app
and can give you access If you're interested in tackling this
I am loving this tool so I can do, or at least work on, the homebrew publishing. I have done it before with internal tools and private repos across multiple platforms. I'll open a PR with an outline of the required changes and we can discuss setting up github actions there.
I use homebrew on both MacOS and Linux systems.
Thank you @pho3nixf1re 🙏 that would be super helpful.
I don't have any experience publishing to package managers so any help is appreciated.
I don't think flatpack (and probably snap) would be a good fit for this. Flatpacks are self-contained and run within an virtual environment strictly sandboxed from the host. This app needs lots of access to the file system and the ability to run scripts on the host potentially with admin/root privileges. Potentially these could be granted but it would be a lot of permissions requests and other setup by the user to make work. This is a very simple single file binary so distributing it is easy. A better option may be to provide a bootstrap sh/pwsh script that a user can run via curl/invoke-webrequest or download and run. Similar to how oh-my-zsh or homebrew is setup.
Also, integrating an update-check mechanism into the code would be nice. That way each run it can self-check github's releases.
I'm not set on flatpack/snap they were just my first ideas. You bring up some good points against using them 🙏
I agree that a very good (if not the best) option is simple sh/pwsh bootstrap script. For updating we could experiment with the self_update crate or we could suggest using a tool like eget (with a suggestion to add it to the dotfiles to have Rotz install it). At least an update warning if a new version is available would be nice to have.
What would also be nice is to have Rotz available on "native" package managers that come distributed with the OS (like winget or apt etc.) because installing it would be the easiest that way.
I use Rotz to install non "native" package managers like scoop and homebrew so I would not use them to install Rotz but that's just me and no reason not to publish Rotz there 😁
These are my thoughts on the matter I'm open to ideas/feedback.
I'd welcome your help publishing Rotz on homebrew if you want to tackle that (or something else) 🚀
Looks like homebrew is already in progress by @kecrily at Homebrew/homebrew-core#135639 . I'll see if I can help out that effort.
So one problem with winget I have ran into is that I cannot use it on some corporate laptops since they disable the Windows Store. winget requires the Store as a dependency to function for some reason. Otherwise I greatly prefer it over choco or scoop on windows when it has what I need. Certainly not opposed to publishing it as many places as possible though. Since brew is already done in the above link I will look into scoop/choco but I have never published anything there before. I'm sure it shouldn't be too bad right?
So would you be open to publishing the checksums in the releases description or as assets for each binary with a .sha256 extension? Example URL: https://github.com/volllly/rotz/releases/download/v0.9.4/rotz-x86_64-pc-windows-msvc.zip.sha256. This way we can pull this easily to update package managers. Possible even as part of the github actions workflows here.
Well scoop is a big disappointment. I had everything lined up and started opening the issue/PR but apparently you have to be a "well-known" and popular (lots of github stars) project to be in their repos. It seems capricious and entirely arbitrary but those are the rules. The fallback would be to create your own Scoop bucket git repo and drop the json in there. If that is something you could create I'll open the PR with the manifest file I created.
Here it is for reference https://github.com/pho3nixf1re/ScoopMain/blob/add-rotz/bucket/rotz.json
Hey, I think we could get into the scoop extras bucket.
Extra manifests for Scoop, the Windows command-line installer. For manifests that don't fit the Main criteria.
It seems homebrew has the same problem though. the PR has gotten the notability label ("Project is not notable enough for inclusion").
I think thats overkill ATM but I could move rotz into its own github organization and add a Tap there 🤔
Short term I'll create simple install sh/pwsh scripts #280
I've also added an issue for creating checksum files #279 👌 I'll tackle that with the next release.
Unfortunately the extras bucket also has a popularity requirement. It's reduced but it is still there. I think creating your own tab/bucket is probably best. It's not that tough of a step for users to do that as a pre-install step. The sh/pwsh script is still a good fall back for many use-cases and is a common enough technique.
Ah, you're right. I found 100 stars and 50 forks as the requirement in an issue there.
I think I'll move Rotz into a GitHub organisation in the next few weeks and we can setup a homebrew Tap and a scoop Bucket there 👌
Hey, I've created a personal scoop bucket and homebrew tap. The manifests were adopted from your previous efforts. Huge thanks for the help🙏
Both should be kept up to date automatically through renovate for homebrew and the autoupdate functionality of scoop.
In short: Rotz can now be installed with brew install volllly/tap/rotz or scoop bucket add volllly https://github.com/volllly/scoop-bucket; scoop install volllly/rotz 🎉