API to get global tools path

[wli3]

Tools CLI ask

1. Need to be in user directory
   Or at least an option to say “only user directory”. Current all global tool is user level, since we don’t want to require user to run with sudo. While today’s NuGet cache could be user level or machine level.

2. All the “format”
   This is due to weird behavior when using profile.d and paths.d adding to PATH. For mac, if we want to add user directory using paths.d. It has to be in ~/.nuget/ toolsdir format (before tilde expansion). And for Linux using profile.d, it has to be $HOME/.nuget/toolsplace format. The full path will also be used to display message to user. To make such API look nice turned out is hard.

[nkolev92]

Dup of #6253.

Deduping that in favor of this one, so it's easier to track for you.

[nkolev92]

Clarified with Rob, here the ask is actually to just return the GlobalPackageFolder location specified in the "Machine-Wide" config.

I'm not sure any of the points listed in the original issue are a concern.

Will clarify offline if we want to have this as an MSBuild target, or just use the already existing APIs.

[wli3]

We need talk more about this problem. We need an API similar to https://github.com/dotnet/cli/blob/55f62d9d646b558d53c56e226a9ddc3dc003a23b/src/Microsoft.DotNet.Configurer/CliFolderPathCalculator.cs#L44

And as the issue stated, it cannot simply return the full path.

[nkolev92]

@wli3
There's already APIs that allow you to do what you're asking for above and I'm not aware of any issues like the ones you listed under 2.

Can you please try the following

var machineWideSettingsOnly = Configuration.Settings.LoadDefaultSettings(
                    root: null,
                    configFileName: null,
                    machineWideSettings: new XPlatMachineWideSetting());

SettingsUtility.GetGlobalPackagesFolder(machineWideSettingsOnly);

[nkolev92]

How do we handle the scenario where the global packages folder is at the root of a drive? Example F:
The tools folder cannot be at the same level as this.

@anangaur @rrelyea @emgarten @wli3

[wli3]

We do need to think more and decide where to put the logic. In the end, this should not be allowed. Also, I was about to talk about it yesterday, tools folder should be at least per user (ideally it can only be in user's folder) like %userprofile%/.nuget. If tools folder is shared between 2 users like , their tools will be mixed. So if the user want to use D:\sdktool, we should at least end up with D:\sdktool\johnsmith . Or just straight up throws

[wli3]

I am thinking can we not allow this to be set? Or only allow setting the part after user directly.

The validation logic will be very hard. If we move most of this logic to CLI, it won't help too much. CLI will ask for a list of candidate and validate from top to bottom until finding one or throws. However, NuGet will have no idea which one CLI actually picked. And the worst part is, the user changed the config. The candidate list changed, the new location is not deterministic. Also, what to do with existing tools. Should we migrate them after tools location changed