RFE: rename '--init-image' arg to '--image'

[delabassee]

Today we have fn init --init-image fnproject/fn-java-native-init afunc, i.e. a lot of init in a single command!

Renaming --init-image to --image would be more concise. -> fn init --image fnproject/fn-java-native-init afunc

[rdallman]

--image seems ambiguous with the final image that gets output for a function (ie the image the function points to in fn itself). it's true that this is only in the context of init but this is probably not something 99% of users will have intuition about (that init is just init). I agree the flag name is a bit gratuitous in this context, some ideas:

--factory-image --gen-image --boilerplate-image --template-image --tmpl-image

something along those lines? could dig for more synonyms, not trying to be pedantic - I do think that just bare --image is ambiguous to the nominal user and could easily be confusing. thanks for raising this issue

[rikgibson]

Agree with @rdallman that --image would be ambiguous. I don't see a much of an issue here tbh - --boilerplate-image is probably the most meaningful of the suggested alternatives but that's 11 chars as opposed to 4 for init. Non-issue as far as I'm concerned.

[delabassee]

Can't we just shortcut/alias init-image with image as we're doing for example with fn list functions myapp -> fn ls fn myapp ? As for ambiguity and given that init-image is a relatively advanced/niche init use case, can't we assume that those users know what they're doing ?

[shaunsmith]

I'm on the side of brevity when possible. David's point that we provide both verbose and abbreviated keywords in the CLI is well taken so why not also support aliases for options? Most of the tools I use do this. E.g., docker --help (below).

So why don't we come up with a list of single letter aliases for some of the most commonly used options, including --init-image? This is something we should go globally, not just for fn init. Here's my initial proposal:

-a, --annotation
--cmd
-c,  --config
--entrypoint
--force
--idle-timeout
-i, --init-image
--memory
-n, --name
-r, --runtime
--timeout
-t, --trigger
--version
--working-dir

Docker Usage:

Usage:  docker [OPTIONS] COMMAND

A self-sufficient runtime for containers

Options:
      --config string      Location of client config files (default "/Users/shaun/.docker")
  -D, --debug              Enable debug mode
  -H, --host list          Daemon socket(s) to connect to
  -l, --log-level string   Set the logging level ("debug"|"info"|"warn"|"error"|"fatal")
                           (default "info")
      --tls                Use TLS; implied by --tlsverify
      --tlscacert string   Trust certs signed only by this CA (default
                           "/Users/shaun/.docker/ca.pem")
      --tlscert string     Path to TLS certificate file (default "/Users/shaun/.docker/cert.pem")
      --tlskey string      Path to TLS key file (default "/Users/shaun/.docker/key.pem")
      --tlsverify          Use TLS and verify the remote
  -v, --version            Print version information and quit

[rdallman]

As for ambiguity and given that init-image is a relatively advanced/niche init use case, can't we assume that those users know what they're doing ?

yea, that's a good point, most users won't use this flag at all.

overall @shaunsmith like the idea for aliases and agree with your proposal mostly. for deploy and init specifically, i worry about overlap of --image, --init-image and -i, eg fn deploy -i $image (this isn't a valid flag, today, just thinking about use in general) thinking it's going to use a certain init image when the user's intention was to name the final image. maybe, in old school -vvv verbose style, -ii for init image, which is terse and arcane enough, and satisfies the aesthetics of having too much 'init', without conflicting with -i --image? (not trying to be pedantic, really, i swear it...)

[shaunsmith]

In terms of "niche" we've discussed migrating entirely to init images and making fn init --runtime <name> syntactic sugar for invoking a specific image. I actually think this feature is super useful and will get used. The hard coded boilerplate has to go. :)

In term of names, I don't see the conflict. There is no --image in fn deploy. Although fn create function does take an image as a positional argument. Regardless, option names only have to be unique in the context of a given command, not globally unique.

(I'm not trying to be annoying, really, i swear it...)

[rdallman]

I actually think this feature is super useful and will get used.

yea, agree totally - but most runtimes it will just happen magically and most users won't supply --init-image or whatever we end up calling it, eg fn init --runtime python will effectively supply its own init image and users won't be using the flag under discussion here -- that's what i meant, and usually brevity isn't an issue for me, heh

[rdallman]

there may be a valid use case for fn init --image --init-image, just tell me if i'm digging here i'll can it, but a user could want to generate a function and specify a final image for something like scripting or ci (maybe my use case sucks) -- or in general, want to generate the func.yaml with the name of their function image in their func.yaml at init time (say, it contains a registry, and our $PWD function naming scheme isn't enough, so they have to specify it or they otherwise would have to sed replace it in func.yaml in their script at a later instruction since we don't provide --image).

of course, maybe this isn't valid and we should just tell them to write the dang func.yaml themselves, idk.

[shaunsmith]

Right now an init-image only takes one input, function name, but it could take more like final image name. But since all we're doing is generating boilerplate we'd have to stick something like a specified final image name into the generated func.yaml--which we could totally do. We had talked about a general mechanism for passing args into init-image but failed to come up with compelling use cases. My point being that beyond function name, everything else is a template parameter and isn't special.