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

fix: gradle init support #1040

Merged
merged 7 commits into from
Mar 8, 2019
Merged

fix: gradle init support #1040

merged 7 commits into from
Mar 8, 2019

Conversation

sriram-mv
Copy link
Contributor

@sriram-mv sriram-mv commented Mar 5, 2019

  • Add ability in sam init to specify dependency manager and generate
    appropriate sam templates.

  • Write Design Document (Do I need to write a design document?)

  • Write unit tests

  • Write/update functional tests

  • Write/update integration tests

  • make pr passes

  • Write documentation

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

- Add ability in sam init to specify dependency manager and generate
  appropraite sam templates.
"dotnetcore1.0_cli-package": os.path.join(_templates, "cookiecutter-aws-sam-hello-dotnet"),
"dotnetcore_cli_package": os.path.join(_templates, "cookiecutter-aws-sam-hello-dotnet"),
"dotnet_cli-package": os.path.join(_templates, "cookiecutter-aws-sam-hello-dotnet"),
"go1.x_go-get": os.path.join(_templates, "cookiecutter-aws-sam-hello-golang"),
Copy link
Contributor

Choose a reason for hiding this comment

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

go_get? Shouldn't this be dep vs modules to match our builders?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, you are right, I just went by the go inits.

"java_gradle": os.path.join(_templates, "cookiecutter-aws-sam-hello-java-gradle")
}

RUNTIME_DEP_MAPPING = {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not encapsulate this into the Runtimes enum to keep all of this into one place?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe, I need a double mapping though. Language -> Dep manager and language, dep combo to template. will think about it.

"dotnetcore1.0": ["cli-package"],
"dotnetcore": ["cli-package"],
"dotnet": ["cli-package"],
"go1.x": ["go-get"],
Copy link
Contributor

Choose a reason for hiding this comment

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

dep or modules?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, will change it.

"go": os.path.join(_templates, "cookiecutter-aws-sam-hello-golang"),
"java8": os.path.join(_templates, "cookiecutter-aws-sam-hello-java"),
"java": os.path.join(_templates, "cookiecutter-aws-sam-hello-java")
RUNTIME_DEP_TEMPLATE_MAPPING = {
Copy link
Contributor

Choose a reason for hiding this comment

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

There is a lot of mappings to keep updated all together. Can we condense these into one?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will see how to condense this.

"go1.x_go-get": os.path.join(_templates, "cookiecutter-aws-sam-hello-golang"),
"go_go-get": os.path.join(_templates, "cookiecutter-aws-sam-hello-golang"),
"java8_maven": os.path.join(_templates, "cookiecutter-aws-sam-hello-java-maven"),
"java_maven": os.path.join(_templates, "cookiecutter-aws-sam-hello-java-maven"),
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need a java_maven and a java8_maven? This questions is a general question as we have shortcuts for every language which makes sam init --help super long and is only going to get worse if we have to shortcut all language + dependency manager combinations.

The code for maven and gradle look the same. Are they? If so, do we need to maintain two copies directly? Can we combine them so our java examples are the same but can have different dependency managers?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not really the same, slightly different source files, but the core java files are the same. We can look at de-duping that bit of source code.



class TestInit(TestCase):

def setUp(self):
self.location = None
self.runtime = "python3.6"
self.dependency_manager = "pip"
Copy link
Contributor

Choose a reason for hiding this comment

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

What about the None case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will add a test for this, if a dependency manager is not given, we default to our choice.

# The config mutates based on the workflow selector, so they are not to be imported and used from the template mapping.
# They are an indication of metadata associated with a specific runtime.

RUNTIME_DEP_TEMPLATE_MAPPING = {
Copy link
Contributor

Choose a reason for hiding this comment

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

This does not make sense. Why would you depend on the build workflow configs within init. They should be treated as isolated modules. Otherwise you will end up with a tangled mess of dependencies one year from now.

Copy link
Contributor

Choose a reason for hiding this comment

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

@jfuss filled me in on the intention of this mapping. The config here makes sense (as a true configuration data), but I am not excited about importing workflow_config which is an implementation detail. Can we just remove the workflow configs because they are not really used? That would make me more happy :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will remove that. 👍

# The config mutates based on the workflow selector, so they are not to be imported and used from the template mapping.
# They are an indication of metadata associated with a specific runtime.

RUNTIME_DEP_TEMPLATE_MAPPING = {
Copy link
Contributor

Choose a reason for hiding this comment

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

@jfuss filled me in on the intention of this mapping. The config here makes sense (as a true configuration data), but I am not excited about importing workflow_config which is an implementation detail. Can we just remove the workflow configs because they are not really used? That would make me more happy :)

]
}

SUPPORTED_DEP_MANAGERS = set([c['dependency_manager'] for c in list(
Copy link
Contributor

Choose a reason for hiding this comment

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

I understand what this line is doing, but boy there are so many brackets!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, Having a single config, makes extraction a bit more dense.

@jfuss jfuss dismissed sanathkr’s stale review March 8, 2019 15:16

jfuss approved

@jfuss jfuss merged commit 5deff3c into aws:develop Mar 8, 2019
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