Closed auzhva closed 4 years ago
Hi @AlexeyUzhva,
Thank you for your message.
As described here, Go Modules replace
directives are only applied to the root module. If you have replace
directives in a module and tries to add it as a dependency to another one, those statements will be ignored and only the require
statements will be used to discover transient dependencies. To get the expected transient dependencies intended by the module authors, consumers would need to repeat the same replace
statements present in the dependency go.mod
file. We don't believe this is ideal in terms of dependency management.
When we process modules in GoCenter, as part of our validation process, we check if they are ready to be consumed as dependencies. We do that by mimicking the same behavior users are expected to do, which is a regular go get
command fetching the module, and checking for a success. If this validation step fails it means the module is not healthy or requires additional steps to be consumed as a dependency. GoCenter will consider the module to be on a bad state and will not make it available for consumers. All information about the validation process will be available in the UI though.
Let me know your thoughts about it.
Hi @elioengcomp,
Thank you for the explanations. That's quite explanatory.
Ok, it looks like that in real life the issue above is mitigated by operator-sdk itself. This repository represents Kubernetes operators
framework SDK. Which is invented by CoreOS as one of the future ways to deploy applications in k8s. To start a project they recommend to use their custom-command operator-sdk new. It generate replace
directives in root module as part of the generated boilerplate, so for consumers it works like a charm. Here is an example go.mod that it generates. Looks like that here is a source from where It comes.
From above I understand that one of the possible answers is that GoCenter might not care about this pretty custom logic in just one of the repositories. Still k8s is quite a significant part of IT ecosystem in general and go ecosystem in particular. And operators are things that supposed to be written by consumers.
So not sure what is a right way? What would you suggest?
While GoCenter cannot know about those custom bootstrap logic tools maybe it should at least assume they may exist.
I've open #43 to promote the discussion.
Please fell free to give your input there.
@AlexeyUzhva I don't think you can assume that consumers of your package will use your operator-sdk
tool.
@peterbourgon, it's not actually my package. It's a CoreOS package - https://operatorhub.io
I'm just try to use that in my company. We're paid customers of jfrog, but can't use go proxy for this package. That's why the question.
Let me open also a ticker for operator-sdk.
Hi @AlexeyUzhva - We plan to accept modules that use replace
directive. The team will start working on a design proposal that will include the new responsibility of the validator microservice. This activity will start in the next leap (sprint) that begins in two days.
Feel free to also share your opinion from a user's perspective about what modules you don't want GOPROXY to serve.
Thanks for your patience and stay safe!
As a result of the discussion promoted on #43 , GoCenter opinion on module requirements has been removed and operator-framework
can now be downloaded from GoCenter.
See: https://search.gocenter.io/github.com/operator-framework/operator-sdk
This was discussed under #37 but provided answer is not really full.
First: operator-sdk's go.mod is valid. Correct version is specified under
replace
directive.See source: https://github.com/operator-framework/operator-sdk/blob/master/go.mod#L70
So it looks like GoCenter ignores
replace
directive completely and works only withrequire
section.It's common among k8s deployments to use replace to pin to specific version and it would be nice if GoCenter would support it.
Examples on usage under #37 are still valid