Launcher Arguments

[nebhale]

This RFC proposes a change to the lifecycle execution behavior to allow arguments to be appended to buildpack-contributed process types.

Rendered

[ekcasey]

I really like this idea overall, but I think the big outstanding question here is the UX for direct=false processes. When a direct=false process is launched with a shell, the process arguments are actually arguments to bash -c <cmd> To make this work, each direct=false command would need to explicitly account for the possibility of arguments to take advantage of this feature.

As a simple/contrived example, imagine "hello world" type process.

A directly executed version of this command would look like the following:

[[processes]]
  type = "hello"
  command = "echo"
  args = ["hello"]
  direct = true

If we implemented this RFC and I passed "world" to the launcher the command essentially becomes

[[processes]]
  type = "hello"
  command = "echo"
  args = ["hello", "world"]
  direct = true

what gets executed by the launcher is essentially just echo hello world. Everything works great.

BUT a direct=false hello process could easily look like:

[[processes]]
  type = "hello"
  command = "echo hello"
  direct = false

Passing the same "world" argument to the launcher would result in

[[processes]]
  type = "hello"
  command = "echo hello"
  args = ["world"]
  direct = false

and the launcher would essentially execute bash -c "echo hello" "world". This doesn't work.
The command itself would have to be carefully constructed to accept bash arguments intuitively:

[[processes]]
  type = "hello"
  command = "echo $@"
  args = ["echo", "hello"]
  direct = false

AND even the above doesn't work in practice when read from a config.toml file. After experimenting with every permutation of single and double quoting the only thing i could get to work is toml unicode escape sequences for the $@ so it is evaluated at the correct time...

[[processes]]
type = "hello"
command = "echo \u0024\u0040"
args = ["echo", "hello"]
direct = false
EOF

(This last part is probably to some quoting, toml parsing, nested bash complexity in the launcher implementation, that I don't fully understand, and might independently resolvable. /cnb/lifecycle/launcher 'echo $@' echo hello world works so IDK why it's so hard to recreate the same behavior when reading from config.toml...)

If we fix quoting edge cases this UX might be okay? Folks that want to construct direct=false processes that accept args have a mechanism, but they will need to be careful and I imagine this could trick a lot of people.

[nebhale]

@ekcasey I'd go with something significantly simpler, appending the arguments, space delimited, to the command itself.

[ekcasey]

@nebhale appending space delimited arguments to the command was an idea I was interested in for direct=false process args, even when they are in original process definition and not dynamically supplied (it would resolve the confusion described in buildpacks/lifecycle#281). I know @sclevine had some concerns about that idea however, on which I am sure he will be happy to elaborate.

[hone]

I'm 👍 on this idea as well, but pending resolving the direct=false case.

[sclevine]

I'm strongly opposed to modifying the command automatically. It seems very confusing to provide discreet arguments that don't map to proper argument inputs. Could we just disallow direct = false and non-empty args?

My other concern is that overloading the first argument could lead to unexpected behavior. E.g., if an argument happens to match something on the path, the command would unexpected execute that binary instead.

Could we use environment variables to provide process-type selection and/or shell command overrides instead of trying to fit all of this into a single list?

[natalieparellano]

@ekcasey in the example you provide:

[[processes]]
  type = "hello"
  command = "echo $@"
  args = ["echo", "hello"]
  direct = false

Do you mean to say args = ["hello", "world"]? Just trying to follow along here, want to make sure I'm not missing something.

[sclevine]

Request for prior art: what other tools solve this problem?

[jabrown85]

https://docs.npmjs.com/cli/run-script#description allows arguments via --. Looks like the parsing is described as platform dependent.

[jabrown85]

+1 to this idea. I've been wanting to be able to define npm install task that takes arbitrary arguments for a development mode.

[hone]

I think you meant did here.

Suggested change

	Previously in Cloud Foundry which did not support a system like this, the solution that was chosen was to use an environment variable to represent arguments:
	Previously in Cloud Foundry which did support a system like this, the solution that was chosen was to use an environment variable to represent arguments:

[ekcasey]

Here, "a system like this", refers to one that can accept additional args. CF did not support that. You were forced to use environment variables to change the process.

[jabrown85]

I think we discussed that this PATH change would be restricted to starting the image and stripped from the env of the actual process.

[ekcasey]

yep, I'll update that

[jabrown85]

Are we saying that buildpack authors will have no way of getting the --entrypoint to be launcher if any other buildpack defined a process?

[ekcasey]

We don't want to allow ambiguity in $0 between a process with type launcher and the normal launcher

[nebhale]

Final Comment Period with merge disposition, closing on 26 June, 2020.

[dfreilich]

Simple question, but to make sure I understand:
With this RFC, if I would build an image of pack using pack (e.g. pack build pack -B gcr.io/paketo-buildpacks/builder:tiny -p .), I would be able to use it just by calling

docker run --rm -it pack version

rather than what we currently have to do (docker run --rm -it pack -- pack version)?

[jabrown85]

Simple question, but to make sure I understand:
With this RFC, if I would build an image of pack using pack (e.g. pack build pack -B gcr.io/paketo-buildpacks/builder:tiny -p .), I would be able to use it just by calling

docker run --rm -it pack version

rather than what we currently have to do (docker run --rm -it pack -- pack version)?

Assuming the built image has a pack process type, yes. The pack launcher process would become the entrypoint and the version would be the argument.

[jromero]

@ekcasey / @nebhale can we rename the PR title and the RFC name to reflect that this is talking "image launch flags"