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?

[baronfel]

Sorry for the delay getting back to you @tmds.

The SDK team likely wouldn't push for getting dotnetup into system package managers - I mostly mention that because there is prior art in other ecosystems. I agree with you that there is the possibility to confuse users if both 'modes' are enabled. There was some interest from at least one source-build partner in having it in the system packages, and/or pointing it at distro-defined metadatas for SDKs/Runtimes. Such a mode should be possible, but I don't expect to push for that.

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

Also agree with this observation - we will document this, but since dotnetup is intended for local development workflows only, I would expect things like daemons/systemd units to either a) be self-contained, or b) be reconfigured to point to user-local runtimes to continue to work. I also expect that this use case (shared install of daemon) to not be super-prevalent on developer systems. For production workloads I'd expect the distro packages for the runtime/etc to be used.

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?

Absolutely not - we want these to be separate bubbles entirely, this prevents confusion. We expect to have an 'onboarding' capability to install the set of globally-installed SDKs/Runtimes to the local install location so that users have parity when then begin using dotnetup, but the dotnetup-managed hives are intended to only ever talk to themselves.

[tmds]

Absolutely not - we want these to be separate bubbles entirely, this prevents confusion.

I'm not too keen on having a tool that transparently negates the system .NET packages for a user.

I would prefer a design where the system dotnet installation SDKs and runtimes continue to be usable.

If it is additive, I don't think it would be confusing.

The system packages will be kept up-to-date. For dotnetup, the user needs to manage the updates.