Add yaml config file to image tool command usage

[xiekeyang]

@opencontainers/image-spec-maintainers
Now we are appending more and more flags to image tool commend. For conveniently using, it had better to introduce a yaml config file, like that:

cmd.PersistentFlags().StringVar(&cfgFile, "config", "", "config file (default is $HOME/.cobra.yaml)")

In which user can fulfill his all flags.
If you allow my idea, I'd like to take on it. Thanks a lot!

/cc @philips @stevvooe @s-urbaniak @runcom @wking

[runcom]

I don't like this, I expect the image tool to be just (if possible) a simple tool w/o any state or config saved on disk.

[wking]

On Wed, Sep 07, 2016 at 01:54:58AM -0700, Antonio Murdaca wrote:

I expect the image tool to be just (if possible) a simple tool w/o
any state or config saved on disk.

I agree. What sort of config state were you tired of typing out? ;)

[xiekeyang]

It is OK. I just feel the command line become long to readable, and seen some config file convenient usage via cobra package.

[wking]

On Wed, Sep 07, 2016 at 02:33:58AM -0700, xiekeyang wrote:

It is OK. I just feel the command line become long to readable…

Is that because create-runtime-bundle is really long? Or can you paste
an example of a typical long line that you'd like to abbreviate?

[jonboulle]

would it suffice if you could use environment variables to specify command line options?

[runcom]

would it suffice if you could use environment variables to specify command line options?

is there any tool out there which duplicates command line opts with env variables? I'm not sure... then the "long line" will be the one specifying the env vars (e.g. REFS=a,b,c,d,e,f,... imagine it longer...)

[jonboulle]

What do you mean by "duplicates"? if you're asking about a library that'll map env vars to flags, something like e.g. globalconf, or the simpler package we use for CoreOS projects:
https://github.com/rakyll/globalconf
https://github.com/coreos/pkg/blob/master/flagutil/env.go#L10

[runcom]

What do you mean by "duplicates"?

I mean having an env var for a command line option.

I don't see any gain in having env vars because, as explained early, one can have a really long list of references (for instance) to use with $REFS and thus having still a long line to type paste.

Now we are appending more and more flags to image tool commend. For conveniently using, it had better to introduce a yaml config file, like that:

The op here probably refers to the fact the --ref is a string slice now and one can specify it multiple times (no new flags have been added recently afaict). Having this as env vars seems the same to me (can you make me an example on how it would be different with env vars? even splitting REFS=$refs_list; oci-image-tool validate imagepath has a long line, the first one)

[wking]

On Wed, Sep 07, 2016 at 04:53:10AM -0700, Antonio Murdaca wrote:

I don't see any gain in having env vars because, as explained early,
one can have a really long list of references (for instance) to use
with $REFS and thus having still a long line to type paste.

I think the best solution to this is to remove the the v1.0 default
ref and have the default be “validate all the refs in the bundle”.

If you only want to validate most of the refs, you can always build
REFS incrementally (if you're using Bash or other shell that supports
arrays):

$ REFS=()
$ REFS+=('--refs' 'hi')
$ REFS+=('--refs' 'there')
$ oci-image-tool validate "${REFS[@]}" image.tar

[runcom]

I think the best solution to this is to remove the the v1.0 default
ref and have the default be “validate all the refs in the bundle”.

I'm all for this.

[stevvooe]

Note that there is also https://github.com/spf13/viper, which integrates well with cobra.

Solutions like https://github.com/coreos/pkg/blob/master/flagutil/env.go#L10 are fine, as well, but they do need to be able to handle repeated flags.

In general, I don't quite see the need for introducing a yaml format. What problem are we trying to solve here?

[xiekeyang]

runcom commented 23 hours ago
The op here probably refers to the fact the --ref is a string slice now and one can specify it multiple times (no new flags have been added recently afaict).

I'm not sure except log output and log level set.

wking commented a day ago
would it suffice if you could use environment variables to specify command line options?

stevvooe commented 16 hours ago
Note that there is also https://github.com/spf13/viper, which integrates well with cobra.

Agree, we need way to record and fulfill the flags via env vars. I would take a comparison by coreos and viper.

wking commented 19 hours ago
I think the best solution to this is to remove the the v1.0 default
ref and have the default be “validate all the refs in the bundle”.

Agree.

[runcom]

Agree, we need way to record and fulfill the flags via env vars. I would take a comparison by coreos and viper.

I'm not for this - and not sure at all we need to do this unless there's a specific thing it's solving. So far, no one has provided a valid reason to have env vars in oci-image-tool and just for convenience it's not a valid one at all.

[runcom]

In general, I don't quite see the need for introducing a yaml format. What problem are we trying to solve here?

Please, do reply to what @stevvooe is also asking - why do we need this? I would like to see an example also because I'm not getting what's it's solving (and to me it seems it's not solving the "long list of param" issue, since I'd like to go with @wking's suggestion of validating every ref in an image by default instead)