elementor / lokl-cli

Interactive script to launch and manage your Lokl sites
The Unlicense
66 stars 7 forks source link

create installable package (Homebrew, ad-hoc, Debian, etc) #12

Open leonstafford opened 3 years ago

leonstafford commented 3 years ago

still deciding if this makes sense....

it does allow for easier upgrading for existing homebrew users (who actually run upgrades), but creates extra work for me and isn't necessary for functionality

yoannsark commented 3 years ago

what do you think about adding a command line in the readme allowing a quick installation by creating something like a /usr/local/bin/lokl with the sh -c "$(curl -sSl 'https://lokl.dev/go?v=4')" inside ?

leonstafford commented 3 years ago

ah, my initially thought was that you were suggesting the Homebrew app is just the 1-line script, same as on website.

After this change, I think the Homebrew isn't too hard to maintain now, as it will be version matched to the Lokl Docker tag, so users can freely update using Homebrew and always get appropriate tag version (I don't think the need to use older versions will be common, but they can still run the 1 liner with older tag version if needed).

If we go with what you suggest here, ie a simple way to save the script as local bin, then it may be nice to add an update check within the script, either at initial load or at same point current script checks for Docker/cURL availability.

The script contains the var LOKL_RELEASE_VERSION, matching to php8-5.0.0-dev, so we could make a request to GitHub API, grab latest tags and prompt user to upgrade (overwrite their script) if there's a newer version. Linking to release notes should be trivial, once that tag is known, too.

Oh, and have an option within the wizard to install the script locally, as lokl to /usr/local/bin/lokl and a note on the website for a way to do it manually.

leonstafford commented 3 years ago

in design decisions, my default target user is non-technical, so not wanting big dependencies or requiring /etc/hosts modifications, etc on their host OS.

But, also catering to programmatic access/advanced, like we see with being able to run noninteractively with CLI arguments.

So, for the noob-first development, the 1-liner is great (security bad practice aside!), but we can and should still support common package management, for those not troubled to install Homebrew or run apt, yum, etc.

leonstafford commented 3 years ago

Also, please don't hesitate to tell me when my ideas are silly, I am often wrong and never take offense 😄

leonstafford commented 3 years ago
yoannsark commented 3 years ago

Okay I see, cool !

I was thinking of a local script that fetches and executes the latest version but indeed, in the long term with major updates, I doubt it's a good approach.