-
Notifications
You must be signed in to change notification settings - Fork 521
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
Plug-ins with errors in .app file "not available" #1877
Comments
Yeah that would be a fair change. Initially, the message was added that way because rebar 2.x only allowed a module name as a plugin (and expected it to have been specified in deps). When we supported packages as plugins in the same As such, there is a step where we flat out try to load the module, and just show a little advice saying "plugins is not available" since it was possibly normal to see a bunch of skipped plugins, especially when a bunch of them might have been related to tests or non-dep build tasks. As the ecosystem shifted and that pure rebar 2.x dependencies (that also requited non-critical plugins) became rarer, it would probably make sense to revisit the errors displayed today since they're not as likely to be due for the same reason anymore. |
Thanks for the explanation. It's a minor nitpicking issue, but I found the message misleading and spent some time debugging paths before I realized there was just an error in the |
Line 119 in 4161762
|
It was added for 2 reasons. The second was that, at least for me, I too often had a whole build fail in rebar2 because a plugin that was unrelated to the build failed to be fetched or compile. It was ridiculous to fail compiling because a plugin that wouldn't even be used during compilation failed. So the idea was to try to still build and not let developers who put unnecessary plugins in the main plugin list to be a blocker. It may be the case that now with profiles this isn't as necessary. test plugins and doc plugins go in those profiles. But it isn't prefect since, for example, you can't put a plugin in the So I'm a little skeptical about dropping this but I'm open to it. |
maybe not fail the whole build but just add visibility to the fact that the plugin is broken is sufficient for OP |
That was the purpose of the warning :) |
yeah. Pointing at least to |
I'd be happy if the warning was just "There was a problem loading the plugin XYZ" instead of being misleading. 🙂 I guess the amount of people running broken plugins is smaller than the amount of people wanting errors for them (although I wouldn't mind Rebar erroring out here since I would never personally just add a broken plugin and go about my day. I'd rather have Rebar point that out). |
I'm messing around with plugins and ran into this old issue. I think we were all in agreement so I'll change the warning message. |
Environment
Current behaviour
Describe the current behaviour. In case of a failure, crash, or exception, please include the result of running the command with debug information:
Expected behaviour
An error saying not that the plug-in is "unavailable" but that there was problems running/compiling the plug-in so I know what debug next. E.g. (in red):
The text was updated successfully, but these errors were encountered: