-
Notifications
You must be signed in to change notification settings - Fork 903
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
feature - usePackageRepositoryOptimizations to control install/upgrade for repositories that don't handle the newer optimizations well - optimizations break LaGet / NuGet Simple Server (PHP) / PHPNuget / Gemfury / Azure DevOps #1770
Comments
The issue seems to be in how packages are requested. 0.10.11 uses
While 0.10.13 does
|
@godofgrunts thanks for logging this. Can I ask what you get when you go to |
I see this in the logs:
@godofgrunts That second part, Is Service Based - True means it should support queries with the filter, otherwise it should continue to use the old method. Once you get me that $metadata output, we can see what the issue is. |
If it doesn't have a |
Sorry for the delay, here is the $metadata from my server. |
In working on #1771, we found a few things. For what you are experiencing, we've added a feature that you can disable so that Chocolatey queries in the old inefficient method it did in 0.10.11 and before. I'd recommend reading over #1397 (which caused this issue) to understand why we went this route in the first place. In the meantime, this is fixed for Chocolatey 0.10.14, where you can simply turn off the feature with It would be good to also let the folks who work on LaGet know they might want to implement fixes that work appropriately with filtering on |
BTW @godofgrunts the metadata looks pretty standard. |
Add a feature turned on by default named `usePackageRepositoryOptimizations` that uses the new methods for querying. Also allow turning off per install/upgrade command with `--disable-repository-optimizations`. When turned off or disabled, Chocolatey will query for available packages for install/upgrade/outdated using the older methods. This allows compatibility with repositories that error or do not support the optimizations.
Thanks for the info. LaGet hasn't been updated in a long time so maybe it's time I find an alternative NuGet server. I appreciate your time and providing a work around. |
Related to #1775 - it appears Simple NuGet Server (PHP) is also affected by these optimizations. |
It's been noted that Gemfury also has issues with the repository optimizations. |
Since this breaks compatibility, maybe you should add something to the metadata on the server end that will tell the client that it accepts the new optimized way of searching so this is seemless for end users. |
@godofgrunts that's not a bad idea - like an opt-in kind of scenario. |
Tried with PHPNuget (last git version/master) and choco 0.10.15, seems working! C:\windows\system32>choco install putty.install --source http://localhost:9999/api/v2/ putty.install v0.71 Installing 64-bit putty.install... Chocolatey installed 1/1 packages. |
Same here (i.e. 0.10.15 works fine now), thanks guys! |
We just updated to 0.10.15 and it's working fine (just to confirm with you). Thank you for the assistance! |
What You Are Seeing?
After upgrading to 0.10.12 and 0.10.13,
choco install [package]
can no longer connect to our local LaGet server. --verbose --trace shows that we are receiving an error 500.What is Expected?
choco install [package]
should connect to our server, download the package, and complete.How Did You Get This To Happen? (Steps to Reproduce)
choco
version 0.10.11.choco
to version 0.10.13Output Log
Please see this gist
I have included the full log, but I have also separated out the verbose logs for the 0.10.13 and 0.10.11 attempts.
NOTE: Added by admin
Caused by #1397 optimizations
Release Notes
In Chocolatey 0.10.14, you should run
choco feature disable -n usePackageRepositoryOptimizations
- this will set Chocolatey back to the older methods it used for package install/upgrade queries. Keep in mind those are horribly inefficient. It would be good to also let the folks who create that repo know they should implement fixes that work appropriately with filtering onPackages()
url.Known Affected Repositories
The text was updated successfully, but these errors were encountered: