Currently, struct Config that represents a docker configuration file can be populated only with the function
Load(configPath string) (*Config, error)
that expects to have a file available on the disk and read it. Sometimes, this is a redundant step and a security risk when file content is available in memory. Here is a real-world example
Hence, to overcome the aforementioned problems, this PR introduces
LoadFromReader(r io.Reader) and NewFileStoreFromConfig(cfg *config.Config)
that allow passing anything that implements the reader interface in a non-breaking way. The whole existing API and behavior don't change, some additional methods are introduced, like SetPath and Path allowing saving config populated this way. So this change won't break anybody's code.
The root cause of such a workaround that I proposed is that Config is tightly coupled with the idea of getting configuration only directly from a file, thus to extend but not break, we need to make some compromises. I'm open to suggestions for this PR.
Since there are plans for v3 version of this library and work related to registry authentication e.g. https://github.com/oras-project/oras-go/issues/840 I think that the whole API for parsing a config can be changed during this transition in a breaking way. So getting rid of coupling to files on disk should be feasible. If this PR is accepted, I can create a dedicated issue to get it sorted out in the v3.
What this PR does / why we need it:
Currently, struct
Configthat represents a docker configuration file can be populated only with the functionLoad(configPath string) (*Config, error)that expects to have a file available on the disk and read it. Sometimes, this is a redundant step and a security risk when file content is available in memory. Here is a real-world example
Hence, to overcome the aforementioned problems, this PR introduces
LoadFromReader(r io.Reader)andNewFileStoreFromConfig(cfg *config.Config)that allow passing anything that implements the reader interface in a non-breaking way. The whole existing API and behavior don't change, some additional methods are introduced, like
SetPathandPathallowing saving config populated this way. So this change won't break anybody's code.The root cause of such a workaround that I proposed is that
Configis tightly coupled with the idea of getting configuration only directly from a file, thus to extend but not break, we need to make some compromises. I'm open to suggestions for this PR.Since there are plans for
v3version of this library and work related to registry authentication e.g. https://github.com/oras-project/oras-go/issues/840 I think that the whole API for parsing a config can be changed during this transition in a breaking way. So getting rid of coupling to files on disk should be feasible. If this PR is accepted, I can create a dedicated issue to get it sorted out in thev3.