-
Couldn't load subscription status.
- Fork 520
Use NuGet.Configuration to get the path to the NuGet global… #4301
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
Definitely highly in favor of using NuGet'a apis to interface with parts of the system that they directly control. Love to see more of this. |
|
Giving a look at https://github.com/fsprojects/Paket/issues?q=NUGET_PACKAGES and places in the repository that mentions this environment variable maybe a small safety measure, to know how bad changing things would break. I get the feeling NUGET_PACKAGES not being used anymore will break people, and maybe some CI users. But conceptually, using another folder than the one nuget client uses, seems counter-natural, in today's environment. Could we add an entry in release notes, IIUC, that mentions that this environment variable is not used anymore and that it will leverage the ambient nuget environment instead? |
|
Nuget.Configuration reads NUGET_PACKAGES itself - https://github.com/NuGet/NuGet.Client/blob/d525b0e670f3b6cbd5c73a35f04730a9f658c852/src/NuGet.Core/NuGet.Configuration/Utility/SettingsUtility.cs#L231 - it uses that if set and then tries globalPackagesFolder if it isn't |
|
This works for me when doing local builds of FAKE anyway -
|
|
|
||
| let GitRepoCacheFolder = Path.Combine(LocalRootForTempData,".paket","git","db") | ||
|
|
||
| let [<Literal>] GlobalPackagesFolderEnvironmentKey = "NUGET_PACKAGES" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This gets referenced from
| let _ = directPaketInPathExWithEnv "restore" (scenarioTempPath "extracted-package-permissions") [Paket.Constants.GlobalPackagesFolderEnvironmentKey, localNugetDir] |
… packages folder
refs
#3853
#4209
I don't know the history of things in this area, I just hit #3853 when building some things that use paket on a system that has the
globalPackagesFoldersetting set to a custom location (on a different drive than the default user profile directory) and wondered if it would be possible to fix it by using the 'where is the cache folder' functionality inNuGet.Configurationrather than doing it locally (it contains the logic to look forNUGET_PACKAGES, thenglobalPackagesFolder, then the regular defaults)