Skip to content
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

Merged
merged 13 commits into from
Nov 21, 2024

Conversation

hdwalters
Copy link
Contributor

@hdwalters hdwalters commented Nov 16, 2024

Fixes #411 and #558.

Now specifies functionality via subcommands, with command-specific options:

  • Use amber eval to execute Amber code fragment.
  • Use amber run to execute Amber script.
  • Use amber check to check Amber script for errors.
  • Use amber build to compile Amber script to Bash.
  • Use amber docs to generate Amber script documentation.
  • Use amber comp to generate Bash completion script.

Now passes command line arguments to main block in Amber script.

@hdwalters hdwalters requested a review from Ph0enixKM November 16, 2024 17:52
@@ -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;
Copy link
Contributor Author

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("*")],
Copy link
Contributor Author

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.

Copy link
Member

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

Copy link
Contributor Author

@hdwalters hdwalters Nov 20, 2024

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)

Copy link
Member

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?

Copy link
Member

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>,
Copy link
Contributor Author

@hdwalters hdwalters Nov 16, 2024

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.

src/main.rs Show resolved Hide resolved
@Ph0enixKM
Copy link
Member

Does the amber main.ab run the amber script too for shebang compatibility?

@hdwalters
Copy link
Contributor Author

hdwalters commented Nov 17, 2024

Does the amber main.ab run the amber script too for shebang compatibility?

It does:

hwalters@Ghostwheel ~/git/amber-lang (improve-command-line-interface) 
$ ./echo.ab 
Hello world
hwalters@Ghostwheel ~/git/amber-lang (improve-command-line-interface) 
$ amber echo.ab 
Hello world
hwalters@Ghostwheel ~/git/amber-lang (improve-command-line-interface) 
$ amber run echo.ab 
Hello world

Of course, this does mean users will have trouble with scripts called run, build etc. I think we can live with this.

@hdwalters hdwalters requested a review from b1ek November 17, 2024 09:16
@Ph0enixKM
Copy link
Member

Thanks @hdwalters. That's great

@hdwalters
Copy link
Contributor Author

hdwalters commented Nov 17, 2024

Does anyone object if I fix #564 in this PR as well?

@mks-h
Copy link
Member

mks-h commented Nov 18, 2024

I'm objecting to having amber run instead of the simple amber [path-to-file.ab] — that's going to make the shebang weird (#!/bin/amber run), and generally it would be less comfortable to use. Otherwise I don't see any problems.

P.S. If it isn't, the bash output filename in amber build should be optional, and by default be the same as of the Amber script, but having .sh ending.

@hdwalters hdwalters requested a review from mks-h November 18, 2024 07:43
@hdwalters
Copy link
Contributor Author

hdwalters commented Nov 18, 2024

I'm objecting to having amber run instead of the simple amber [path-to-file.ab] — that's going to make the shebang weird (#!/bin/amber run), and generally it would be less comfortable to use. Otherwise I don't see any problems.

@Ph0enixKM asked that exact same question; see my answer above. The revamped Cli struct has an input filename and command line arguments at both the top level and in the run subcommand, so either syntax works.

P.S. If it isn't, the bash output filename in amber build should be optional, and by default be the same as of the Amber script, but having .sh ending.

The output filename is already optional: the compiler creates a new filename by replacing .ab with .sh if not provided.

@Mte90
Copy link
Member

Mte90 commented Nov 18, 2024

To me is fine if this PR fix also #564

@b1ek
Copy link
Member

b1ek commented Nov 19, 2024

Does anyone object if I fix #564 in this PR as well?

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

Copy link
Member

@b1ek b1ek left a 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

@b1ek
Copy link
Member

b1ek commented Nov 19, 2024

it also conflicts with #595

@hdwalters
Copy link
Contributor Author

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

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.

lgtm so far, but it seems to be a draft for now (the #564) so i will review it later when its ready

It's not a draft, it's a feature proposal I haven't pushed yet.

it also conflicts with #595

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!

@hdwalters hdwalters changed the title Improve command line interface Implement subcommands, Bash tab completion, do not pass "$0" to main block Nov 19, 2024
@hdwalters hdwalters changed the title Implement subcommands, Bash tab completion, do not pass "$0" to main block Add subcommands, Bash tab completion, do not pass "$0" to main block Nov 19, 2024
src/modules/main.rs Outdated Show resolved Hide resolved
@hdwalters hdwalters force-pushed the improve-command-line-interface branch from 42c86de to fd8a69c Compare November 19, 2024 08:19
@hdwalters hdwalters changed the title Add subcommands, Bash tab completion, do not pass "$0" to main block Add CLI subcommands and Bash tab completion Nov 19, 2024
@b1ek
Copy link
Member

b1ek commented Nov 19, 2024

It's not a draft, it's a feature proposal I haven't pushed yet.

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

@hdwalters
Copy link
Contributor Author

Ok. It's a moot point anyway, as I backed out the change.

Copy link
Member

@Ph0enixKM Ph0enixKM left a 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.

src/utils/metadata/parser.rs Show resolved Hide resolved
src/modules/function/declaration.rs Outdated Show resolved Hide resolved
src/main.rs Outdated Show resolved Hide resolved
@Ph0enixKM
Copy link
Member

Ph0enixKM commented Nov 20, 2024

I just realized that the document module operates on files but it's a part of the compiler module. The file management part should be extracted to the main.rs. But that's not for the scope of this issue.

@hdwalters hdwalters requested a review from Ph0enixKM November 20, 2024 20:10
@hdwalters
Copy link
Contributor Author

I just realized that the document module operates on files but it's a part of the compiler module. The file management part should be extracted to the main.rs. But that's not for the scope of this issue.

Another thing I would like to do at some point is refactor the entire codebase to use PathBuf and &Path for file system paths, instead of String and &str. I made the new CLI use the path specific structs at that level, but I had to convert to strings to pass into the compiler, to avoid feature creep.

Copy link
Member

@Ph0enixKM Ph0enixKM left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good

@Ph0enixKM Ph0enixKM requested a review from b1ek November 21, 2024 08:32
@hdwalters hdwalters merged commit e5467d2 into amber-lang:master Nov 21, 2024
1 check passed
@hdwalters hdwalters deleted the improve-command-line-interface branch November 21, 2024 17:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature] Pass further arguments to program with "--"
5 participants