Skip to content
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.

Sign up for GitHub

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

Jump to bottom

(#508) Uplift NuGet library #2740

Merged
merged 4 commits into from
Nov 24, 2022
Merged

(#508) Uplift NuGet library #2740

merged 4 commits into from
Nov 24, 2022

Conversation

TheCakeIsNaOH
Copy link
Member

@TheCakeIsNaOH TheCakeIsNaOH commented Jun 16, 2022 •
edited
Loading

Description Of Changes

Uplift Chocolatey CLI from NuGet.Core to using NuGet.Client

Motivation and Context

This allows for features like V3 api support, and SemVer 2.0

Testing

Built and ran tests.

Things to test list

Tests to add:

Known issues

  • Logging from NuGet is at a more verbose level than needed. This can be adjusted either in the NuGet.Client fork, or in the ChocolateyNugetLogger class. What to do should be determined by a review of the messages from libraries once they used classes/methods are more settled on. This can be seen when running choco install and choco search by the network requests information logged to info by NuGet. (#508) Change NuGet normal logging to be verbose logging #2944
  • Pushing packages to CCR does not work (and does not error, where it should work or error). This can be seen by pushing a valid package to CCR with a valid apikey, and having it say that it was ok, but no package was actually uploaded.
  • When push has errors, they are not always caught correctly. I have not always been able to reproduce this, but pushing to nexus with a bad apikey, or where the server is not available are two situations that should trigger it. Once pushing to CCR is working, then testing the error handling if the package already exists would be appropriate.
  • Using a relative local path as a source is not working. When using a dot . as the source like .\choco.exe list -s ., it erors with The path '.' for the selected source could not be resolved.. However, installs do seem to be working? (#508) Attempt to resolve relative paths for sources #2943
  • There are quirks with list/search. Not sure what all is broken. Test matrix should include listing/searching from a local folder, from v2 APIs like CCR and nexus, and from V3 APIs like NuGet.org and Nexus, then should have a search with no search term (so listing all package), listing with a search term, listing with a search term with --exact and/or --all-versions
  • A couple of the list/search command line options are not properly functional. --page, --page-size=, --by-tags-only are all likely broken in some cases. (#508) Fix --page and --page-size arguments #2949 and --by-tags-only is working.
  • Download progress is not available. Previously, the PackageDownloader class was overridden, but the class no longer actually downloads the packages inside it. (#9) Add Download Progress NuGet.Client#12
  • The code to set a source bypass a proxy has not been ported to NuGet.Client, so it won't work. Proxy functionality should be tested first.
  • Search and outdated commands use way more API calls than previously in some cases. Try running search with and without a search term, --exact and --all-versions, then compare to NuGet.Core quantity of calls. It may also be worth looking at install/upgrade when --version is not passed, and for packages that have a large dependency chain.
  • Source priority is not respected. It might just so happen to work, but there is no longer any code that explicitly enforces it.

Features to add?

Moved to comment: #2740 (comment)

Completed

  • Fork NuGet.Client
  • Create a list of commits added to nuget-chocolatey that should be ported/upstreamed/ignored/investigated
  • Investigation of various things relating to the licensed extension. Overriding nuget download service?

Change Types Made

  • Bug fix (non-breaking change)
  • Feature / Enhancement (non-breaking change)
  • Breaking change (fix or feature that could cause existing functionality to change)

Related Issue

Preparing for #508

Change Checklist

  • Requires a change to the documentation
  • Documentation has been updated
  • Tests to cover my changes, have been added
  • All new and existing tests passed.
  • PowerShell v2 compatibility checked.

@TheCakeIsNaOH
Copy link
Member Author

TheCakeIsNaOH commented Jun 16, 2022 •
edited
Loading

Some initial thoughts:

  • Semver stuff is now available in NuGet.Versioning, and appears to be fairly compatible, at least from a compilation point of view.
  • There is a ILogger available in NuGet.Common, against somewhat compatible with the current interface.
  • Metadata, information about packages, and IPackageDownloader are available in NuGet.Packaging
  • IPackage is no longer available, and it is heavily used in the Chocolatey codebase.
  • I'm completely ignoring the unit/integration tests for the moment, some do have NuGet references.
  • There are NuGet references to IPackage and similar across the codebase, but as to calling actual methods, that is mostly limited to stuff in infrastructure.app.nuget, in the NugetService, and in the templates/pins commands (to check for locally installed packages, these probably could be abstracted into something in the NugetService or whatever).

@TheCakeIsNaOH
Copy link
Member Author

TheCakeIsNaOH commented Jun 17, 2022 •
edited
Loading

I went for the low hanging fruit and got push working to my local nexus repository. There are still a number of things that are broken, but it is kinda working:

  • The logging levels need adjustment to be less verbose. I'm not sure if that is adjustment in ChocolateyNugetLogger, something that can be set via a method in NuGet, or something that needs to be changed in the NuGet code.
  • When attempting to push to Nexus with an invalid apikey, it instead asks for username/password, although I can't reproduce it anymore. Either way, it is something to possibly investigate if it pops up: Forbidden status and prompted to enter credentials when attempt to push new package with same ID as an existing one NuGet/Home#3391
  • The user-agent header is being partially set, but it always includes the version of the NuGet library, and there is no way to set that. So, I've set it to do this, Chocolatey Command Line/<version> via NuGet Client/<nuget version>. There is an upstream issue open here: Users using the API should have greater control over the user agent string NuGet/Home#7464
  • Pushing to CCR (via https://push.chocolatey.org) is not working. If it is a valid package and apikey, then nuget logs ok and that the package was pushed, but the package was definitely not pushed. Same thing happens with a pre-existing immutable package version, with both a valid and invalid API key.
  • I suspect that different exceptions would be thrown than with NuGet.Core , so the exception handling will need to be checked, once things are working better.

Other notes:

  • I traced the codepath that nuget.exe uses, and replicated the approiate method calls, at about the same abstraction level as push via NuGet.Core had.
  • Detection of the push being a v2 vs v3 feed seems to happen automatically, and so this should theoretically "just work" for both.
  • Appending of /api/v2/packages to the push source was disabled by noServiceEndpoint, as Chocolatey has push URLs that are specified explicitly.
  • Reminder to self, test "pushing" packages to a unc location. Edit: this is working for me. It does spit out an error about skipping duplicates not being supported, but that can be dealt with later.

@TheCakeIsNaOH TheCakeIsNaOH force-pushed the nuget-v3-devel branch 2 times, most recently from b28dcfe to 5be7b43 Compare June 17, 2022 22:40
@TheCakeIsNaOH
Copy link
Member Author

So, I've got pack working as well. It works with NuGet compatible .nupecs, so using the older schema and not using any of the elements added to nuget-chocolatey.

  • This is one area that has not changed much from older library versions. It just required tweaking a couple of things like switching from implementing an interface to passing a function, but overall, not super difficult. Yay for low-hanging fruit.
  • Since there are not a lot of changes, it is looking like it is still not easy to add additional elements, but on the upside, it looks like it would be reasonably easy to bring forward the commit(s) from nuget-chocolatey to the newer libraries. It is possible everything would be contained within NuGet.Packaging, but it would actually have to be ported to ensure that.
  • File filtering, and .nuspec metadata property replacement are working as far as I can tell
  • It also looks like it would be fairly simple to bring in the command line specification of file exclude filters in from NuGet, the code would be almost copy/paste for the filtering.

@TheCakeIsNaOH TheCakeIsNaOH force-pushed the nuget-v3-devel branch 2 times, most recently from 9846e1d to 2f09265 Compare June 17, 2022 23:16
@TheCakeIsNaOH
Copy link
Member Author

A couple of things I noted today in research:

@TheCakeIsNaOH TheCakeIsNaOH force-pushed the nuget-v3-devel branch 7 times, most recently from 1641023 to 5db4d45 Compare June 24, 2022 16:26
@TheCakeIsNaOH
Copy link
Member Author

In nuget-chocolatey, IPackage inherits from IPackageMetadata (which provides the metadata available in .nupec) and from IServerPackageMetadata (which provides the other metadata not in .nuspec schema but available from v2 API feeds). Therefore,

In NuGet.Client, IPackage has been removed. IPackageMetadata still exists, in almost unchanged form. However, IServerPackageMetadata is not available, with IPackageSearchMetadata taking it's place. IPackageSearchMetadata has all of the metadata from a source, not just the metadata not available in a .nuspec. Therefore, we can't just re-add IPackage, as there would be name conflicts/ambiguity between the two now, for example they both have title.

Instead, I'm thinking of using IPackageMetadata and IPackageSearchMetadata directly, and replacing usages of IPackage with the appropriate one as required. Say for example, with PackageResult, instead of using instance.Package, use instance.PackageMetadata/instance.SearchMetadata (or whatever they are called).

This would require changes in lots of files, but theoretically the changes mostly should just be updating the names of things without too many larger changes. I talked with @gep13 about this, and it seems like a reasonable option to explore.

@TheCakeIsNaOH
Copy link
Member Author

While looking into getting list/search/find working, there are a couple of fun things I discovered:

  • There is no longer a concept of an AggregateRepository that I could find to have a single repository object with multiple sources. Instead, commands like nuget list and nuget search have to keep a list of sources, and iterate through them to initialize the repository, get the resource, get the package(s), and print out the results. This means that Chocolatey will have to take ownership of that, although that is an upside is that version resolution behavior can be adjusted as required without having to dive into nuget code (see Switch aggregate repository package resolution to all feeds for latest instead of just first location found (Vertical) #283 for example).
  • I do not think there is currently a concept of a source priority in the NuGet.Client codebase, at least nothing close to the way Chocolatey does. It will have to be investigated further.
  • There are a number of nice resources to do some search things, like finding all versions of a package (FindPackageByIdResource), or getting information about a specific package (PackageMetadataResource), or searching for a package (PackageSearchResource). Some of these fit very neatly into a specific use (i.e. specific switch combination) of the list/search/find command, but not all uses.
  • There is also a ListResource, for listing all packages on a source, but unfortunately, that is only available for V2 feeds and local packages. There is no direct equivalent for the V3 api at the moment, Package ID service (enumerate all package IDs) for V3 feeds NuGet/NuGetGallery#3878
  • The only reason the nuget list command works for the nuget v3 source is because that source has a link that says "here, go look at the v2 feed to list packages", see this Add a sample for listing package ids from a feed. NuGet/Samples#41 (comment) I discovered this when nuget list refused to list against my local Nexus instance.
  • The NuGet catalog also exists as a suggested alternative to using the v2 search API, but it is only implemented for some repositories (so nuget.org has it, but my Nexus instance does not). Additionally, there is no library in NuGet.Client that I am aware of that will process this, so Chocolatey would either have to fork NuGet.Jobs to use NuGet.Protocol.Catalog from their gallery jobs implementation or download and process the Json manually.
  • On the upside, the catalog is a good candidate for downloading to use as a local package index, since it is an append only log of additions/modifications/deletions of packages on the repository. And since there is no longer an aggregate repository, then package indices could be stored per source without issue and results combined inside the Chocolatey code as needed.
  • Since not all repositories Chocolatey would use would have one of these options to use for a listing of all packages, then a fallback to the PackageSearchResource with an empty search term would be required to list all packages. The fun part of using this is that it would mean that it is pagination time. Joy. Though it could mean getting results out to the screen quicker instead of waiting for everything, and being able to work around Nexus pagination issues if needed.

@TheCakeIsNaOH TheCakeIsNaOH force-pushed the nuget-v3-devel branch 12 times, most recently from 714836c to c11032b Compare July 1, 2022 20:02
@TheCakeIsNaOH
Copy link
Member Author

TheCakeIsNaOH commented Jul 26, 2022 •
edited
Loading

With Chocolatey CLI versions that use NuGet.Core, when upgrading a package that has a "parent" package, it will upgrade the parent package to the lowest version that will work with the dependency package being installed, while with the NuGet SDK, it is the highest version. A "parent" package means a package that depends on the dependency package that is being upgraded.

Here is the integration test example. It has a starting situation of hasdependency 1.0.0 and isdependency 1.0.0 being installed, where hasdependency 1.0.0 depends on isdependency [1.0.0, 2.0.0). Then upgrade is run for hasdependency, with the latest version of 2.1.0, which is not compatible with the installed version of hasdependency. Therefore, hasdependency is upgraded to a version that is compatible with isdependency 2.1.0. The source has multiple versions of hasdependency that are compatible (with isdependency 2.1.0) ranging from version 1.0.1 to 2.1.0.

With NuGet.Core (where PackageManager is set to DependencyVersion.Highest), then it will choose version 1.0.1 of hasdependency, i.e. the lowest compatible version available.
With NuGet SDK package resolver (Set to DependencyVersion.Highest), then it will choose version 2.1.0 of hasdependency, i.e. the highest compatible version available.

This does seem to be a breaking change, as it is behavior that is integration tested for, and the tests do fail when using NuGet SDK. However the NuGet SDK behavior where it installs the highest compatible version seems to be the correct behavior, given that it is set to DependencyVersion.Highest.

I don't think there is a way to tweak this behavior without changing DependencyVersion.Highest to something else, which would break other things. Or of course, changing code in the NuGet.Resolver library, which I am not touching if at all possible.

So, the question becomes, are there any operational cases where this breaking change would be a problem? If so, this needs to be investigated further to see if there is a way to mitigate or it that case. If not, then it should be documented during release, and the tests changed to reflect the new behavior

I'll assume it is the second option for the moment, and modify the tests to assume the highest compatible version of parent package(s) will be installed, instead of the lowest.

@TheCakeIsNaOH
Copy link
Member Author

The NuGet.Versioning library has both a SemanticVersion class and a NuGetVersion class. The SemanticVersion class is a strict semver 2.0 system, while the NuGetVersion class has the support for the fourth revision element in the version. See documentation here: https://docs.microsoft.com/en-us/nuget/concepts/package-versioning#where-nugetversion-diverges-from-semantic-versioning

Therefore, usages of SemanticVersion from NuGet.Core have been switched to use NuGetVersion, and same for any further uses unless there is some reason to use strict semver 2 in a specific area.

Another change from NuGet.Core is that the Constants class has been renamed to NuGetConstants, but some things are now in PackagingConstants. All of the ones that Chocolatey uses (like .nupkg, .nuspec) are still available, so it is simply a matter of a search+replace.

For reading .nupkg files, NuGet.Core had OptimizedZipPackage. The equivalent in NuGet SDK is PackageArchiveReader, which offers similar functionality. It does have to be disposed of though, so using statements need to be added in, but fortunately, this does not translate to huge amounts of indentation changes since most times it is being used in Chocolatey, it is just a line or two of getting the metadata from the .nuspec in the .nupkg

@TheCakeIsNaOH
Copy link
Member Author

TheCakeIsNaOH commented Aug 2, 2022 •
edited
Loading

Proposal for a branching strategy for the NuGet.Client fork:

  • Upstream tracks development in the dev branch as the main branch PRs target. Then for a release a release-A.B.x branch is created (where A.B is the major.minor version like 6.3), and any fixes for A.B are pull into that branch (and/or picked from the dev branch).
  • From what I understand, the intention is for Chocolatey to create custom builds with changes, but that follow upstream fairly closely. So the intent is for the changes to be more of a patch set that is applied on top of the latest code, instead of a major fork that changes lots of things and diverges from upstream.
  • So, assuming we want to use git to add the patch set as commits, instead of having a separate repository of .patch files or something, that leaves two options: merging changes, or rebasing on top of changes.
  • Given that rebasing the patch commits on top of new upstream commits (in the same branch) means rewriting history, that is a no-go for a number of reasons.
  • But merging could work. So base the fork on the dev branch, and then upstream changes get brought in with merge commits. The downside of this is that it makes the history very messy, and it could be hard to get a sense of what the actual patch set on top of upstream is, because there are the patches mixed in on the commit history.
  • So, instead I propose basing the fork on the release-A.B.x branch. Then once upstream creates the release-A.B+1 branch, the required commits can be cherry-picked onto the release-A.B+1 branch (and cleaned up if needed to create a streamlined patch set). If there are any upstream commits on the release- branch, then they can be merged in. This allows for a much shorter history that has to be picked through to separate out upstream work from work on the fork. The downside is that it means that the active development branch of the fork is changing frequently.

To keep the fork up to date, it may be a good idea to utilize a bot to create PRs to merge in changes on the release-* branch from upstream, and to create new release-* branches as they become available.

@TheCakeIsNaOH
Copy link
Member Author

The NuGet PackageResolver class does not have proper documentation, but fortunately, with the method parameter comments and reading through how NuGetPackageManager uses it, it is possible to set up. The Resolve() method takes a PackageResolverContext, and the parameters passed into that are where the real action is in regard to using the resolver.

There is not a distinction between upgrades and installs for the dependency resolver, so more or less the same setup can be used for installs and upgrades.

Here is my explanation of what to pass to the PackageResolverContext to use it with Chocolatey:

  • dependencyBehavior: This is set to DependencyBehavior.Highest, same a used with the NuGet.Core package manager. Given what Chocolatey's intended use case, having everything be the newest version that work for everything is ideal.
  • targetIds: A IEnumerable of strings, with just one entry with the ID of the package being installed.
  • requiredPackageIds: An IEnumerable of strings. This should have the package IDs of all packages locally installed, minus the ID of the package being installed (in the case that it was already installed, and it is being forced or a different version is being installed).
  • packagesConfig: An IEnumerable of PackageReference (a representation of a package ID, version, and allowed framework). Same as above, should include all packages installed locally, minus any versions of the package to be installed.
  • preferredVersions: An IEnumerable of PackageIdentity (a representation of a package ID and version). Same as the two above, should include all packages installed locally, minus any versions of the package to be installed.
  • availablePackages: An IEnumerable of SourcePackageDependencyInfo (A partial set of metadata about a package). This should include the dependency infos of all locally installed packages (again minus any versions of the package that is to be installed), joined with the dependency info of the package version to be installed, and the dependency infos of all available versions all direct and child dependencies of the package version to be installed.
  • packageSources: Pass in the PackageSource from the enabled sources
  • log: Pass in a ILogger like ChocolateyNuGetLogger

These have worked for all situations in the tests, and everything I have played with manually. There could be situations, say for example with multiple versions of packages installed, and complex dependency trees, that it does not work for, but nothing has popped out yet.

As for uninstalls, instead of using PackageResolver, use NuGet.PackageManagement.UninstallResolver.GetPackagesToBeUninstalled.

@TheCakeIsNaOH
Copy link
Member Author

TheCakeIsNaOH commented Aug 3, 2022 •
edited
Loading

Features to possibly add

Investigate adding support for v3 catalog reading/parsing

This would be for the purpose of adding a local index of packages: #820

Some NuGet v3 feeds support the catalog resource: https://docs.microsoft.com/en-us/nuget/api/catalog-resource

It is a append-only resource that records all package additions/changes/unlistings in a json format. So it could be paged through and saved locally, and updated via a new update command to update the index. Then the data can be read locally and parsed as needed.

There are a few samples and projects that use it, but it is not something available through NuGet.Client as far as I am aware, so it would have to be implemented within Chocolatey.

https://github.com/NuGet/NuGet.Jobs/tree/main/src/NuGet.Protocol.Catalog
https://github.com/emgarten/NuGet.CatalogReader
https://github.com/NuGet/Samples/tree/main/CatalogReaderExample

Figure out version ranges, potentially get version range working for --version and/or pin

Feature requests from these two issues: #1278, #800

The NuGet SDK provides a nice class called VersionRange that allows representing a range of allowed versions. It should be possible to be able to use this to parse and represent a version range passed in.

The version range can be saved within the pin file, if the pin file is empty, then it falls back to the previous behavior of pinning the current version.

Then during upgrade, the metadata for all package versions (for the package being upgraded) can be gotten, and filtered to versions allowed in the version range, and then the max of those be used for upgrade.

Add and test validation of package signing

Feature request here: #504

This may already be working, but has not been tested yet. It should be a matter of setting the ClientPolicyContext correctly in the ChocolateyNuGetProjectContext implementation of INuGetProjectContext. Which then gets passed into FolderNuGetProject.InstallPackageAsync which has signature validation, depending on what ClientPolicyContext is set to.

Add in per-source confirmation?

Feature request here: #179

Given the manual package installation routine, it would be possible to toggle confirmation on and off without too much issue for each package.

This may or may not require changes to NuGet.Client, similar to what is required for #1486 to make sure that the source is available inside Chocolatey to check if it require confirmation.

Add in checksum validation of downloaded .nupkgs?

Feature request: #1144

It may be a good idea to investigate adding checksum validation at the same time as validating the .nupkg code signature. Checksums are provided from some repositories, and exposed via IPackageSearchMetadata

Improve the NuGet user-agent?

The user-agent header is being partially set by Chocolatey, but it always includes the version of the NuGet library, and there is no way to currently change that.

So, I've set it to do this, Chocolatey Command Line/<version> via NuGet Client/<nuget version>. This method is fine, but potentially it may want to be changed.

There is an upstream issue open here to allow complete control over the user-agent string: NuGet/Home#7464

Install a (locally available) non-packed/extracted .nupkg?

Feature request #903, may require #624

This should be a case of coping the required files, and then moving right along to the continue action to run the package automation scripts.

Don't save the .nupkg, only keep the .nuspec

Feature request #624

This could be as simple as flipping the current PackageSaveMode.Nupkg | PackageSaveMode.Nuspec | PackageSaveMode.Files to PackageSaveMode.Nuspec | PackageSaveMode.Files in the package extraction context in the ChocolateyNuGetProjectContext implementation of INuGetProjectContext

It would breaks lots of tests, and potentially anything else in Chocolatey that relies on the .nupkg being there, but I think those all could be worked around by just reading the info from the .nuspec directly, and if a list of files is required, reading the .files file for the package. It also should be looked at if any of the list -lo things get broken, but again, that should be reasonable to work around.

Allow dependencies from alternate sources?

Feature request #879

Probably requires changes to the .nuspec schema to add an extra element. Due to the manual installation routine, any dependencies from alternate sources can be removed before passing things to the dependency resolver, then it should be a case of just calling the alternate source for the install of the dependency.

@TheCakeIsNaOH TheCakeIsNaOH mentioned this pull request Aug 4, 2022
Closed
@TheCakeIsNaOH
Copy link
Member Author

TheCakeIsNaOH commented Sep 25, 2022 •
edited
Loading

As side by side is going to be removed, I'm updating this to not include side by side support.
The code with side by side support is backed up in this branch: https://github.com/TheCakeIsNaOH/choco/tree/nuget-v3-sidebyside

And here is the branch with the previous version of the NuGet.Client code: https://github.com/TheCakeIsNaOH/NuGet.Client/tree/sidebyside-backup

@TheCakeIsNaOH TheCakeIsNaOH mentioned this pull request Nov 8, 2022
Closed
@TheCakeIsNaOH
Copy link
Member Author

To be able to rebase this without a huge amount of hassle, I had to squash a bunch of commits, since otherwise changes would not merge smoothly in. As noted in the last comment, the previous version of this branch is still available here: https://github.com/TheCakeIsNaOH/choco/tree/nuget-v3-sidebyside

@choco-bot
Copy link

Task linked: PROJ-311 Take some time to familiarise ourselves with the changes that Josiah has put into PR

@TheCakeIsNaOH @AdmiringWorm
(chocolatey#508) Rip out NuGet.Core
1ee1229 
Remove NuGet.Core dll and project references to it.
@TheCakeIsNaOH TheCakeIsNaOH force-pushed the nuget-v3-devel branch 2 times, most recently from bee58d2 to 6072cb1 Compare November 23, 2022 00:50
AdmiringWorm
AdmiringWorm reviewed Nov 23, 2022
View reviewed changes
Copy link
Member

@AdmiringWorm AdmiringWorm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are just notes for us on the Chocolatey Team. No change is needed, as we will merge this code as is (after a few updates) and continue working on it.

src/chocolatey.tests.integration/scenarios/InstallScenarios.cs Outdated Show resolved Hide resolved
src/chocolatey.tests.integration/scenarios/InstallScenarios.cs Outdated Show resolved Hide resolved
src/chocolatey.tests/TinySpec.cs Outdated Show resolved Hide resolved
TheCakeIsNaOH and others added 3 commits November 23, 2022 17:53
@TheCakeIsNaOH @AdmiringWorm
(chocolatey#508) Uplift To NuGet.Client
8b7f355 
(chocolatey#508) Update using references to new NuGet libraries

(chocolatey#508) Update Constants references for new libraries

update constants

(chocolatey#508) ChocolateyNugetLogger update to nuget logger changes

(chocolatey#508) Update method of getting remote repository

This allows getting the remote repositories and remote resources from the config,
 with authentication and client certificates attached as available.

(chocolatey#508) Get Push working

(chocolatey#508) Get pack compiling

This gets pack working, if the package is using the NuGet compatible schema without
the added Chocolatey specific elements

(chocolatey#508) Switch nupkg reading to PackageArchiveReader

As OptimizedZipPackage is no longer available

Switch to using my forked libraries

Switch package result to use IPackageMetadata/IPackageServerMetadata

Fix Pin, Template and Export commands

Get List working

Misc fixes

Get Outdated, Install, Upgrade and Uninstall compiling

Try initial manual package installation routine

Remove Pending from Install Scenarios and tweak tests

Fixes a couple of tests that have different behavior with newer NuGet
Fixes a couple of tests that were pending, and were not written correctly

Add better exception handling during setup to TinySpec

ChocolateyPackageMetadata handle .nuspecs

Fixes for List

Make sure results are not duplicated, and that ordering is correct

Add Identity to packageresult

ChocolateyPackagePathResolver fix for side by side and use to get install location

temp add debug asset to ensure metadata available

NuGetCommon add more methods and tweak GetPackageDependencies

This adds methods to get the local/installed package repository,
to get dependencies for installed packages,
and fixes GetPackageDependencies to get dependencys with ranges

Switch to PackageMetadataResource to get all package versions

Port over install improvements from parallel install branch

misc cleanups

Switch package service actions to include configuration

Upgrade command work

Switch depender to parent

Add in package page to list verbose output

Work on upgrade/uninstall

Upgrade to nuget 6.4.0.4

Upgrade and Uninstall get passing tests

Upgrade NuGet SDK build

Update path resolver to specify correct manifest name

upgrade nuget library version again

Add tests for side by side nuspec and nupkg file names

This adds tests to ensure that the manifest and package files are correctly named,
that is with the version in the filenames if side by side, and without the version
if not side by side.

Remove now unused nugetpackagemanager related code

Update my added integration tests

Fixes and adds a test to the switch side by side to normal install scenario.

Tweak install package resolution for side by side and add a test

Update messages in some pester tests
@AdmiringWorm
(maint) Remove explicit unit tests
c8abc10
@AdmiringWorm
(maint) Add missing category labels on tests
031aaca
@AdmiringWorm AdmiringWorm marked this pull request as ready for review November 23, 2022 17:03
@AdmiringWorm
Copy link
Member

Failures on GitHub action here is expected, we have not made the NuGet.Client libraries we use public yet.

AdmiringWorm
AdmiringWorm approved these changes Nov 24, 2022
View reviewed changes
Copy link
Member

@AdmiringWorm AdmiringWorm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you for your work on this @TheCakeIsNaOH. We have decided to pull these changes in and continue working on them to fix any outstanding issues in separate pull requests.

@AdmiringWorm AdmiringWorm merged commit 5c65d89 into chocolatey:develop Nov 24, 2022
@TheCakeIsNaOH TheCakeIsNaOH mentioned this pull request Nov 24, 2022
Open
@TheCakeIsNaOH TheCakeIsNaOH changed the title NuGet library uplift testing (#508) Uplift NuGet library Dec 15, 2022
@TheCakeIsNaOH TheCakeIsNaOH deleted the nuget-v3-devel branch December 20, 2022 14:30
@TheCakeIsNaOH TheCakeIsNaOH mentioned this pull request Jan 4, 2023
Closed
This was referenced Jan 26, 2023
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@AdmiringWorm AdmiringWorm AdmiringWorm approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@TheCakeIsNaOH @coveralls @choco-bot @AdmiringWorm