-
Notifications
You must be signed in to change notification settings - Fork 167
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
Make lookup-logic more generic #665
Conversation
e2062a2
to
7a8303c
Compare
The new parser will build the entire AST to support nested lookups.
7a8303c
to
fd996e9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only one small suggestion, but otherwise this looks great! A lot simpler than what I had imagined too, so that's really great to see. Are you thinking you'd convert all the lookups to the new format in this, or just Output?
Thanks again for this - other than the small code question, the docstrings need some updates to use the Google syntax. Also, I'm curious if there's more tests that should be written, or if you think the old tests cover enough ground? The dependency stuff seems like it'd be worth something.
Thanks again!
556bd11
to
ab6190c
Compare
210fa2a
to
01dc5fd
Compare
I've addressed the comments in a new commit. I'll squash these later, but this way, you can easily follow the changes as I make them. Please notify me if this PR is acceptable for merge, so I can rebase this PR into more logical commits. I've only converted the Output lookup, since that is the only lookup that needs the new syntax (to inject dependencies). The code currently supports both types. It's up to you to decide if you want to keep support for both, or to deprecate the old style. Let me know of you want me to convert the other lookups as well. It's fairly straightforward to do. The current tests actually cover pretty much of the new code already (88% of variables.py), but not as much as the previous implementation. I'll see if I can spend some time later this week to get the test coverage back up. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great. It's probably worth it for us to convert the old Lookups into the new style lookups, just so that folks don't try to create new ones for the old style lookups. That said, I can work on that in another PR if you don't have the time - I appreciate what you've done so far!
Another thing that might be worth thinking about is throwing a warning around old style lookup registration, at least for custom lookups - that way folks will realize, in this next release, that the old style is being deprecated and prepare their lookups for the release after that.
Let me know when you feel comfortable with the tests/etc, and I'll go ahead and give it one final look and merge it. Thanks again, this is great stuff!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great. It's probably worth it for us to convert the old Lookups into the new style lookups, just so that folks don't try to create new ones for the old style lookups. That said, I can work on that in another PR if you don't have the time - I appreciate what you've done so far!
Another thing that might be worth thinking about is throwing a warning around old style lookup registration, at least for custom lookups - that way folks will realize, in this next release, that the old style is being deprecated and prepare their lookups for the release after that.
Let me know when you feel comfortable with the tests/etc, and I'll go ahead and give it one final look and merge it. Thanks again, this is great stuff!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great. It's probably worth it for us to convert the old Lookups into the new style lookups, just so that folks don't try to create new ones for the old style lookups. That said, I can work on that in another PR if you don't have the time - I appreciate what you've done so far!
Another thing that might be worth thinking about is throwing a warning around old style lookup registration, at least for custom lookups - that way folks will realize, in this next release, that the old style is being deprecated and prepare their lookups for the release after that.
Let me know when you feel comfortable with the tests/etc, and I'll go ahead and give it one final look and merge it. Thanks again, this is great stuff!
Sorry for the spam - I blame github :) |
2e75f7f
to
a99801e
Compare
stacker/lookups/registry.py
Outdated
@@ -80,7 +97,7 @@ def resolve_lookups(variable, context, provider): | |||
return resolved_lookups | |||
|
|||
|
|||
register_lookup_handler(output.TYPE_NAME, output.handler) | |||
register_lookup_handler(output.TYPE_NAME, output.OutputLookup) | |||
register_lookup_handler(kms.TYPE_NAME, kms.handler) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this PR aim to also move these over to the new classes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, but I can't get the linting to work on my machine, so I'm abusing CircleCi...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please post error, I think I ran into this before.
For me, I needed to install flake8-future-import
and naming
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm getting tons of Deprecation warnings, so the actual things I need to fix are hard to find
77b722a
to
6fe83ca
Compare
6fe83ca
to
2c441bf
Compare
This PR is, as far as I'm concerned, in a mergable state. I don't have much more time to work in this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great, thanks @nielslaukens !
* Rewrote Lookup-parser The new parser will build the entire AST to support nested lookups. * Move dependency injection of ${output} to the lookup itself * Addressed comments * Removed dead code * Fix lint warnings * Fix lint errors after master merge * Fix lint error (unused exception) * Add warning when using old style lookups * Convert lookups to new style * Reformat code to fix linting errors
* Rewrote Lookup-parser The new parser will build the entire AST to support nested lookups. * Move dependency injection of ${output} to the lookup itself * Addressed comments * Removed dead code * Fix lint warnings * Fix lint errors after master merge * Fix lint error (unused exception) * Add warning when using old style lookups * Convert lookups to new style * Reformat code to fix linting errors
This Pull Request is work in progress. It has been opened to solicit feedback while it is developing.
This patch is an attempt to fix issue #664, and extending the functionality of the lookups. Currently, the
${output stack::name}
lookup is treated specially to allow it to inject dependencies. This is an attempt to make the logic more generic, so new/other lookups can also inject their dependencies.