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

Phase final necessity and ability for phases to expose providers for downstream targets #917

Closed
ittaiz opened this issue Jan 15, 2020 · 1 comment

Comments

@ittaiz
Copy link
Member

ittaiz commented Jan 15, 2020

@borkaehw @andyscott while working on #916 I started wondering about the motivation behind run_phases returning the global provider and then having the rules call .final?
The cons I see are that every rule needs to "remember" to call .final and additionally custom external phases cannot expose providers for downstream targets.
Is the latter by design?

I have a hunch that if we change the phase return value contract to be 2 dicts where one is of "internal providers" (similar to today but more typed and explicit) and a dict of "external providers" and then run_phases just returns the values of this dict then rules can just return the output from run_phases (one less thing to remember) and additionally we'll be allowing phases to expose providers (currently this isn't an option). WDYT?
I'm saying dict to allow phases to override providers of previous phases.

@andyscott
Copy link
Contributor

This seems reasonable to me. I'm almost always in favor of phases being able to cleanly customize what's being returned by the rules.

@ittaiz ittaiz closed this as completed Jan 23, 2020
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

No branches or pull requests

2 participants