New files not tracked by git (and can we settle on package name?)

[jeffsawatzky]

@timburks with the changes in #344, when I run make on a clean copy of the repo I get some new files that aren't checked in, and the old files with the old package names still stick around.

See attached screenshot, but in short I have a new annotations.pb.go and OpenAPIv3.pb.go files under a new github.com folder, and the older versions of these files are still checked in to the openapiv3 folder as well. This might cause some confusion as to which files protoc-gen-openapi (and other tools) use. If I delete the older files then make no longer works as things are still using the old ones.

I'm not a go expert, and I don't know what the best practices are for package naming and such, but I think some care should be put into thinking about what the package names for these things should be, and ideally solve #337 (the buf.build issue) as well.

I also wonder about the change to OpenAPIv3.proto here. From what I understand that file is autogenerated, so does that mean these changes will be reverted the next time the file is autogenerated? Should the thing that autogenerates this file ALSO be updated to fix the package name?

[jeffsawatzky]

@timburks I put up #349 which I think fixes the issue with running make (or more specifically COMPILE-PROTOS.sh).

However it doesn't address the package naming issue between the package name here and the one for the files on buf.build.

Also, I am still curious about the OpenAPIv3.proto file, and whether the package name will be reverted once this file is regenerated.

[timburks]

Hi @jeffsawatzky, yes, I was expecting that we would need to fix the generator to write the new package paths.

Regarding the path change, in other projects I've moved generated files around to fix problems but would be interested in better ways to handle this.

I'll respond on the buf-related issue about the buf protos - I wanted to set up an isolated (and stable) reference for kubectl (the new github.com/google/gnostic-models) repo, and then start working here to get an updated proto structure that's more consistent with best practices and the draft protos that I put on buf.

[jeffsawatzky]

I think this can be closed as the only outstanding issue is the package path, but I think that is better discussed in #337