Open jsumners opened 4 years ago
Also interested in this.
Besides depreciation blogs stating Python 2.6/3.3 drop of support I haven't found any blog about till when date v1 will be supported and should we switch to v2 now.
Hi @jsumners and @Suncatcher, thanks for asking. Marking this as needs discussion.
As an update to this, please refer to the recently published AWS SDKs and Tools Maintenance Policy. The AWS CLI v1 is still in general availability phase.
It looks like v1 will stay here for a while like AWS SDK for Java | 1.x | 3/25/2010 | Full Support =) without Next Phase
AWS CLI | 1.x | 9/2/2013 | Full Support |
-- | -- | -- | -- |
AWS CLI | 2.x | 2/10/2020 | Full Support |
Well that answers the "when" portion of the question, but it doesn't address the ongoing tracking of updates portion of the question. The CLI v1 page still pushes you to install v2 (https://docs.aws.amazon.com/cli/latest/userguide/install-cliv1.html), but v2 cannot be as easily updated as v1.
We recommend that you use AWS CLI version 2 instead — which is not installable even in AWS Lambda (due to being not published on PyPI, see #4947).
Nice recommendation, ain't it.
I am leaving a comment here, as I would very much like to know the answer to this question: "When will aws cli v1 be marked EOL". As soon as there is an EOL date, I have leverage to start migrating to v2...but not until.
Do not end-of-life this until the latest AWS CLI can be installed via PyPI.
It seems that someone within AWS seems dead-set on the decision to not support this method of installation. Unfortunately, that's just not going to work for those of us who work in more unusual environments. In particular, the requirement for glibc
makes this unsuitable to be included in the 90% of the container ecosystem that depends on Alpine Linux and systems like it. For those of us who've bet on Python for cross-platform compatibility, this is also directly squandering our investment.
It's perplexing that containers are a second-class citizen when Amazon says publicly that EKS and ECS are first-class products. If this is EOL'd without a suitable replacement (as determined by your customers, not a project manager), it will falsify that statement and undermine faith in AWS as a viable business partner for technical endeavors.
To any readers who've made it this far, please replace this sentence with the strongest brand of insult that still complies with the GitHub Code of Conduct. This decision is unwise, the level of dedication to it is unfortunate, and locking related issues to silence criticism is despicable. Listen to your users.
And, if your organization is unable to take a reasonable direction; give actual, defensible business reasons for doing this. Because issues handled like #4947 are downright offensive to those of us who pay you 7 or 8 digits a year for a service that we now can't even automate easily. This is patently not acceptable for someone who bills themselves as "Earth's most customer-centric company".
Please keep this thread on topic.
As a watcher of #4947, I can't disagree with @jvantuyl at all. The pain behind that comment, ever so much attenuated by writing — is real. It's familiar. pip install aws-cli
-level familiar. Unexpressable requirements.txt
-level familiar.
Undeployable to Heroku-style application servers level of familiar. Unpackageable-except-as-a-whole-OS-image level of familiar.
Unreproducible builds level of familiar. (What's up with the botocore
versioning issue again?..)
Unusable in AWS Lambda level of familiar. (Because why? Because please make it pip install
-able.) :man_shrugging:
"awscli v2 is garbage, forget about it and stick to v1" level of familiar.
P.S: the takeout for those who don't see how this is relevant to the topic: don't EOL awscli v1 before pip install awscli>=2.0.0
works.
Kind of waiting for this to be auto-closed by a bot / during "backlog grooming" at some point. An answer here would be nice. Just the answer to "When will we v1 be EOL?" would be great. If we're getting public recommendations for this, then surely someone has a date somewhere?
To any readers who've made it this far, please replace this sentence with the strongest brand of insult that still complies with the GitHub Code of Conduct
This is probably the most remarkable insult that I've ever seen on github :joy:
Please keep this thread on topic.
If that message is not on-topic then the topic needs to be changed. It's the most-reacted-to message in the entire thread for a reason.
There are several notices on https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html that state one should be using version 2 of the library going forward. But I can't find any information about when version 1 will be de-supported/end-of-lifed. I need to know this information so I can plan how to build systems that depend on this tool.
https://github.com/aws/aws-cli/issues/4947#issuecomment-586046886 says:
But that's the only, seemingly "official," statement I have been able to find. It's not a very reassuring one given all of the statements like:
^ A clear emphasis is placed on using v2 over v1.
Additionally, if I'm building e.g. Docker images that rely on this tool, how do I get updates? https://github.com/aws/aws-cli/issues/4961 directly asks this question and the answer is poor given that v1 is maintainable through common tooling instead of checking a git repo.