deprecated: --build.bin --build.args_bin

[xiantang]

todo:

• [x] https://github.com/air-verse/air/pull/826
• [x] https://github.com/air-verse/air/pull/828
• [x] https://github.com/air-verse/air/pull/829
• [x] update readme to deprecated --build.bin and --build.args_bin

because currently we often use bin to pass args

/home/neo/project/airexample/with space/with space/tmp/main but for example in this case we need complex logic to handle and also with args /home/neo/project/airexample/with space/with space/tmp/main server :8080 so it's hard to maintain

I would like to introduce a new method to express our behavior

which call entrypoint: entrypoint: ["executable","param1","param2"]

for abs bin: /home/neo/project/airexample/with space/with space/tmp/main

[build]
entrypoint: ["./tmp/main"] #should only be file, but root path is `/home/neo/project/airexample/with space/with space`

for abs bin /home/neo/project/airexample/with space/with space/tmp/main server :8080

[build]
entrypoint: ["./tmp/main", "server", ":8080"] # first element should only be file, but root path is `/home/neo/project/airexample/with space/with space`

We will use a entrypoint to check the first element if the file exists, so the new bin cannot go with args,. So we can easily get the bin file path.

I would like to keep the bin behavior for one minor version and introduce entrypoint.

For full_bin, I will also deprecate it, but in the next PR, I will put envs in a new field.

close https://github.com/air-verse/air/issues/546 https://github.com/air-verse/air/issues/773

[xiantang]

And for --build.bin, I will retain this field for a minor version. After that, I will remove this field

[nanvenomous]

During the deprecation phase would be nice to get some kind of a warning in the stdout of air if you still have bin set in config and don't have entrypoint set in config.

Found my way here from the transition from

[build]
  args_bin = []
  bin = "./main serve"

to

[build]
  args_bin = ["serve"]
  bin = "./main"

which broke my app build. took me a bit to find the issue.

[xiantang]

Yes, the current bin setting is very confusing. Users can either input a file path or enter the command with its arguments.

[xiantang]

During the deprecation phase would be nice to get some kind of a warning in the stdout of air if you still have bin set in config and don't have entrypoint set in config.

Found my way here from the transition from

[build] args_bin = [] bin = "./main serve" to

[build] args_bin = ["serve"] bin = "./main" which broke my app build. took me a bit to find the issue.

https://github.com/air-verse/air/pull/828 check out the warnning PR there

[silverwind]

For full_bin, I will also deprecate it, but in the next PR, I will put envs in a new field.

Will running commands like make be supported once full_bin is deprecated? Currently I have:

full_bin = "make run"

And my Makefile has some logic to build and run the executable:

ifeq ($(OS), Windows_NT)
EXECUTABLE := $(NAME).exe
else
EXECUTABLE := $(NAME)
endif

run: $(EXECUTABLE)
	./$(EXECUTABLE) server

[xiantang]

just use entrypoint: ["make", "run"]? @silverwind

[silverwind]

Ah I see, entrypoint also accepts "path-resolved tools", so yeah that will work. It wasn't clear when looking at this, but I see it's documented in README.

[xiantang]

yes let me also update in doc

[silverwind]

If full_bin is changed to an array form, cmd would be last remaining option that takes string form. I wonder if you plan to unify these so all will only take array form? Note that both full_bin and cmd support environment variables.

[xiantang]

If full_bin is changed to an array form, cmd would be last remaining option that takes string form. I wonder if you plan to unify these so all will only take array form? Note that both full_bin and cmd support environment variables.

I think it depends on the request the reason I make bin as an array is because string it very hard to find it executable. And for env I will add a new field to do it. So full bin can be replaced

[silverwind]

Hmm I think ideally pure unparsed shell command passed as a single string to the current shell would be the most flexible, consider this example from one of my apps:

pre_cmd = ["killall -9 $EXECUTABLE 2>/dev/null || true"]
cmd = "MODE=dev make build"
full_bin = "DEBUG=true make run"

Here we have both the definition of environment vars and existing vars being passed. I guess splitting env vars into a separate options would make it less readable.

[xiantang]

Yes, a single string looks nice. I think we can keep cmd and full_bin, but I will remove bin and args_bin when we reach version 2.0.0, as the meaning of bin is unclear.

[xiantang]

The problem is that there are different types of commands in the configuration, which may confuse users.

[xiantang]

Currently, the bin configuration can accept arguments. I believe the correct behavior is that the bin is simply a binary file.

[silverwind]

If I were to redesign this, I would only have two options, a build command and a run command, both accepting either an a array of command strings or a single string:

build_cmd = [
  "killall -9 $EXECUTABLE 2>/dev/null || true",
  "MODE=dev make build",
]
run_cmd = "DEBUG=true make run"