-
Notifications
You must be signed in to change notification settings - Fork 515
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
give top level plugin providers precedence over default providers #1065
Conversation
I have a tentative +1. I'd like to keep maybe 1 day or 2 before merging it just to think of ways this could be bad or good. I guess we can't have tests for that either, right? |
What's the order of things if two top-level plugins try to take over the same command? |
:( I wanted to write my cuttlefish blog post today. Order is the order they are defined in rebar.config |
Don't we usually use name order for conflict resolution? Would it make sense to use that here instead so we always pick the same rules? Also would that still be necessary with the relx hooks I saw in another PR? |
I'd say no, since it is entirely up to the single rebar.config entry, so in the case like this that you can see all that can have an effect in one place i think using the order defined makes sense. |
is the override only for the root app's context, or will redefining compile redefine it for all deps? |
For all deps. There isn't a concept of providers per deps, the compile provider is the one that knows about deps, no the other way around. |
so if i have an app that depends on a custom compile provider, it's unuseable as a dep if that compile provider doesn't also work with all my deps and the root project? |
@talentdeficit yes, providers are not called for apps, they are run on the project. Only hooks may be run per-app/dep. So even if you could override |
Well it does have the interesting side effect that it breaks composability then, no? What works in an app should work when that app is a dep, and this is no longer true? |
Yea, that would be the case for for hooks. Someone could have a plugin that overrides some default provider and uses it as a hook and that hook would not use the plugin provider when run as a dep :( Why must people break things! |
would it be possible to ignore deps plugins when it comes to downloading, but use them if the root project includes the plugins just in the context of deps that declare use of that plugin? that way plugins in deps can't break other deps or your project, but a dep that depends on a plugin is still useable if you include the plugin in your project |
I'm not sure what you are saying. |
if a dep declares a plugin and the plugin is declared in the project rebar.config, use the plugin, otherwise fall back to the built in providers (or error or skip as appropriate if it's a plugin that doesn't attempt to change providers) |
9afcddd
to
53866e1
Compare
Ok, new idea. The issue has been that we can't differentiate a project that is an umbrella/release and one that is an app. The former can never be a dependency. So in this patch I add the option |
This can also be used by any plugin a user wants to have available when developing on their app but isn't needed when being used as a dependency. I may use this for neotoma plugin... Since for that I just build the |
i like the idea of differentiating between a project and an app |
Yeah +1 on that idea. Makes a distinction between necessary and optional plugins. |
so is this good to merge now then? |
Yeah. We'll need to update docs about that too. |
give top level plugin providers precedence over default providers
This change allows top level plugins to take the names of default providers. For example, the cuttlefish plugin, which requires control over the release building, will be
{default, release}
and{default, tar}
in order to make this possible.