Allow feature authors to customize the names of the main executables for features.

[edgonmsft]

This proposal is an enhancement idea to the current dev container features proposal.

---

install.app and install.file properties for feature authors to control the name of the main executable of their features, also allows them to add some parameters and to create features in ways different than shell scripts.

(Previously discussed in #27 (review).)

Originally posted by @chrmarti in #48 (review)

[Chuxel]

Just to capture it here - what we discussed in the near term in some DMs is would be to use the filename install rather than install.sh. That way the command could be anything from a shell script to an executable or even a python or node script with the right #! on top.

[andreiborisov]

This would be a brilliant addition. Bash scripts are brittle and hard to maintain in general, so the ability to use something else would be quite useful.

[Chuxel]

@edgonmsft @jkeech @joshspicer @chrmarti We'd talked about also just allowing install as a first step here - did that get implemented or is the ".sh" required?

@andreiborisov One note is you could use a shell script to bootstrap the right executable based on the architecture being built as things are now. e.g. arm64 vs x86. For example, if you use Go and have both an arm64 and amd64 binary.

#!/bin/bash
script_dir="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
arch=$(uname -m)

case $arch in
    x86_64)
        arch=amd64
        ;;
    armv8l | aarch64)
        arch=arm64
        ;;
    *)
        echo "Unsupported architecture: $arch"
        exit 1
        ;;
esac

if [ -e "${script_dir}/you-binary-here-linux-${arch}" ]; then
    "${script_dir}you-binary-here-linux-${arch}" "$@"
    exit $?
fi

echo "Unable to find binary for ${arch}!"

[andreiborisov]

Nice idea!

I want to use fish shell though since it has cleaner and less error-prone syntax than other shells (Go is a bit too involved).

Probably not the best place to ask but:

Is there a chance of including fish shell in the base image so the environment would be available for features? I understand the desire to move everything in the features, but shell is the most basic interface we use to communicate with containers, so including alternative shells in the base image feels right to me.

[Chuxel]

Nice idea!

I want to use fish shell though since it has cleaner and less error-prone syntax than other shells (Go is a bit too involved).

Probably not the best place to ask but:

Is there a chance of including fish shell in the base image so the environment would be available for features? I understand the desire to move everything in the features, but shell is the most basic interface we use to communicate with containers, so including alternative shells in the base image feels right to me.

@andreiborisov We're in the process of migrating the images from vscode-dev-containers over to https://github.com/devcontainers/images so that's a good place to discuss. That said, developers could pick another image (e.g. just straight debian), so a bash script in the feature could look to see if fish is present and add it if not, then use a fish script. That's one of the nice things about the features model since you can more easily have more than one script involved. (As a FYI - installing fish does add about 55-106mb to an image though, so that's something to consider.)

The Alpine common script did something like this with the same script - it initially starts as sh since that's all that is in the base alpine image, installs bash if missing, then uses it - but it was done in a single script which felt a bit hacky. devcontainers/features#67 proposes unifying the distro specifics scripts into one feature with a detect step instead, which is much easier to achieve with more than one script file. 😄

[eitsupi]

@andreiborisov By the way (sorry this is a bit off-topic) are you planning to move the feature fish to your repository as you are asked here microsoft/vscode-dev-containers#1589 (comment)?
(of course I would love to help)

[andreiborisov]

@eitsupi yes, I'm on it, I'm just trying to figure out a way to make it more maintainable (not writing Bash)