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

[nkolev92]

@wli3
In the end, NuGet would just be reading a predetermined config file.

We cannot control if the users change these values.

CLI figuring out the path on its own would allow you the most control.

Why do you say it won't help?
It's literally a predetermined place to install these tools.
And you just won't make it configurable.

[nkolev92]

This is on hold right now, due to design changes.

[anangaur]

@nkolev92 shouldn't be required now. right? Are we still deliberating on the location of the extracted tools package payload?

[nkolev92]

@anangaur
As far as I know, we moved it.

Haven't heard any official confirmation though, so I was gonna leave it open.

@wli3 Can we close this now?

[nkolev92]

Redundant now.

[livarcocc]

I am confused. @anangaur you were the asking for tools to be placed next to the user's NuGet package cache, because it allowed you in the future to maybe move this functionality into nuget.exe.

Is this something that you guys are no longer interested at and now we will keep tools under the .dotnet folder?

Also, if this will be under a NuGet folder, we will not hand craft that location, which is why @wli3 asked for an API. I thought we were in agreement on this with @rrelyea.

I am sorry if I am missing something here, I guess I don't have the whole story.

[nkolev92]

I don't think we want the tools functionality in NuGet.exe anymore.

There's also the issue that even our machine-wide config can still be changed, so this tools location could not be enforced permanently.
The root of the drive issue described above, etc.

I'd still wait on @anangaur and @rrelyea to confirm that we're on the same page.

[anangaur]

Just to clarify, we may want this functionality in NuGet in future but we will use the same .dotnet folder that we all decided on. I think we all (including @livarcocc)are on the same page on this now :)