Google.Apis.Games.v1 NuGet package outdated

[NKnusperer]

The NuGet version is outdated, it is v1.9.0.1030 while all other packages are v1.10.0.
This not only makes it unusable with other API packages but also missing Google.Apis.Games.v1.ApplicationsResource.VerifyRequest which I need.
Please update the package.

[chrsmith]

@NKnusperer The NuGet package was published the last time the Games API was able to be built and work correctly with the C# libraries. I'll follow up with the internal team at Google responsible for the API and see what they need to do so that it can work correctly with C# again.

[chrisdunelm]

The reason this doesn't currently build is the enum definition here, in which "played_with" and "playedWith" both map to the same "PlayedWith" name in C#, causing a compile failure.

I've confirmed with the Games team that this enum is never persisted server-side, and is only used as a client-to-server parameter, so we can simply remove the deprecated value from the games_v1.json file. Then this library will build correctly again, and we can release a new version.
We hope to do this in the next week or two.

[mmdriley]

The build machinery downloads the API definitions anew each time. What's your plan to pin a modified version of the games API?

What if the games API changes again later? Would we need to notice and manually unpin and repin?

One option I considered here was a "patch step", where after downloading the API definitions, but before generating code for them, we could apply some targeted patches. In this case, we'd remove one enum element.

[mmdriley]

The patch step could live pretty naturally in get_discovery_documents.py.

One subtle point: the easiest way to cause build problems is to write the same file twice. In cases where we patch the discovery document, we should either do it before writing it out, or write the patched version to a separate file.

If we patch before writing, we should probably write the unmodified version somewhere for comparison. (But we shouldn't bother doing this for unpatched APIs.)

If we write the patch to a new file, we need to change the downstream machinery to consume that file instead of the original. I can imagine MSBuild trickery that would make this work, but it seems unnecessarily complicated.

I'd suggest we go the former route: write the patched JSON to games_v1.json and the original JSON to games_v1.pristine or similar.

If we ever extend this patching to other APIs -- specifically, APIs that are currently building -- we'll need to worry about bumping the revision to ensure that we build and publish new libraries. That's not a concern here since we haven't produces a library for Games.v1 in a while.

When you're testing this, don't forget to remove Games.v1 from the exclusion list in GeneratedLibraries.proj.

[chrisdunelm]

@mmdriley Yes, we're almost certainly going to do a patch step; I haven't yet planned all the exact filenames to use, but may well do it pretty much as you suggest.

[chrisdunelm]

This was fixed in release v1.18.0. Closing.