-
Notifications
You must be signed in to change notification settings - Fork 905
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
Do not use NuGet package cache #479
Comments
We shut it off completely at one point, but must have missed it during the rewrite when we moved to NuGet.Core. |
Actually it's a bug in NuGet - for some reason it is using the cache repository with the aggregate even though it should not. We don't go down the path that would allow for the cache repository. What we can do is clean up after the installer/upgrader when it does install packages into the cache. |
Something to the effect of: var cachePackage = _fileSystem.combine_paths(Environment.GetEnvironmentVariable("LocalAppData"), "NuGet", "Cache", "{0}.{1}.nupkg".format_with(packageId, version.to_string()));
if (_fileSystem.file_exists(cachePackage)) _fileSystem.delete_file(cachePackage); |
This is now fixed and will go out in 0.9.10. There is a prerelease going out today that will also include this fix. |
Chocolatey doesn't use the NuGet cache at all, but NuGet always caches the package in the NuGet cache (and there is not a way to shut it off with NuGet calls unfortunately). This can cause issues when later using NuGet and trying to install a package from NuGet.org that is different, but carries the same name. The cached file will be served to the user causing hard to detect issues. Therefore we need to clean up after NuGet as there is no way to tell it NOT to cache the nupkg during install/upgrade.
Chocolatey doesn't use the NuGet cache at all, but NuGet always caches the package in the NuGet cache (and there is not a way to shut it off with NuGet calls unfortunately). This can cause issues when later using NuGet and trying to install a package from NuGet.org that is different, but carries the same name. The cached file will be served to the user causing hard to detect issues. Therefore we need to clean up after NuGet as there is no way to tell it NOT to cache the nupkg during install/upgrade.
* ticket/stable/pro-hooks: (25 commits) (GH-584) Build virus check configuration (GH-584) Make empty Get-VirusCheckValid call (GH-583) Mark command methods virtual (specs) Try twice to delete .chocolatey directory (docs) update CHANGELOG / nuspec (GH-535) Tags before summary in nuspec template (GH-479) Remove NuGet cache of package (GH-584) Reinstall should use available package (GH-590) Explicit Cache - No chocolatey subdirectory (GH-584) Set Env Variable for PowerShell Host (maint) formatting (GH-590) Uninstall Cleanup Cache / Delete on Force (GH-585) Force should allow downgrade (GH-584) Hook for loading licensed posh extensions (GH-584) License name - Redact @Domain of email (GH-584) Load licensed version (GH-584) Simple injector load component registries (GH-584) Get version info for other assemblies (GH-584) Assembly adapter enhancements (GH-583) unseal commands ...
* stable: (26 commits) (GH-584) Build virus check configuration (GH-584) Make empty Get-VirusCheckValid call (GH-583) Mark command methods virtual (specs) Try twice to delete .chocolatey directory (docs) update CHANGELOG / nuspec (GH-535) Tags before summary in nuspec template (GH-479) Remove NuGet cache of package (GH-584) Reinstall should use available package (GH-590) Explicit Cache - No chocolatey subdirectory (GH-584) Set Env Variable for PowerShell Host (maint) formatting (GH-590) Uninstall Cleanup Cache / Delete on Force (GH-585) Force should allow downgrade (GH-584) Hook for loading licensed posh extensions (GH-584) License name - Redact @Domain of email (GH-584) Load licensed version (GH-584) Simple injector load component registries (GH-584) Get version info for other assemblies (GH-584) Assembly adapter enhancements (GH-583) unseal commands ...
@ferventcoder Rob have to ask as old as this issue is, that as of latest version 0.10.13, every chocolatey install's package gets stuffed into |
This comment has been minimized.
This comment has been minimized.
@CollinChaffin Let's file a new issue. Chocolatey cleans up the main package that is installed there, however it may not clean up dependencies. I'm not sure I see what you are seeing, so it may be a regression on certain systems. We may go edit nuget-chocolatey not to even store into a local cache (it is annoying). |
chocolatey-archive/chocolatey#714
From @Stift:
I have recently observed that chocolatey uses the same cache as nuget does (c:\users\user1\appdata\local\nuget\cache). Which sounds first like it should not be a problem, they both save files there from different feeds. As there are some packages with the same name, like
nunit
that exist on the chocolatey and on the nuget feed, this leads to some unforeseen behaviour. Depending who comes first, the second one thinks that the package was already downloaded and uses that one. The behaviour afterwards is desastrous and really took me some to figure this out. Therefore I strongly recommend to use some different path for caching the downloaded package files as the feed is also context-wise completely different.The text was updated successfully, but these errors were encountered: