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

Certain CLI options are not passed to shards custom subcommands #600

Open
luislavena opened this issue Oct 7, 2023 · 2 comments · May be fixed by #631
Open

Certain CLI options are not passed to shards custom subcommands #600

luislavena opened this issue Oct 7, 2023 · 2 comments · May be fixed by #631

Comments

@luislavena
Copy link
Contributor

Hello folks,

When creating an external shards subcommand (using shards-xxx executable):

https://github.com/crystal-lang/shards/blob/master/src/cli.cr#L101-L105

Noticed it does not pass to the invoked executable the already processed commands like --production, --without-development, --verbose or --quiet, as these were already parsed by OptionParser.

You can confirm this with the following sample executable script:

#!/usr/bin/env sh

echo "args: $@"

Name it shards-dummy, make it executable and place it in $PATH and when invoked, notice certain options where already processed:

$ shards dummy --production --release --static --verbose
args: --release --static

This differs from the behavior of build or run, which passes all - starting options directly to it. Additionally, the impact of --production or --without-development is not validated (something that is done by build and run by doing a check or install).

Since there hasn't been lot of discussion on this subject, I wanted to check first what is the expected behavior:

  1. Should all the args be passed verbatim to the custom shards subcommand? Including --production or --without-development ?
  2. Should these special shards options be processed first before delegating? (perform a check or install before invoking the subcommand)
  3. Should at least the logging options be passed to the subcommand? Eg. --verbose and --quiet

Last but not least, this also impacts --help, as any custom subcommand cannot provide their own help information as this is short-circuit here, but perhaps that is a separate issue.

I wanted to confirm what are the expectations before proposing a PR with changes.

Thank you in advance for your responses!
❤️ ❤️ ❤️

@straight-shoota
Copy link
Member

I think this behaviour is just an omission and all arguments should be forwarded entirely to the subcommand.

@luislavena
Copy link
Contributor Author

Thank you for the confirmation @straight-shoota, Since there is no specs around that behavior, I'm going to draft something for the integration tests and see if I can make it work.

Once again thank you for your response.
❤️ ❤️ ❤️

@luislavena luislavena linked a pull request May 20, 2024 that will close this issue
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 a pull request may close this issue.

2 participants