Aws-cdk: Must pip install every AWS service

[ccfife]

Note: for support questions, please first reference our documentation, then use Stackoverflow. This repository's issues are intended for feature requests and bug reports.

• I'm submitting a ...

  • [ ] :beetle: bug report
  • [X] :rocket: feature request
  • [ ] :books: construct library gap
  • [ ] :phone: security issue or vulnerability => Please see policy
  • [ ] :question: support request => Please see note at the top of this template.

• What is the current behavior?
  If the current behavior is a :beetle:bug:beetle:: Please provide the steps to reproduce
  Some Python developers don't like having to pip install a package for every AWS service they want to use in their CDK apps. In their own words:

• "Vending all of the services as separate pip packages isn't the easiest to work with"

• "Constantly going back and forth for a pypi package was a pain."
• "not a huge fan of having to install each service separately, feels very npm-ish"
• "upgrading all my pip modules to the latest release was also kind of a pain."

• "... first thought is... holy crap, that's really granular. This isn't node, people. Python folks do not expect that kind of granular packages!"

• What is the expected behavior (or behavior of feature suggested)?

1 package to rule them all

• What is the motivation / use case for changing the behavior or adding this feature?

a more Pythonic developer experience

• Please tell us about your environment:

  • Language: [ Python ]

• Other information
  As an alternative approach to a monolithic package, what if there were init templates for Python CDK projects that populated the requirements.txt file with some or all of the modularized packages. For example cdk init --language python all references every CDK package in requirements.txt so that pip install -r requirements.txt gets everything. The 'Lambda' template creates a requirements.txt that references the Lambda, APIGateway, DynamoDB, S3, SNS, and SQS packages; 'containers' - ECS, ECR, EKS, and EC2; and so on.

Would this address the problem?

[eladb]

I like the init template approach. How about we make our sample-app templates include all modules by default. That’s a good way to easily familiarize oneself with the CDK

[garnaat]

I think expanding the init templates to handle more use cases makes sense and, by default, each init template would come with a requirements.txt that automatically installed all necessary modules. We could even run the pip install -r requirements.txt as part of the init process itself. Note that this doesn't really address the problem of needing an additional module after the init process. This is, I think, where the friction arises. For example, you decide you need to add a queue to your application and so you try to do the import in your code and discover that none of the help is available because you don't have the module installed. Then you have to switch gears, find the right module, add it to your requirements.txt and install it. It's distracting.

I think some sort of IDE experience that recognized that the right module was not installed and installed it automatically would be a great experience though not easy to do.

I question whether anyone would really want all. Ever. Nor do I think anyone would really be happy with one monolithic module. It would be absolutely enormous.

[hoegertn]

What about providing a "bill-of-materials" package that depends on all packages. So each developer could decide to use individual packages or just add the bom-package?

[garnaat]

I like this idea but I'm still skeptical that anyone would want all of the modules. A variation on this would be to have various collection packages available, e.g. serverless, ML, etc., that grouped together a bunch of individual modules that would commonly be used together.