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

Handling shell arguments with different plugins #1322

Closed
vans163 opened this issue Sep 3, 2016 · 4 comments
Closed

Handling shell arguments with different plugins #1322

vans163 opened this issue Sep 3, 2016 · 4 comments
Labels
question question relative to the project

Comments

@vans163
Copy link
Contributor

vans163 commented Sep 3, 2016

In relation to this. vans163/rebar3_auto#3

Running a plugin like rebar3_auto does not apparently allow to pass shell arguments.

Either you are running 'rebar3 auto', or you are running 'rebar3 shell name "node@localhost"'.

Perhaps add a way to support this, priority is minor.

@ferd
Copy link
Collaborator

ferd commented Sep 3, 2016

You can just take the arguments from your own plugin and re-set them in the State for the next provider coming on. You'll need to declare them as available to your own plugin, but otherwise it should work.

@ferd ferd added the question question relative to the project label Sep 13, 2016
@ferd
Copy link
Collaborator

ferd commented Sep 13, 2016

I believe this answer is all we have right now, no better way to do it without changing things in major ways. Will close this as answered.

@ferd ferd closed this as completed Sep 13, 2016
@vans163
Copy link
Contributor Author

vans163 commented Jan 6, 2024

You can just take the arguments from your own plugin and re-set them in the State for the next provider coming on. You'll need to declare them as available to your own plugin, but otherwise it should work.

Would you have an example available on how to do this?

@ferd
Copy link
Collaborator

ferd commented Jan 8, 2024

Well, that's a 7 years old post, so I don't know that I would say the exact same today. We actually don't set them much in most places, but we do around things like code coverage:

maybe_cover_compile(State) ->
{RawOpts, _} = rebar_state:command_parsed_args(State),
State1 = case proplists:get_value(cover, RawOpts, false) of
true -> rebar_state:set(State, cover_enabled, true);
false -> State
end,
rebar_prv_cover:maybe_cover_compile(State1).

It happens in this case that the coverage handler does not even check command line arguments, but that's how it would work. There's also some stuff in rebar_opts that can handle it: https://github.com/search?q=repo%3Aerlang%2Frebar3+rebar_opts%3Aset&type=code

Most places that handle configuration check both for command-line arguments and for stuff set in rebar.config. So if your command reads it from the command line, it can write it to wherever the other config is handled and that will be the default in the command you call in turn.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question question relative to the project
Projects
None yet
Development

No branches or pull requests

2 participants