x/pkgsite: package removal request for github.com/google/gnostic/cmd/*

[timburks]

What is the path of the package that you would like to have removed?

github.com/google/gnostic/cmd/disco
github.com/google/gnostic/cmd/parse-linter-output
github.com/google/gnostic/cmd/petstore-builder
github.com/google/gnostic/cmd/protoc-gen-jsonschema
github.com/google/gnostic/cmd/protoc-gen-openapi
github.com/google/gnostic/cmd/report
github.com/google/gnostic/cmd/report-messages
github.com/google/gnostic/cmd/vocabulary-operations

Based on the above, it would be equivalent to remove all packages with this prefix:
github.com/google/gnostic/cmd

Are you the owner of this package?

yes - see https://github.com/google/gnostic

What is the reason that you could not retract this package instead?

These packages were created with new go.mod files that were introduced to explore a multimodule configuration for our project.
After finding problems with our configuration, we decided to revert to a single-module configuration and found that retracting the version of the main repo that introduced the multimodule go.mod files wasn't enough to get these child modules out of the package cache.

https://github.com/google/gnostic/releases/tag/v0.6.0 introduced the multimodule configuration
https://github.com/google/gnostic/releases/tag/v0.6.1 removed the multimodule configuration
https://github.com/google/gnostic/releases/tag/v0.6.2 retracted v0.6.0 but did not seem to retract the child modules.

We may have missed an ability to retract the child modules in our main go.mod - we didn't see that capability documented and didn't try it.

[seankhliao]

note removal here only applies to the documentation site, it doesn't affect the cache

[morphar]

Thanks @seankhliao.
How does the cache work? Will it automatically drop the cache for e.g. github.com/google/gnostic/cmd/protoc-gen-openapi@latestat some point?
Or is there someway to ask for it to drop this as well?

[seankhliao]

No, it's permanent (to not break any existing builds).
retract (in the modules you want to remove) can affect the version selected by go for new dependencies/upgrades.

[morphar]

I see. So for all future calls to github.com/google/gnostic/cmd/protoc-gen-openapi@latest, I will get the broken version (v0.6.0), unless we add a new go.mod in github.com/google/gnostic/cmd/protoc-gen-openapi/. Is that correctly understood?

[seankhliao]

yes,
To prevent the module defined in github.com/google/gnostic/cmd/protoc-gen-openapi/ from being used, you can create a go.mod in that directory with:

module github.com/google/gnostic/cmd/protoc-gen-openapi

go 1.17

// all psuedoversions representing commits and real versions up to the retraction version
retract [v0.0.0-00000000000000-000000000000, v0.6.1]

and tag it with cmd/protoc-gen-openapi/v0.6.1

This doesn't have to be on the main branch, as long as the the highest tagged version of the module has the retraction it will be effective.

[morphar]

Perfect! Thank you so much for your help and advice @seankhliao 👍