1-line installer: incrementally install 4 dependencies, so no UX delay (improves compatibility on other Linux distributions)

[holta]

Improvement that should resolve #154 thanks to @sptankard & @tim-moody

See Also:

• http://FAQ.IIAB.IO > "7 What OS should I use?"
• https://github.com/iiab/iiab/wiki/IIAB-Platforms#operating-systems

[holta]

FYI I'm intentionally delaying apt update until Line 177 here, so the interactive UX is not unecessarily delayed:
https://github.com/holta/iiab-factory/blob/1-line-installer--declare-own-deps/iiab#L177

I realize that's not 100% perfect for alternative distros and newbies who've never run apt update and don't realize they should.

But I'm not too worried as those running quirky distros usually know a thing or 2 about packaging/updating infra (!) and I don't want to bog down the masses (running mainline distros) with unnecessary delays.

[tabbyrobin]

Just tested this in a fresh vm! Seems to work well, nothing unexpected

(tested in a qubes debian-10-minimal vm, by replacing the url in install.txt with https://raw.githubusercontent.com/holta/iiab-factory/1-line-installer--declare-own-deps/iiab )

[jvonau]

Don't forget to install 'curl' in install.txt if you are truly interested in auto installing dependencies, that would be the better place to install wget that's used to retrieve local_vars.yml before the git clone. Any special reason not to use curl in 'iiab' in place of using wget? One call to install curl, wget, git, nano, etc al and can be installed in one shot, the question is where is the best spot?

[tabbyrobin]

I noticed curl is used in the directions for obtaining install.txt (users are instructed to manually type "curl..." to download install.txt). At that point it seems like a chicken-egg problem... altho of course someone might obtain install.txt some other way, and run it.

Not sure if any of the scripts themselves actually make use of curl? (Whereas, wget is definitely within the scripts.)

I did wonder why both curl and wget were used (curl in the manual download, wget in the scripts). (Maybe because curl has a nicer syntax for piping to bash, and wget has a nicer syntax for storing file locally?)

[holta]

I did wonder why both curl and wget were used (curl in the manual download, wget in the scripts). (Maybe because curl has a nicer syntax for piping to bash, and wget has a nicer syntax for storing file locally?)

Exactly (:

Don't forget to install 'curl' in install.txt

curl is a pre-requisite to download install.txt, and very much on purpose, so no need to install it again. As @sptankard mentioned above there's an inherent bootstrapping issue here (chicken & egg).

One call to install curl, wget, git, nano, etc

Any Delays Whatsoever (in install.txt and in the initial/interactive stages of 'sudo iiab') are a problem with impatient ("time-sensitive") implementers, so that strategy has been avoided.

Hence the title (subject line) of this ticket.

[tabbyrobin]

Looks like there's only 2-4 script invocations of curl. I'm not noticing any invocations in the execution path "before" role 2-common, which will ensure it is installed for later uses such as roles for wordpress, owncloud etc...

https://github.com/search?q=org%3Aiiab+curl&type=code

[tabbyrobin]

(So even if someone downloads install.txt with browser, i think 2-common will install curl early enough that there will be no errors)

[tabbyrobin]

Also, academic note about the incremental installs: if there's ever a re-porting to centOS/fedora etc, dnf/yum download repo metadata more often than debian so incremental installs could take significantly more time (in the long run) than one-shot installs, which might add up, UNLESS the script uses the cli option to use cached metadata.

But i believe on debian, this isn't much of an issue (the extra time of incremental vs one-shot is pretty minimal so it doesnt add up to much.)

[jvonau]

curl is a pre-requisite to download install.txt, and very much on purpose, so no need to install it again. As @sptankard mentioned above there's an inherent bootstrapping issue here (chicken & egg).

So would be wget, grep, nano git,

One call to install curl, wget, git, nano, etc

Any Delays Whatsoever (in install.txt and in the initial/interactive stages of 'sudo iiab') are a problem with impatient ("time-sensitive") implementers, so that strategy has been avoided.

Hence the title (subject line) of this ticket.

The auto installing in the '3 step which check' and the git install can be avoid, in README.html mention these requirements upfront and speed improvements might be gained with sudo apt install curl wget grep nano git prior to curl...install,txt | sudo bash As a side note, could also warn of the auto creation of iiab-admin with a pointer to those docs in README.html.

[holta]

curl is a pre-requisite to download install.txt, and very much on purpose, so no need to install it again. As @sptankard mentioned above there's an inherent bootstrapping issue here (chicken & egg).

So would be wget, grep, nano git,

Different: Chicken & Egg (i.e. bootstrapping) refers to the tool doing the initial download.

The auto installing in the '3 step which check' and the git install can be avoid, in README.html mention these requirements upfront and speed improvements might be gained with sudo apt install curl wget grep nano git prior to curl...install,txt | sudo bash

You're talking about a 2-line installer, which is a fine idea for geeks, but the masses much prefer a 1-line installer.

As a side note, could also warn of the auto creation of iiab-admin with a pointer to those docs in README.html.

Good idea.

[jvonau]

Since the tinkering has begun, might be an opportunity to validate the target's OS as supported before installing any packages?
as in #136 and/or with an addition to 'iiab'? If you need to fail, fail at the earliest possible opportunity.

[holta]

Since the tinkering has begun, might be an opportunity to validate the target's OS as supported before installing any packages?
as in #136 and/or with an addition to 'iiab'? If you need to fail, fail at the earliest possible opportunity.

Makes sense but let's try to avoid duplicate code.

In the case of those who refuse to use the 1-line installer (instead using the ancient/manual IIAB install instructions at https://github.com/iiab/iiab/wiki/IIAB-Installation#do-everything-from-scratch) they too should still probably be warned...when their OS appears to be unsupported / unworkable.

[holta]

For future reference, if OS Support validation moves to the 1-line installer, duplicate code really needs to be avoided in scripts/local_facts.ansible

[jvonau]

For future reference, if OS Support validation moves to the 1-line installer, duplicate code really needs to be avoided in scripts/local_facts.ansible

LMAO, sure break all the top-level ymal files that reference vars/{{ ansible_local.local_facts.os_ver }}.yml, think that would need to stay for now, but you should open a discussion on that before acting as the lone ranger. There is/was open issue for this somewhere, but with the manipulation of the milestones and ignoring of issues I'm not going to bother trying to dig the info up.

The main issue would be the installation of anisble would occur before ever testing if the OS is supported some 15-ish minutes into the install, that determination (go/no go) needs to occur early in the interactive area of the 'iiab' being the first thing the user sees.