Repository navigation
Docker version is not compatible with aws-sam-cli #73
Description
At the moment this plugin requires docker>=3.7,<3.8" (https://github.com/aws-cloudformation/cloudformation-cli-python-plugin/blob/master/setup.py#L40), aws-sam-cli requires docker~=4.0 (https://github.com/awslabs/aws-sam-cli/blob/develop/requirements/base.txt#L9).
Since both are command line tools, and sam cli is the recommended way to test the provider, changes are high that they will be installed in the same virtualenv. To make development easier, they should probably be in sync.
Activity
tobywf commentedon Jan 9, 2020
we can certainly fix this one, tbh i'm not quite sure why it's pinned so strictly.
but the docker one isn't the only one that could be in conflict if installed in the same virtualenv (directly: PyYAML, requests, and boto). one solution is to track what SAM does, but that's fragile. another is to recommend SAM CLI be installed in some other way, e.g. on macOS via homebrew. or we could depend on SAM CLI in the core requirements, but then if you already have it installed... there's no ideal solution as far as i can see
benbridts commentedon Jan 10, 2020
There isn't and I believe cfn-lint has similar problems (they depend on aws-sam-translator).
Using sam in its own virtualenv comes with its own complexities and I know sam chooses to recommend homebrew (osx/linux) or msi installers, but that's a lot less user friendly than "pip install -r build-requirements.txt".
Doing less strict pinning and updating when issues are raised would be an acceptable compromise in my opinion. It allows users ton choose to treat it as a code dependency. Once you use more than one dependency you will have to deal with dependency conflicts anyway.
Something to keep in mind is that it will not be possible for users to install plugins into separate environments, so keeping dependencies in sync between everything cloudformation-cli-* would be something I'd expect as a user.
benkehoe commentedon Jan 10, 2020
The AWS CLI v2 is taking the approach of distributing an installer, rather than being available through language-specific package management. Maybe that's the right approach for other AWS CLI tools as well?
benbridts commentedon Jan 10, 2020
I probably should bite the bullet and install SAM with brew.
I know this is more of a tangent, but I would love to have one way to install all tools needed to build something on AWS. (and have them work without conflict, using pip for most and dealing with conflicts when they manifested themselves has been my approach for now, maybe I should switch to something else..
Currently there are as many ways to install tools as there are teams: SAM uses brew or an MSI, CLI v2 has it's own script, CloudFormation CLI uses pip, ECS CLI is "download this go binary", EB has another script, eksctl is a go binary but uses brew and chocolaty. Having one preferred way for everything would definitely simplify things.