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

Use directed codegen #47

Merged
merged 3 commits into from
May 24, 2022
Merged

Use directed codegen #47

merged 3 commits into from
May 24, 2022

Conversation

JordonPhillips
Copy link
Contributor

@JordonPhillips JordonPhillips commented May 4, 2022

This updates the python generator to use the directed codegen. This reduces the amount of fiddly repetitive work we have to do.

This relies on smithy-lang/smithy#1214 to some extent since we need the topological sorting.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@JordonPhillips JordonPhillips requested a review from a team as a code owner May 4, 2022 16:12
@JordonPhillips JordonPhillips requested a review from gosar May 11, 2022 16:18
Copy link
Contributor

@nateprewitt nateprewitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just one minor comment about mypy (and I guess potentially black)

try {
CodegenUtils.runCommand("python3 -m mypy -h", fileManifest.getBaseDir());
} catch (CodegenException e) {
LOGGER.warning("Unable to find the python package mypy. Skipping type checking.");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Skipping this makes me a little leary. Do we want a way to enforce strictness on this so we don't accidentally generate code without type checking?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is gonna run for all our customers too, who may not care as much. It may be worth it for us to create our own temporary virtualenv, but since this is existing code that just got moved, I think that should be done in a separate pr.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, definitely don't want it required everywhere. I was thinking more in the context of a way to opt into these being required. I'm fine handling discussion in a separate PR though.

@JordonPhillips JordonPhillips merged commit d2cfc58 into develop May 24, 2022
@JordonPhillips JordonPhillips deleted the remove-ssdk-stuff branch November 2, 2022 15:44
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

Successfully merging this pull request may close these issues.

3 participants