Ensure global tools dir is on the PATH

[wli3]

https://github.com/dotnet/cli/issues/9208

After installation of global tools, you need to restart session to let its dir be on PATH. However, in docker image. This should be exported to PATH beforehand. Or the docker user has to restart the session which could lose state.

[peterhuene]

Ping @richlander. It'd be nice to have this for the 2.1 RTM SDK images.

Users will expect that /root/.dotnet/tools to be on PATH if they're playing around with global tools from the SDK images.

[MichaelSimons]

This is not as straight forward as I initially thought. I don't think we want to add ENV PATH="${PATH}:/root/.dotnet/tools" as this will affect all users. Having /root/.dotnet/tools on the path for non-root users seems wrong. We could try to add it to the root user's path only but that won't help scenarios where users are running as non-root. Additionally, user specific paths in general purpose Dockerfiles is not a common practice.

@richlander - What are your thoughts on this?

[peterhuene]

Perhaps we could use /etc/profile.d like we do when you install the SDK via the installer?

It creates /etc/profile.d/dotnet-cli-tools-bin-path.sh with the contents:

export PATH="$PATH:~/.dotnet/tools"

[MichaelSimons]

@peterhuene - yes - good suggestion. I think we can dockerize this by using ENV PATH="${PATH}:~/.dotnet/tools". Thanks

[peterhuene]

Either suggestion should work provided bash is the shell being used 👍 I forgot that bash does expand tilde when searching PATH (zsh does not, which is what I use).

[MichaelSimons]

The native installers support a bash specific solution. A similar bash specific solution could be implemented within the microsoft/dotnet Dockerfiles via ENV PATH="${PATH}:~/.dotnet/tools". A bash specific solution is not ideal within Docker. For example a common use case that would not work is 'docker run --rm <image w/global tool> dotnet-myglobaltool`. Additionally this solution would not work for 'out of the box' with the Alpine based images. While there are other solutions that could be implemented, they would not be natural to Docker. After discussing with @richlander, we both agree that we will not fix this.

The natural usage for global-tools within a Dockerfile would be:

FROM microsoft/dotnet:2.1-sdk

RUN dotnet tool install -g dotnet-serve
ENV PATH="${PATH}:/root/.dotnet/tools"

or

FROM microsoft/dotnet:2.1-sdk
...
USER containeruser
...
RUN dotnet tool install -g dotnet-serve
ENV PATH="${PATH}:/containeruser/.dotnet/tools"

When comparing the existing ENVs set in the SDK images such as ASPNETCORE_URLS vs adding the global tools dir to the path, why wouldn't the global tools dir be added to the path? The principle difference is the interaction with an open-ended external system. ASPNETCORE_URLS is a configuration setting for ASP.NET Core only.

[MichaelSimons]

Reopening as this is something we should be providing a better experience around.