-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move remote package to its own module #1845
Comments
Further thinking about this: I wonder if we should just remove the remote code from the core entirely. For example: move it to a repository under https://github.com/go-viper and just import it back for backwards compatibility. I'd very much like to remove these features from the core eventually (ie. provide an interface that doesn't care about remote). |
That would be the best long-term solution …
… but importing the new module for backwards compatibility would negate the dependency benefits.
Ultimately that sounds like a v2 feature 😉. |
I was thinking to still make the remote package a separate module AND move the code out. It might make maintenance harder, so I’m not sure yet. Fortunately, the remote package has no exported types, so we can make that change anytime. |
Ah, right, yes, I think that would work. |
This sounds like a great proposal. Having a slimmer binary is always welcome 😝 . Moving remote package (or providers in general) to a separate repo is not needed tbh ( monorepos work great in Go) This could also be applied to the rest of the providers (file, which could in turn also be an interface that the different types implement, env, flags). Basically the v2 can go ahead and have just a thin but pluggable core and the rest would just be separate packages and users can just import what they need. |
It's not going to make binaries smaller. Go is smart enough not to compile packages that you don't import.
Well, I'm not that positive about monorepos and Go. :) But the idea here is to start removing that chunk of code from the core. The downside is some additional maintenance cost when updating dependencies.
That is the plan, although most of the current implementations will probably stay in the core with the exception of a few encoding libraries. |
Preflight Checklist
Problem Description
Viper has an enormous amount of dependencies (called out a lot in past, particularly in #707).
Most of those dependencies are the result of supporting different remote config providers.
22% of users who responded to the v2 feedback form claimed to use a remote provider, so dumping it completely is not an option:
Proposed Solution
@skitt proposed (alongside with some actual proof that it works) to create a submodule out of the remote package in #707 (comment)
Although technically it's a backward incompatible change, the Go tool is clever enough to notice that an imported package is a separate module, thus able to resolve the situation without users having to do anything.
Alternatives Considered
The alternative is moving the remote package to a completely separate repo (which is probably better for the long term), but it's a hard BC break and we should aim to minimize those in a single major version.
Additional Information
No response
The text was updated successfully, but these errors were encountered: