Improving the experience of using tools with a runtime install

[richlander]

The following recent issue got me thinking about acquiring tools via the SDK and deploying them to a runtime environment.

https://github.com/dotnet/dotnet-docker/discussions/6090 

I just did the following:

FROM mcr.microsoft.com/dotnet/sdk:9.0 AS sdk

RUN dotnet tool install --global dotnet-runtimeinfo --version 1.0.5


FROM mcr.microsoft.com/dotnet/runtime:9.0

COPY --from=sdk /root/.dotnet/tools/.store/dotnet-runtimeinfo/1.0.5/dotnet-runtimeinfo/1.0.5/tools/netcoreapp3.1/any/ /dotnet-runtimeinfo
ENTRYPOINT ["dotnet", "https://accionvegana.org/accio/0ITbvNmLiVHa0l2Z6MHc0/dotnet-runtimeinfo/dotnet-runtimeinfo.dll"]

Not: It's unlikely you'd do this to run the tool as an ENTRYPOINT. I just did that a proof of concept / validate the test.

This all works, but it's quite ugly. You have to pin the version number in order to be able to predict the path. It's not possible to capture an EXE this way.

I then remembered about --tool-path.

The Dockerfile can be vastly simplified!

FROM mcr.microsoft.com/dotnet/sdk:9.0 AS sdk

RUN dotnet tool install --tool-path /dotnet-runtimeinfo dotnet-runtimeinfo


FROM mcr.microsoft.com/dotnet/runtime:9.0

COPY --from=sdk /dotnet-runtimeinfo/ /dotnet-runtimeinfo
ENTRYPOINT /dotnet-runtimeinfo/dotnet-runtimeinfo

Not so fast.

I then tried another experiment with the resultant --tool-path image.

rich@mazama:~/dtest$ docker run --rm -it --entrypoint bash toolstest
root@29011ca7d434:/# ls /dotnet-runtimeinfo/
dotnet-runtimeinfo
root@29011ca7d434:/# mkdir /test
root@29011ca7d434:/# mv /dotnet-runtimeinfo/dotnet-runtimeinfo /test
root@29011ca7d434:/# ls /test 
dotnet-runtimeinfo
root@29011ca7d434:/# ./test/dotnet-runtimeinfo 
The application to execute does not exist: '/test/.store/dotnet-runtimeinfo/1.0.5/dotnet-runtimeinfo/1.0.5/tools/netcoreapp3.1/any/dotnet-runtimeinfo.dll'.

I did something that seems reasonable on the surface but is very much not. Clearly, that same structure is still there and very difficult to reason about.

root@5f5d3858905d:/# find /dotnet-runtimeinfo/ | wc -l
23

Go and Rust both have somewhat similar experiences that result in binaries that have all the character of normal binaries. I think tools would have much more general utility if they had a mode that supported that.

Ironically, we go to great lengths to build a turnkey system that has great UX, but then we still end up with the following on macOS and Linux.

You can add it to the current session by running the following command:

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

This issue isn't itself a proposal, but documenting that tools satisfy a very narrow use case and were not designed for scenarios that (A) we know that users need, and (B) that match what are platforms offer.