Open arifd opened 1 month ago
What you want is
That's right ?
Correct.
To make it even clearer: This is how bacon currently looks for my application:
I've lost what it could look like if I ran this command:
cargo run --bin worker | pretty
A solution, maybe not ideal, could be to write a script, eg run-pretty.sh
with cargo run --bin worker | pretty
, then to define your job as
[jobs.run]
command = [
"sh", "-e", "/path/to/run-pretty.sh"
]
need_stdout = true
allow_warnings = true
background = true
Interesting proposal... Now if i could pass the location of the bacon.toml then i would have a master script that writes the bacon.toml and the run-pretty.sh to /tmp and tell bacon to read it's config from there.
Or maybe if i cd into /tmp, bacon always looks for the bacon.toml in the current working dir?
Why do your bacon.toml need to be dynamic ? Side note: the jobs can also be defined in the global prefs.toml file, and you can give them whatever name you want.
I want to be able to use the bacon interface, I like that it shuffles errors to the top.
But once my application has been built and is running, my application spits out NDJSON logs to stdout, which bacon prints into its interface.
However, I would like to plug in other commands (such as, but not
jq
) which could parse the NDJSON logs, do other things, and have whatever the resultant output be; be fed back into bacon.I'm not sure what the best way to achieve this is. If I were running a bash command I would just
cargo watch -x run --bin my-bin | pretty-print
.I want to be able to express
bacon run -- --bin my-bin | tee -a /tmp/my-bin.log | pretty-print
.But bacon may say this is out of scope and force me to create a separate bin:
my-bin-debug
which calls the pretty printing library, such that bacon still has an opaque application that it just prints into it's interface. I don't mind this approach, but I would rather not have a custom rust bin just to overcome a tooling limitation.What do you think?