[Roadmap Scenarios] User vs. System, default should be user to not require admin rights for the default execution

[KevinMarquette]

Description of the new feature/enhancement

The default execution will not trigger a UAC prompt or require administrator rights (unless the packages themselves request them). To do this, the default install location will be a user specific location. A parameter would be specified to have it install system wide.

This is to provide a better user experience and help promote "least privileges". The general user expects commands to just work and requiring them to use admin rights for default execution mode creates unnecessary friction. Systems administrators that know they want software installed system wide are better equipped to take the additional step of providing a parameter and already have awareness of user vs admin rights related issues.

Here are common pain points I run into when supporting the PowerShell community that commonly has to deal with applications that require users opt out of admin rights for basic functionality.

User instructions should just work

When a user is given instructions or examples to install something using WinGet, they should just work. We should not have to add instructions or disclaimers about running as admin or what parameters to specify to use it as a non-administrator. You should be able to give an instruction like this and it work the first time.

This app can also be installed using WinGet

winget install vscode

Having this error with access denied by default for non administrators and forcing them to go research the issue of something vague like "access denied" during an install process is a poor customer experience. Issues like this tend to generate support calls.

Users don't care where it goes, sys admin do

Most users, especially those that are the sole operator of a system, won't even realize it installed to user locations instead of system wide. Workers that don't have admin access would prefer it installed to a user location so they don't have to talk to someone else to install it. A sys admin would prefer not to be requested to install software that requires elevation when it didn't really need it. This is especially true of applications that want to auto update.

Scrips or tools wrapping WinGet should just work

This also applies to providing install scripts that contain WinGet calls. We don't want sys devs creating tools and scripts that automatically require admin rights. The default execution will be common in those scripts. This is frequently an issue when someone does their scripting work as an administrator and then hand it off to users.

It should not try to detect admin rights to determine install location

This is another trap to avoid so that usage of WinGet is consistent all the time. Having it "randomly" install to one of two locations makes troubleshooting issues more difficult and doubles the scope of testing.

Users should not have to elevate other tools unnecessarily

When working in VSCode and using the integrated environment, working with commands that require elevation can be disruptive. Users start launching VSCode as administrator as a workaround. That's something that should generally be discouraged.

Should be able to use it on CI/CD workers that are not elevated

It is really hard to create build agent workers that do not run elevated because of tools that require elevation unnecessarily. This tool should not add to the problem.

Impossible to change later

Once WinGet is released and has a large user base, this becomes a huge breaking change to correct later. This may be a non-issue for devs, but will be a huge pain point for system administration. This is the main reason I am calling this out now. If you need a good example of a project that got it wrong and is trying to course correct: https://github.com/PowerShell/PowerShellGetv2/issues/236

Saving your sanity when troubleshooting github issues

When your team is responding to support issues, you will almost always have to ask Do you have admin rights on the system you are testing on?. By now you think everyone knows to try that first but you can't know that they have. You will still have to ask that often but you will know its a package issue and not a WinGet issue.

[KevinMarquette]

Related to #271 with a focus on the overall roadmap scenario.

[JoBrad]

I’m not sure if this should really be a different issue, but IMO a crucial part of solving this pretty much requires a common directory for “traditional” (non-Windows store) program executables, for the user. Scoop.sh does this almost perfectly on Windows, in my opinion, but there may be other package managers (like apt/apt-get) that could be used as a model for getting this just right. There is a lot of value in having an official common location for executables at the user level, not least of which would be eliminating the requirement of adding to the PATH variable.

[plastikfan]

With all due respect, I fundamentally disagree with installing by default to the current user only. This is treating a desktop environment like it a mobile device. And I would rather be informed what's its going to do.

To quote your example

winget install vscode

at the moment, I would have no idea what this is. Is this install for all users, or just the current user? I don't want to have to guess. I'm really sorry, but with respect (I love your PowerShell blog!), I strongly disagree with most of your comments.

One of the biggest problems with application/package installation on windows is the issue of install for all users or current user only. In the olden days, you could rely on applications being installed into Program Files and that application would be available to all users no fuss, no messing. Now, this is no longer the case. Some applications will install for all users, some other don't. This has not being standardised. And the windows store does not help in the slightest. Most the the applications installed from the store are for the current user only. When on earth did this become the norm? It's infuriating. If I have multiple accounts on the same machine this becomes a repetitive nightmare. The responsibility of this mess is somewhere between app developers and Microsoft, but mostly the latter, they have the power to impose standards and they should do so. Let's get back to install for ALL USERS by default!

If you want to make install to current user only, then let's have a system setting where we can specify this. I don't want the requirements of most users to trump the way that I want to use my own system, so give us a choice.

[Annihilator]

Currently, winget defaults to (and seems to encourage), the use of per-user installers, and provides no method of selecting at installation time a per-machine installation for software that originally provides that choice. I propose implementing a switch/commandline parameter which would enable the end user to choose whether the installation performed would be per-user or per-machine. Some software offers this choice within their own installer (example: WinSCP), so a commandline parameter for the installer would be appropriate for such cases, and other software has completely separate per-mahine installers available; those would have to point to two different download URLs in the manifest, and select one depending on the choice (example: MS VS Code).

Also, the following logic would possibly be useful:

if running in an elevated command prompt: default to per-machine if running in user context: default to per-user

[KevinMarquette]

I'm advocating for what I feel is the best interest of customer that don't really understand the tools they are using as well as they should. I want the right way to be the easy way, so people fall into the pit of success.

Several of those things are not ideal for me personally, but I'm capable enough to work around them. What I am really asking is that execution of the command performs consistently the same way every time it is executed. I want to see this:

winget install vscode

And just know exactly what it is going to do. You only have to figure it out once. That's why installing to the system should be an intentional flag or non-default config setting. Let the technical users take that extra step.

[plastikfan]

I think you miss the point slightly. As a developer, I don't care about taking extra steps if it means that other users get an easier ride. What I do care about is consistency and knowing what a command is going to do before hand without having to dig into code to find out. And I still disagree about the default install location. Applications/packages should install system wide by default in my opinion. A computer with multiple accounts is not an 'expert' user scenario. If somebody installs an application under one account, why should that application not be available to all and more frustrating, why should this behaviour be different for different applications; that's just a recipe for confusion and frustration. The only way this is going to be satisfactorily resolved is to impose a standard.

[KevinMarquette]

What I do care about is consistency and knowing what a command is going to do before hand without having to dig into code to find out.

This is all I am asking for, 100% consistent execution. We want the same thing, we are just on opposite sides on how to accomplish it. I don't feel that it can be consistent if some users don't have access to the default folder. Either they will not have access or it has to change locations based on elevation.

[denelon]

@KevinMarquette we've implemented settings via winget settings to determine whether a user prefers or requires "user" or "machine". The default is "user". Users may also pass the --scope argument with either "user" or "machine". Does this meet the intent for this Issue?

[KevinMarquette]

Yes, it does. Thank you.

A typical non administrator user will be able to use winget and it will just work the first time. This will provide that correct user experience. Those of us that are more technical will not have any issues adding that parameter to our automation where needed.

[plastikfan]

Cool, I'm happy with that. All I want is consistency and control. If I as developer have to take an extra step then thats fine by me as long as its consistency is maintained, and we all know whats going to happen before we do it. Perhaps if there is WhatIf flag, that would also say what the installation scope is, so we know before we run it.