Discussion thread for ' Add proposal for dnup CLI-based acquisition tool'

[baronfel]

Hey folks - PR comments are hard to thread/follow sometimes, so I've made this Discussion to allow for more free-form discussion about the dnup Spec in a way that is hopefully more topic-based. I'll link this from the PR itself.

[baronfel]

This is the official name bikeshedding thread. Do it here and nowhere else 🤣

[Frulfump]

I understand the current name since you want to target rust devs. But honestly this will be used also by already existing .NET Devs so I wouldn't cater to devs of other languages too much given that they will most likely always only represent a minority in usage.

Since we already have a package management system called Nuget, why not use for example dotget as a name?

#339 (comment)

I like the suggestion from @dev-in-disguise, dotget as the name.

[tillig]

My day job is in a pretty highly regulated environment which makes SDK installation and management painful. A couple of things that could ease the pain:

• Continue to allow users to control DOTNET_HOST_PATH, DOTNET_INSTALL_DIR, DOTNET_ROOT. The IT and security departments end up controlling some of these locations to allow/disallow execution. If dnup tries to take control, that won't work. (If the value is unset, dnup maybe can take ownership; but if it's explicitly set already, don't change it - obey it.)
• Allow for a different SDK list/pull location. We have to pull all of our SDKs from an internal location that's been security scanned and cached. Other version manager tools n or nvm (Node) allow you to specify environment overrides (N_NODE_MIRROR, NVM_NODEJS_ORG_MIRROR) for where the list of available SDK versions is pulled and where the SDK itself is downloaded. This isn't currently available in dotnet-install.sh and makes .NET management painful. This sort of support would be huge.
• Don't require admin for anything. In the current proposal, there's a note where the tool would request admin permissions to change a registry key. Have some flag or option to not prompt for that - we'll never get admin to change any of that stuff, so if it breaks without that permission or even really prompts for it, it's going to confuse some of the junior devs. Perhaps that could also be an environment variable like DNUP_REQUEST_ADMIN=false or something. This is a big problem with the current dotnet-uninstall-tool, where even in a custom install location, it requires admin permissions.

And a "nice to have": Something that hooks into global.json, such that if you run dnup install with a global.json in the local folder, dnup will ensure you have a compatible SDK installed. If not, it'll install it. Basically, easier bootstrapping for folks setting up the system on new checkout. (Doesn't have to be dnup install, could be some other command, but the idea is global.json can help drive a check-and-install-if-necessary flow.)

[baronfel]

This is awesome feedback - thank you for taking the time to write it out. We are thinking along these same lines, I can definitely add to the doc to make some of this more clear. We know we need an offline/alternative-source pathway for the releases manifests and 'sources' for the various bits to be installed, and we definitely will support global.json influencing install. That's a huge part of our own workflows on the dotnet-org repos.

We do want to allow a custom install root - it's a really interesting idea to take those from the ambient environment if already set 👍 We'll probably end up with a scheme where there's a more direct, dnup-prefixed variable for this kind of signal, with a fallback/probe of the existing DOTNET_-based variables for compatibility. And point definitely taken about making anything to do with elevation opt-out-able.

[siegfriedpammer]

Having a command line option to specify a path to the global.json to be used would be nice. Relying on the directory structure and specific well-known filenames is a problem in larger projects that use a multitude of different programming languages and build tools.

[tillig]

I did notice that the VS Code ".NET Install extension" is also not using dotnet-install.sh or any shared logic. I filed an issue there about this same thing. It would be nice if the teams working on dnup (or whatever) and other .NET install/acquisition mechanisms could collaborate to ensure there's a single way to configure it and not per-product settings.

[baronfel]

Yep, we're all the same people. The VSCode extension should be able to become a client of dnup, that's exactly the kind of reuse I think I mentioned in the doc.

[tmds]

hi @baronfel, some feedback:

The dotnet download web site and the Learn documentation for getting started with .NET are the primary candidates. However, it is also common to distribute these kinds of bootstrappers via system package managers, so future efforts could include WinGet packages, Debian and Red Hat packages, a Homebrew cask, etc. The tool itself will be a Native AOT tool that is completely standalone, so acquisition should be relatively simple to set up.

As this text says: acquisition for a Native AOT stand-alone can be made simple.

I'm not a fan of including a tool that acquires out-of-band SDKs (i.e. not from package repos) in the package repos.
To the end-user it becomes unclear what get patched by the system.

On first-run, dnup-init will configure the users' environment to support user-local hives. DOTNET_ROOT will be set to point to the dnup user-local root,

I know this is meant to make apphosts find dnup runtimes. It also causes other apps to no longer find system installed .NET runtimes.

I assume dnup will install its own dotnet muxer on a user-location that is in PATH?
Will that muxer also consider SDKs that are at the system location (per /etc/dotnet/install_location?