cread@cread-mac:~$ shellcheck -V
Installing shellcheck 0.7.0
100%|██████████████████████████████████████████████████████████████████████████████████████████████| 1.50M/1.50M [00:00<00:00, 12.7MiB/s]
ShellCheck - shell script analysis tool
version: 0.7.0
license: GNU General Public License, version 3
website: https://www.shellcheck.net
cread@cread-mac:~$ Usage: ozy [OPTIONS] COMMAND [ARGS]...
Try 'ozy --help' for help.

Error: no such option: -B

There is a second or two lag from the exec returning to us getting the ozy usage error, so it's either something with my current shell (GNU bash, version 5.0.18(1)-release (x86_64-apple-darwin19.5.0)), but more likely it's something in the initial install process as subsequent invocations work correctly.

I've noticed a lot of /tmp/_MEIxxxxx files in my /tmp and I think it's because pyinstaller installs there. If ozy fails, or maybe in other situations (we exec a new process, so maybe that?) we get junk left in /tmp.

Quite a strong argument to move away from python and/or pyinstaller.

When installing an app:

Running tarball installer for ccache v.4.8

the version here is 4.8 not .4.8 or v.4.8 - the extra period confuses me at least. ccache 4.8 or ccache version 4.8 or even ccache v4.8 but not v.4.8 make sense to me.

Would be awesome to cover, e.g. ansible and ansible-playbook from the same installation.

Installation output should not just be swallowed up, it should go to stderr. We should see installation progress as it arrives, but only on stderr.

If multiple processes decide to update you can end up with one process blowing away ozy.tmp and redownloading it while the other is execv'ing the new version.

If you get very unlucky this can cause a non-chmodded file to be placed in ~/.ozy/bin/ozy, breaking ozy.

In one use case we have some stuff in an automounter directory. ozy will see its .ozy.yaml as a "directory":

machine:~/d/t/o/env $ pwd
Error: While loading ozy config

Caused by:
    0: Reading config YAML
    1: Is a directory (os error 21)
/home/mgodbolt/dev/project/out/env

Maybe we should ignore .ozy.yaml type things that seem to be bogus as we walk up the directory structure?

1651406 rename("/tmp/install-ozy-1651396/ozy", "/home/matthew/.ozy/bin/ozy") = -1 EXDEV (Invalid cross-device link)

from:

$ env OZY_VERSION=0.1.8 strace -o/tmp/asd -f bash /tmp/fas
Installing ozy pointing at the ozy sample team configuration on GitHub...
Using 0.1.8 as it was set in the environment
Installing ozy v0.1.8 for Linux-x86_64
Error: Cross-device link (os error 18)

For yet-to-be understood reasons, running bazelisk (https://github.com/bazelbuild/bazelisk) under ozy causes subtle, unusual problems. These manifest as things like
bazel-contrib/toolchains_llvm#32 and other issues running other python programs) .
I suspect the PYTHONPATH and other pythonic environment variables set up by the pyinstaller are to blame; we probably need to unset them to prevent downstream issues.

Things like terraform --version get eaten up by ozy. Reported by @cread

If we want to intentionally remove this, that's probably fine, but we should remove it from the example team config if that's the case.

Several installers create subprocesses as part of their installation process. These subprocesses should all

• not inherit their parent's stdin
• redirect stdout to parent's stderr
• inherit parent's stdout
• have the Ozy bin directory on their path

We should explicitly refactor this desired common logic out

otherwise things like:

$ newapp --version > version.file

might end up with version.file containing external installation info (e.g. conda output)

I tried fixing but got as far as:

#!/usr/bin/env bash
# Should be suitable to be `curl | bash`'d

set -euo pipefail

echo Installing ozy pointing at the ozy sample team configuration on GitHub...

OZY_CONFIG_URL=https://raw.githubusercontent.com/aquanauts/ozy/main/conf/sample-team-conf.yaml
OZY_OS=$(uname)
OZY_ARCH=$(uname -p)
#OZY_VERSION=$(curl -sL ${OZY_CONFIG_URL} | grep 'ozy_version:' | awk '{print $2}')
OZY_VERSION=0.1.8

echo Installing ozy v${OZY_VERSION} for ${OZY_OS}-${OZY_ARCH}

TMP_INSTALL_FILE="$(mktemp)"
curl -sL -o "${TMP_INSTALL_FILE}" https://github.com/aquanauts/ozy/releases/download/v${OZY_VERSION}/ozy-${OZY_OS}-${OZY_ARCH}
chmod +x "${TMP_INSTALL_FILE}"
${TMP_INSTALL_FILE} init ${OZY_CONFIG_URL}
rm -f "${TMP_INSTALL_FILE}"

echo
echo '********************************'
echo 'Installed ok. Make sure you follow any instructions above to ensure ozy is on your path.'
echo '********************************'

added the OS and ARCH properly, hacking it to 0.1.8 but still:

Installing ozy pointing at the ozy sample team configuration on GitHub...
Installing ozy v0.1.8 for Linux-x86_64
Error: While loading ozy config

Caused by:
    0: Reading config YAML
    1: No such file or directory (os error 2)

In fact, any attemp to execute the ozy cases this:

bollo:~/d/c/ce-ci (main|✚1) $ /tmp/tmp.CYWrZW95Nt --help
Error: While loading ozy config

Caused by:
    0: Reading config YAML
    1: No such file or directory (os error 2)

New feature: presently the sample team config has entries for sha256, sha256_signature, and sha256_gpg_key. These aren't being checked by the installers, so if a file has been corrupted or tampered with ozy will not know.

Add a feature to verify the sha256.

Specifically, if it gets an EAGAIN error while looking up the config, it should try the request again.

~/.local/bin is defined as part of the systemd file-hierarchy

Any distro that uses systemd (or makes an attempt to be compatible with systemd conventions) will recognize this directory and place it on the users path upon login if it exists.

Note that this path is not guaranteed to exist, so you may need to create it upon first use.
On a similar note, this path will not appear on $PATH if it does not exist, so you may need login-cycle after creating it.

Using ~/.local/bin decreases $PATH bloat, but it also means you may conflict with binaries placed by others.
These potential conflicts already existed in the logical sense that weird and unexpected things may happen depending on order within $PATH, but now they become "that file already existed" issues when placing symlinks.

e.g.

$ app1 | jq -C .

where app1 is controlled by ozy, if app1 has to install and installation generates stdout, then jq is confused and the whole thing goes wrong.

Perhaps we need to redirect all output to stderr during installation? (Happened during a conda package install).

If the tmp path ozy was downloaded to is a different filesystem than the users home directory std::fs::rename fails in rozy

Seems like we'd need a locking mechanism to await, if a new app app is invoked twice, e.g.

$ app &
$ app &  # may race installation with the above