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

Activity

1. Chuck Lantz (Chuxel)

   added

   proposalStill under discussion, collecting feedbackStill under discussion, collecting feedback

   on Jun 30, 2022
2. Chuxel commented on Jun 30, 2022

   

   Chuck Lantz (Chuxel)

   on Jun 30, 2022

   Last edited by Chuxel

   Member

   More actions

   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.
3. andreiborisov commented on Aug 30, 2022

   

   Andrei Borisov (andreiborisov)

   on Aug 30, 2022

   Last edited by andreiborisov

   More actions

   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.
4. Chuxel commented on Aug 30, 2022

   

   Chuck Lantz (Chuxel)

   on Aug 30, 2022

   Member

   More actions

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

   Andrei Borisov (@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}!"
   

   👍React with 👍1Reacted by Andrei Borisov
5. andreiborisov commented on Aug 31, 2022

   

   Andrei Borisov (andreiborisov)

   on Aug 31, 2022

   Last edited by andreiborisov

   More actions

   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.
6. Chuxel commented on Aug 31, 2022

   

   Chuck Lantz (Chuxel)

   on Aug 31, 2022

   Last edited by Chuxel

   Member

   More actions

   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.

   Andrei Borisov (@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. 😄

   ❤️React with ❤️1Reacted by Andrei Borisov
7. eitsupi commented on Aug 31, 2022

   

   eitsupi

   on Aug 31, 2022

   More actions

   Andrei Borisov (@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)
8. andreiborisov commented on Aug 31, 2022

   

   Andrei Borisov (andreiborisov)

   on Aug 31, 2022

   More actions

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

   👍React with 👍1Reacted by eitsupi

   🎉React with 🎉1Reacted by eitsupi