-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add CLI subcommands and Bash tab completion #600
Add CLI subcommands and Bash tab completion #600
Conversation
@@ -4,7 +4,7 @@ use crate::modules::block::Block; | |||
use crate::translate::check_all_blocks; | |||
use crate::translate::module::TranslateModule; | |||
use crate::utils::{ParserMetadata, TranslateMetadata}; | |||
use crate::{rules, Cli}; | |||
use crate::rules; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cli
is defined in main.rs
, and would therefore be unavailable to a library crate, if we ever decide to separate the code into binary and library crates; removing references to it will help with that.
src/compiler.rs
Outdated
impl Default for CompilerOptions { | ||
fn default() -> Self { | ||
Self { | ||
no_proc: vec![String::from("*")], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CompilerOptions
is used everywhere AmberCompiler
is used, which is to say almost everywhere. I do not think the --no-proc
and --minify
options make sense outside a cargo check
or cargo build
scenario, so we disable postprocessors for other subcommands. If anyone thinks we need to run postprocessors by default with cargo run
, I can add a command line option for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think it would make sense to add an option for run
for disabling postprocessors, in case there are problems with it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My point is that postprocessors are currently enabled only for check
and build
, not for run
subcommands. Your response implies that they should be enabled by default for run
? (with an option to disable)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't use postprocessors at all. Moreover I think that for debugging purposes they should be disabled so that we can see what's actually being returned by amber compiler. Running them make sense when compiling amber in --release
mode. Wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So right now the postprocessors, are a formatter and a a tool that inject code in the bash script.
I think that makes sense when amber is released that the postprocessor are enabled, but we have a tests if I am not wrong for those.
#[arg(help = "'-' to read from stdin")] | ||
struct Cli { | ||
#[command(subcommand)] | ||
command: Option<CommandKind>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Making command
optional, and duplicating the input
filename and args
array at the Cli
level, allows us to enter either amber run script.ab
or amber script.ab
. The latter is required to run scripts with a shebang line as ./script.ab
.
Does the |
It does:
Of course, this does mean users will have trouble with scripts called |
Thanks @hdwalters. That's great |
Does anyone object if I fix #564 in this PR as well? |
I'm objecting to having P.S. If it isn't, the bash output filename in |
@Ph0enixKM asked that exact same question; see my answer above. The revamped
The output filename is already optional: the compiler creates a new filename by replacing |
To me is fine if this PR fix also #564 |
is it even relevant? i guess its fine as long as it doesn't make a mess out of it. but change the title if you merge this PR with another one so it would be clear what is happening here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm so far, but it seems to be a draft for now (the #564) so i will review it later when its ready
it also conflicts with #595 |
It's relevant because for the first time, we can actually pass command line arguments directly to an Amber script, without compiling to Bash first. And given it's a one line change, I don't want to go through the pain of getting another PR approved! But since nobody has complained about doing it in the first place, I'm just going to push a fix.
It's not a draft, it's a feature proposal I haven't pushed yet.
Good grief. At 83 changed files, it would be hard for it not to conflict. But since I got mine in first, and yours is still a draft, it doesn't seem unreasonable to expect you to fix any merge conflicts! |
42c86de
to
fd8a69c
Compare
i meant that i can't tell my opinion if you haven't decided yet what is going to be changed in the final version |
Ok. It's a moot point anyway, as I backed out the change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was a long one but I got through it. Looking good! 3 small questions though.
I just realized that the |
Another thing I would like to do at some point is refactor the entire codebase to use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
Fixes #411 and #558.
Now specifies functionality via subcommands, with command-specific options:
amber eval
to execute Amber code fragment.amber run
to execute Amber script.amber check
to check Amber script for errors.amber build
to compile Amber script to Bash.amber docs
to generate Amber script documentation.amber comp
to generate Bash completion script.Now passes command line arguments to
main
block in Amber script.