script requires bash on Alpine

[danmoseley]

On Alpine the default shell is "ash". To run dotnet-install.sh, it is necessary first to install "bash" (at a minimum because it uses bash in its shebang line). Which can easily be done, but has to be figured out. Ideally there would be a way to run this script without bash - although that my require an Alpine-specific script.

cc @mthalman

[danmoseley]

cc @richlander

[bekir-ozturk]

cc @KathleenDollard

[danmoseley]

#!/bin/sh might be a common denominator?

[bekir-ozturk]

@danmoseley Install scripts don't manage dependencies today. Why do you think it should be different for bash?

One reason I can think of is: with any other dependency, we have the ability to print some meaningful message (such as a link to dependencies page).

[danmoseley]

@bozturkMSFT this is a dependency of your own script:
https://github.com/dotnet/install-scripts/blob/main/src/dotnet-install.sh#L1

[bekir-ozturk]

That is true. But my point is:
We want to offer customers a one-liner which they can run and start using .NET. This doesn't work in all the cases today and some users need to install some additional tools regardless of whether the dependency is in the SDK or it is in the scripts. If we can ask them to have "libssl" installed today for instance, why can't we do the same for bash?

I'm not looking for concrete answers, just trying to make sure that I fully understand the situation 🙂

[mthalman]

I think it's important to consider installation dependencies separate from runtime dependencies. IMO, the fact that libssl is needed to run a .NET app is unrelated to the question of how the script itself should handle its own dependency on bash. You should be allowed to run the install script before installing .NET runtime dependencies without a problem.

Also, the eventual goal is to have the script install dependencies (see #2 and Phase 4 of dotnet/core#5651), so the argument of runtime dependencies would become moot at that point.

[danmoseley]

In my mind, there are two kinds of dependencies -- those of the script itself, and those necessary for dotnet to actually run after installed.

For the latter I know the script historically attempted to log when they were missing, and I had earlier opened an issue here that that logging was incomplete/incorrect; you pointed out that it probably wasn't even appropriate for the install script to attempt to keep up to date with the dependencies required by the runtime -- I think that's reasonable -- and you removed the logging.

It seems to me it's a little different when the script itself requires a dependency to work - ideally it has as few dependencies as possible, simply so that it's as easy and as frictionless as possible to use anywhere. Eg., if you can use sh and it will work out of the box everywhere it already does, plus some other distros we support (I do not know this btw), that may be a good thing. Similar to how you attempt to use wget if curl is missing, and give a helpful warning if you can't find either. If 5% of folks attempting to use the script on Alpine give up when bash isn't present, this would allow those folks to be successful.

Thoughts?

[danmoseley]

Oh, crossed posts with Matt..

[KathleenDollard]

@danmoseley The primary use case for Alpine is containers. Wouldn't you generally get the SDK as part of the container?

I'd like to understand the benefit before we consider supporting a new shell. It is hard for us to take them away and Bash and PowerShell are both in very wide usage.

[mthalman]

The primary use case for Alpine is containers. Wouldn't you generally get the SDK as part of the container?

That's the case only if you use a .NET container image. There are cases where it makes more sense to use another technology's container image as the base and then add .NET to it. This is particularly true when you consider how easy it is to install .NET into a container.

[richlander]

@KathleenDollard asked me about this. I think the bash dependency is fine for now, and that we should wait for customer feedback for supporting non-bash scenarios.

[danmoseley]

My only thought is that this script may be the very first .NET touch point for a customer considering it trying it out, and if it fails they may move on rather than engaging to give that feedback. But, I'm fine with what you propose - shall I close then?

[richlander]

We should rely on documentation for now until we hear more from others. Having myself played with the difference between sh and bash, it isn't hard to hit bash only features that are attractive to use. I'd rather not burden the team with supporting multiple shells until we feel need to.

If we decide bash isn't universal enough, we may want to consider other models, like rustup.