UX bug: Show a difference between zero args and empty args

[schneems]

Summary

I ran into an issue where (due to a buildpack version difference) one buildpack was working and one wasn't. I figured out the problem eventually, but the core issue that made debugging harder than it had to be was that lifecycle currently shows the same output for empty args [] as it does for args that contain no characters [""].

$ pack inspect cutlass_image_basic_bash | grep -B2 web
Processes:
  TYPE                 SHELL        COMMAND        ARGS
  web (default)        bash         while true; do echo 'lol'; sleep 2; done

Note that there's nothing under the "args" section, and it collapses into the command.

Here's my original notes and investigation https://github.com/Malax/libcnb.rs/issues/49

Reproduction

Steps

Make a base buildpack:

cd /tmp
mkdir my_buildpack && cd my_buildpack
mkdir -p bin

cat > buildpack.toml <<EOM

api = "0.4"
[buildpack]
id = "ultra basic invoker"
version = "0.0.0"
name = "ultra basic invoker"

[[licenses]]
type = "MIT"

[[stacks]]
id = "heroku-20"

[metadata]
EOM

cat > bin/detect <<EOM
#!/usr/bin/env bash

exit 0
EOM

Write a build script with non-empty args

cat > bin/build <<EOM
#!/usr/bin/env bash

layers_dir=\$1

cat >> "\${layers_dir}/launch.toml" <<EOL
[[processes]]
type = "web"
command = "while true; do echo 'lol'; sleep 2; done"
args = [""]  # Non-empty args
direct = false
EOL
EOM
chmod +x bin/build
chmod +x bin/detect

Build it:

pack build debug_pack_inspect_launch_args --path . -B heroku/buildpacks:20 --buildpack ./  -v

Produces:

$ pack inspect debug_pack_inspect_launch_args | grep -B2 web
Processes:
  TYPE                 SHELL        COMMAND        ARGS
  web (default)        bash         while true; do echo 'lol'; sleep 2; done

Modify to empty args in the launch:

cat > bin/build <<EOM
#!/usr/bin/env bash

layers_dir=\$1

cat >> "\${layers_dir}/launch.toml" <<EOL
[[processes]]
type = "web"
command = "while true; do echo 'lol'; sleep 2; done"
args = []  # EMPTY args
direct = false
EOL
EOM

Build it:

pack build debug_pack_inspect_launch_args --path . -B heroku/buildpacks:20 --buildpack ./  -v

Produces:

$ pack inspect debug_pack_inspect_launch_args | grep -B2 web
Processes:
  TYPE                 SHELL        COMMAND        ARGS
  web (default)        bash         while true; do echo 'lol'; sleep 2; done

So even though the image produced is not identical, the output of pack inspect is.

Current behavior

Pack inspect does shows identical output when there are no args versus when there are args with no characters.

Expected

I expected the two to produce an observable/inspectable difference in outputs because they are different (one executes, and the other does not).

I propose possibly adding arg count to the output such as:

Processes:
  TYPE                 SHELL        COMMAND                                         ARGS (count = 0)
  web (default)        bash         while true; do echo 'lol'; sleep 2; done        

Or possibly showing non-visible args:

Processes:
  TYPE                 SHELL        COMMAND                                         ARGS (count = 1)
  web (default)        bash         while true; do echo 'lol'; sleep 2; done     ""

---

Context

lifecycle version

Lifecycle:
Version: 0.11.4

platform version(s)

$ pack report
Pack:
  Version:  0.20.0+git-66a4f32.build-2668
  OS/Arch:  darwin/amd64

Default Lifecycle Version:  0.11.3

Supported Platform APIs:  0.3, 0.4, 0.5, 0.6

Config:
(no config file found at /Users/rschneeman/.pack/config.toml)

[natalieparellano]

@schneems thanks for reporting this! I suspect the root issue is in pack, as pack is reading the processes information from the io.buildpacks.build.metadata label and on the app that I tested, I see \"args\":[\"\"] there. I could move it over to the pack repo if there are no objections.

[schneems]

@natalieparellano thank you, if you can move it over that would be amazing!

[edmorley]

Instead of a count of the args (which seems a bit out of place in all but the zero args case), another option might be to show <NONE> or similar in the no-args case.

@schneems Also, I wonder if (as part of another issue) lifecycle should forbid empty string args given they seem to not be able to successfully launch the command, from what you found the other day?

[schneems]

Also, I wonder if (as part of another issue) lifecycle should forbid empty string args given they seem to not be able to successfully launch the command, from what you found the other day?

For my case that would be great. I think there might be another case where someone writes a bash tool that needs an empty arg. If we raised/disallowed an empty arg then also including some kind of escape valve. For example allow_empty_arg: true in the launch.toml

[rizul2108]

I want to work on this issue. @natalieparellano can you please assign this issue to me ?

[jjbustamante]

Hi @rizul2108 thanks for helping us out

[jjbustamante]

@rizul2108 before you try to fix this one, could you try to reproduce it with the latest main branch version? We just merged this PR, that I think it could be related but I didn't check. I do not want you to waste your time

[rizul2108]

Ok sure I will check once

[rizul2108]

yes it is still giving same output

[rizul2108]

so i should start work on fixing this this error? @jjbustamante

[jjbustamante]

Hi @rizul2108 , yes!

I like the idea suggested by Ed here, to use <NONE> with no-args case

[rizul2108]

Okk sure I will work on it

[jjbustamante]

Hi @rizul2108!

Are you still working on this one?

[keshavdalmia10]

Hi @natalieparellano , @jjbustamante i am starting to work in this issue.