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
phobologic
left a comment
There was a problem hiding this comment.
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. |
phobologic
left a comment
There was a problem hiding this comment.
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!
phobologic
left a comment
There was a problem hiding this comment.
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!
phobologic
left a comment
There was a problem hiding this comment.
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
|
|
||
| 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.
Does this PR aim to also move these over to the new classes?
There was a problem hiding this comment.
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.
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.
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. |
phobologic
left a comment
There was a problem hiding this comment.
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.