search

crystal-lang / shards

Dependency manager for the Crystal language
Other
758 stars 99 forks source link

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

Open luislavena opened 8 months ago

luislavena commented 8 months ago

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 commented 8 months ago

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

luislavena commented 8 months ago

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. ❤️ ❤️ ❤️