It doesn't need to target .NET 5.0 or 6.0 - it's only Microsoft.Extensions.Logging.Console that I needed to go GA... and we can take a dependency on that while still only keeping to netstandard2.0.

Basically we're not waiting for anything else to be released - we're just waiting for it to be the most important way of spending our limited time.

Version sha256:d31e2c298acb9460c7f770be01d9ae655250b88906d7698202d7506fa06e1b85 was published at 2021-03-05T23:16:51.380Z.

Eventually, we'll want to be able to easily regenerate every version of every module. For now, this adds the ability to regenerate a single module.

:robot: I have created a release *beep* *boop*

2.0.3 (2021-03-08)

Bug Fixes

• deps: update dependency open to v8 (#83) (e8643f6)

This PR was generated with Release Please. See documentation.

Right, yeah that would be .net 5.0, considering 6.0 is already running first previews. Initially you noted wanting to wait for 5.0 to be released before productionizing this. Rephrased my question was more, is this tied to the next (asp).net release, or just when ready. When ready it is :)

I also really like this usage of the EPCL but instead of exposing this through a sample we should consider designing this to be a native integration in the future where the prediction automatically returns the EPCL type. You can print or pprint the predictions directly.

It's really nice that the predict API takes EPCL objects for prediction but this is not something we scoped in for the MB SDK and it would benefit the experience to design out these integration points before exposing them. For instances, you should be able to pass in a list of dictionaries.

Since parameters are unused we don't need to pass them in.

pairs w/ https://github.com/googleapis/gapic-generator-ruby/pull/552

used to generate yaml for docfx

Greetings @ravi-ssi - this is entirely unrelated to this module. If you're having specific issues with auth and the chat API, could I trouble you to open an issue here, with the questions in the issue template? https://github.com/googleapis/google-api-nodejs-client

I can't seem to figure out how to use artman to generate my cloud healthcare java objects. I can't file an issue on that project since there is no issues tab so filing it here.

Not even sure which project has the proto files for google cloud healthcare. Any pointers to the right people would be great!!!

The documentation for the google.cloud.someapi.gapic.enums doesn't currently get generated.

Unfortunately, since many (all?) enum classes are inner classes, Sphinx's automodule directive doesn't seem to support that. Instead, it appears you can use autoclass for each class in the enums file.

Also, I don't see type hints indicating that these enums are used in the docstrings for the proto classes for which they are relevant.

Similar to to googleapis/artman#351, it would be helpful if the googleapis-common-protos-types ruby gem included the proto files in addition to the code generated ruby definitions. As it is currently, compiling proto files using the google.api.http option requires vendoring a copy of the googleapis/googleapis repo into the project.

From a usage perspective I was envisioning being able to do something like the following:

grpc_tools_spec = Gem::Specification.find_by_name('grpc-tools')
googleapis_spec = Gem::Specification.find_by_name('googleapis-common-protos-types')
bin_path = File.join(grpc_tools_spec.bin_dir, 'grpc_tools_ruby_protoc')
exec(bin_path,
  "-I.",
  "-I#{File.join(googleapis_spec.gem_dir, 'proto')}",
  "--ruby_out=lib",
  "--grpc_out=lib",
  *proto_files)

Colorlog is up to 3.1.4 but artman is pinning to 3.0.0. Is this necessary?

error: colorlog 3.1.4 is installed but colorlog<3.0.0,>=2.6.1 is required by {'googleapis-artman'}

Currently, it return 32/64/96 for no clear reason/definition.

Artman uses other tools to generate client libraries. It would be nice if artman could attach the metadata regarding the versions of the tools used (or commit of a GH repo the tool is built upon). This could be in the form of comments in source code or some sort of metadata file in a released package. This metadata would be very helpful when comparing/understanding the diffs of two client libraries of a same API generated at different times. This will also make it straightforward to reproduce a certain artifact at any given time.

Running nox -e lint shows dozens of Python style violations. The linter environment is not being run in travis, allowing these style violations to accumulate. We should fix the existing violations, then enable the linter in ~travis~ Circle.