search

hkdb / app

A cross-platform package management assistant with super powers!
https://hkdb.github.io/app/
Apache License 2.0
54 stars 2 forks source link

Consider providing binaries #1

Open RichardFevrier opened 1 month ago

RichardFevrier commented 1 month ago

Please consider providing binaries (can be easily generated by github workflow). Remove bash scripts (install & update) and merge them into main.go (update can be handle with selfupdate packages there are multiple doing that job).

hkdb commented 1 month ago

@RichardFevrier Thanks for the feedback! I am currently time crunched and focused on chasing features/bugs for my personal use case in the short-run but once that's out of the way, I will certainly work on making distribution a little bit more friendly as you suggest especially if there's a demand for it. :)

hkdb commented 1 week ago

@RichardFevrier The latest release (v0.11) should hit a lot of what you were talking about in terms of installation via binaries. Let me know if you have any feedback.

One thing I haven't done and plan on fixing is that update currently does not check the currently installed version against the latest version. It just overwrites no matter what.

RichardFevrier commented 1 week ago

Overwriting no matter what is a good enough solution I think 🙂

I was curious when you merged #4 why it didn't produce the binaries for the v0.09 release since I did checked it worked on my side before the request. Seeing your commit 8e1000d I think I understand now. You've created the release before creating the tag am I wrong?

hkdb commented 1 week ago

I actually sent you an e-mail about that with a screenshot of the error but it must have been eaten by spam filters or the Internet monster. I do releases through the web UI and it requires me to create the tag in parallel of submitting a release so when the job runs, it fails to create tag because the tag already exists. So instead, I changed the job to upload artifacts to existing tag instead of creating a new tag.

hkdb commented 1 week ago

Oh and I personally couldn't stand "just overwriting" for the update function 😅️ so for v0.13, update checks for the latest version and compares it with the currently installed version to determine whether or not it should move forward with the update.

hkdb commented 1 week ago

Last but not least, If all looks good to you, I am thinking we can close this issue...

RichardFevrier commented 1 week ago

I actually sent you an e-mail about that with a screenshot of the error but it must have been eaten by spam filters or the Internet monster. I do releases through the web UI and it requires me to create the tag in parallel of submitting a release so when the job runs, it fails to create tag because the tag already exists. So instead, I changed the job to upload artifacts to existing tag instead of creating a new tag.

Exact my solution creates automatically the release when the tag is created but do how you prefer 🙂

RichardFevrier commented 1 week ago

What about using the latest binary instead of compiling the app in the install and update scripts before closing this issue?

hkdb commented 1 week ago

Starting v0.11, users could already use a single command to install the binary way.

The single command is listed in README.md, docs/INSTALL.md, docs/UPGRADE.md, and https://hkdb.github.io/app (dist dir is automatically deployed to github pages on release)

The actual script this single command utilizes is dist/getapp.sh or in reality, https://hkdb.github.io/app/getapp.sh.

To update app, simply running app -m app update will do. What it actually does is it checks against https://hkdb.github.io/app/version.txt ( dist/version.txt ) to determine what the latest release is and if current version is < latest version, it utilizes the script in https://hkdb.github.io/app/updateapp.sh ( dist/updateapp.sh ) to download the binary and overwrite the existing binary.

I actually did a more high level writeup about this and gave you a shout out:

https://medium.com/@hkdb/app-v0-13-is-officially-released-fd7ca6fd1aa2

If you need a friend link instead, I am more than happy to send you one privately.

install.sh & update.sh will remain as is for those who prefer to install and update by compiling and of course, to make dev/test easier. I did however bring over the new code from dist/getapp.sh and dist/updateapp.sh for configuring dot files etc since it accounts for the various shells much better and I removed all the code for installing different package managers so as to stay true to the concept of leaving it to the user to configure their package managers properly.

The idea is, if you want to install and update the binary way, you never even have to clone the repo. However if you cloned the repo, installing and updating by compiling is a first class citizen. 🙂

Then again, you can also run ./dist/getapp.sh and ./dist/updateapp.sh directly from the repo if you prefer to install the binary way from within the repo.