Download and install via tarball instead of NPM

[webwarrior-ws]

The NPM option is still available with the -n/--npm flag.

Fixes #2

[knocte]

And let's rebase.

[knocte]

Let's change one more thing here. In case the -e flag is used, and the -n flag is not used, let's launch a "which npm" process, and if that process fails (because probably npm is not installed), then install awto-pi-lot extension via git instead of npm.

[webwarrior-ws]

Let's change one more thing here. In case the -e flag is used, and the -n flag is not used, let's launch a "which npm" process, and if that process fails (because probably npm is not installed), then install awto-pi-lot extension via git instead of npm.

When trying to test it, it occurred to me that without npm we can't start installation process.

[knocte]

it occurred to me that without npm we can't start installation process.

That's why we're coding this change! so that if someone prefers tarball installation then she doesn't use the -n flag. Did you read it backwards?

[webwarrior-ws]

it occurred to me that without npm we can't start installation process.

That's why we're coding this change! so that if someone prefers tarball installation then she doesn't use the -n flag. Did you read it backwards?

Installation is done by running either npm run or npx. Tarball or not, installation script can't be started without npm.

[knocte]

Installation is done by running either npm run or npx

Oh, you mean the launch of skynot itself, right? Mmm good point

[knocte]

Now that with this type of download we can know what's the progress on it, let's add a progress bar so that we know if it's stuck (this is very useful for me since I have bad connection these days).

[webwarrior-ws]

Now that with this type of download we can know what's the progress on it, let's add a progress bar so that we know if it's stuck (this is very useful for me since I have bad connection these days).

If you run installation with verbose flag, wget output is redirected to stdout, so you'll see the progress.

[knocte]

wget output is redirected to stdout, so you'll see the progress.

Ah ok, acceptable. But then let's only use the verbose flag of wget when skynot is being used with the verbose flag.
And let's use longer flag names on wget!

[knocte]

And let's use longer flag names on wget!

And for tar!

[webwarrior-ws]

wget output is redirected to stdout, so you'll see the progress.

Ah ok, acceptable. But then let's only use the verbose flag of wget when skynot is being used with the verbose flag. And let's use longer flag names on wget!

I don't use any flags on wget. It's the logic of runAsPi function that redirects output of the programs when verbose is true.

[webwarrior-ws]

And let's use longer flag names on wget!

And for tar!

Changed to using long flag names in tar command.

[knocte]

It's the logic of runAsPi function that redirects output of the programs when verbose is true.

What do you mean man? Have you checked what runAsPi() does with the verbose flag? it's just being used for the sudo call; so it doesn't have any effect on wget

[webwarrior-ws]

It's the logic of runAsPi function that redirects output of the programs when verbose is true.

What do you mean man? Have you checked what runAsPi() does with the verbose flag? it's just being used for the sudo call; so it doesn't have any effect on wget

skynot/src/index.ts

Line 95 in 878a182

if (verbose) {

[knocte]

Ok that actually tells me that the way you have done this is wrong. Sudo should only be used for the things that REQUIRE sudo, and downloading with wget does not. Please dismember that big command to only use sudo for the thing that really needs sudo: installing in $installDir.

[webwarrior-ws]

Ok that actually tells me that the way you have done this is wrong. Sudo should only be used for the things that REQUIRE sudo, and downloading with wget does not. Please dismember that big command to only use sudo for the thing that really needs sudo: installing in $installDir.

Split command into 2: one for download, one for unpacking (run as pi user).

[knocte]

Why are you creating a new runCommand func?

[webwarrior-ws]

Why are you creating a new runCommand func?

Because we don't have a function that runs a command? Only the on that runs with sudo.

[knocte]

Because we don't have a function that runs a command?

WRONG! execAsync() is there!!

[webwarrior-ws]

Because we don't have a function that runs a command?

WRONG! execAsync() is there!!

With execAsync() progress bar is not shown.

[knocte]

Then we adjust execAsync, we DONT DUPLICATE IT

[webwarrior-ws]

Then we adjust execAsync, we DONT DUPLICATE IT

execAsync is defined as

const execAsync = promisify(exec);

There is nothing to adjust.

[knocte]

Sigh man I don't understand why you make this so complicated, when it's very simple really.

There's already a way to call processes: exec
There's also a way to call processes with sudo, that receives a verbose flag.

It turns out you need a way to call processes but needing a verbose flag. Then there are 2 obvious options on how to do this here:

1. Figure out how to adjust/wrap exec/execAsync to have a verbose flag like the sudo thing has, and then only use that across everywhere where there is no need for sudo (to not have 3 ways to call processes).
2. Adjust the sudo wrapper to have sudo flag as an option: this way you're reusing the process wrapper without having to DUPLICATE CODE which is what you did!

[webwarrior-ws]

1. Can't adjust exec to redirect output while the command is running.
2. runSudoWithPassword is already complicated. Adding the option to run command without sudo will make it even more complicated. And there's not that much overlap with the new function.