Aws-cli: [v2] Please drop Python 2 support

Created on 27 Jun 2019  路  6Comments  路  Source: aws/aws-cli

Since awscli v2 can be packaged with Python 3, why Python 2 support is needed?

Python 2.7 will become EOL at 2020-01-01. It's a very important milestone for library maintainers to drop Python 2 support.
But if Python 2 is still supported by awscli, it puts pressure to keep supporting Python 2 to library maintainers.

Please note that it is not a problem only for AWS, but also all maintainers who maintain libraries aws-cli depends on.

needs-discussion v2

Most helpful comment

I know it's been a few months here but wanted to comment on this. First, we're dropping 2.6/33 support in less than a month: https://aws.amazon.com/blogs/developer/deprecation-of-python-2-6-and-python-3-3-in-botocore-boto3-and-the-aws-cli/

After thinking about this more, I'm thinking if it really is worth supporting py27 for the CLI v2, especially if we're building binaries that use python3. It definitely has required more maintenance effort and I'm not sure who'd actually be using py27 on CLI v2. We'd also only officially support the binaries we generate (which we test) so we'd only run our unit/functional/integ tests on py27.

I'd like to hear what everyone thinks.

All 6 comments

Hi, sorry for the delay here.

Since awscli v2 can be packaged with Python 3, why Python 2 support is needed?

I think it's mostly an issue of timing. We will eventually drop python 2 support, I think it's just a matter of how. Given that the officially supported installation mechanisms for AWS CLI v2 will vendor python3, and pip will no longer be an officially recommended way of installing CLI v2, in theory the number of python2 users should drop as customers migrate over to CLI v2. At the same time, we realize not everyone will want to use our supported installation mechanisms, and may prefer alternative mechanisms e.g. various linux distro packages, homebrew, docker, snap, etc., so we'd like to see how this plays out.

Once enough customers are no longer using python 2 with the AWS CLI, we can drop support for it.
There will also be a period of time where we'll have to support both AWS CLI v1 and v2, so I would imagine there may be some backporting between both versions.

Additionally, if pip is no longer being used to install the AWS CLI, then any of our dependencies would also see a corresponding drop in their pip download numbers as people migrate. I've seen a number of discussions on other projects where a key metric in deciding python version support is number of installs via pip's metrics. So it seems like not using pip for CLI v2 would effectively have the same desired result for package maintainers.

So AWS CLI v2 shouldn't exacerbate the python 2 issue. And we won't be able to drop python 2 support in AWS CLI v1 until customers are no longer using python2 which we hope would happen as people migrate over to CLI v2. Also, our dependencies have dropped support for a python version before we do, which makes an even stronger case for us to drop support for a python version. For example, urllib3 no longer supports python2.6 even though we still support it (but I'd really really like to drop 2.6 support).

One last thing to keep in mind is none of this is set in stone. Based on feedback, this all can change. We haven't really had a discussion on py2/py3 support yet, so we'd love to hear what everyone thinks.

I think that the original request is a bit misleading or is proposed too soon. I much sane approach is to drop python2.6, python3.3, python3.4 NOW and doing the drop of python2.7 in 2020 once we face the first breaking bug in a dependency that already dropped python2.7.

But having CI enabled on python2.6 and python3.3 seems like a bad joke to me. We cannot even run old versions of pip, setuptools, with these. On MacOS for example, these python version no longer compile and nobody will patch them.

To give a practical example: in order to enable use of conditions in install_requires we need a newer version of setuptools, something that is not available in older python. Mainly the current support matrix block fixing other bugs, like https://github.com/aws/aws-cli/pull/4438

I know it's been a few months here but wanted to comment on this. First, we're dropping 2.6/33 support in less than a month: https://aws.amazon.com/blogs/developer/deprecation-of-python-2-6-and-python-3-3-in-botocore-boto3-and-the-aws-cli/

After thinking about this more, I'm thinking if it really is worth supporting py27 for the CLI v2, especially if we're building binaries that use python3. It definitely has required more maintenance effort and I'm not sure who'd actually be using py27 on CLI v2. We'd also only officially support the binaries we generate (which we test) so we'd only run our unit/functional/integ tests on py27.

I'd like to hear what everyone thinks.

Hi @jamesls,

It would be great to drop support for legacy Python versions and move forward.
But could you please add support for Python 3.8 first (#4404)?

Thanks!

Yes, I commented on the PR. Let's keep this issue about dropping py2 support though. Thanks!

We recently merged a PR for the v2 branch that dropped support for Python 2: https://github.com/aws/aws-cli/pull/4901. I think going forward the plan is to support only the Python version that the binaries run on plus any future versions of Python to make sure it is easy for us to migrate to the new version. Closing issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

pawelkilian picture pawelkilian  路  3Comments

brettswift picture brettswift  路  3Comments

motilevy picture motilevy  路  3Comments

braddr picture braddr  路  3Comments

rahul003 picture rahul003  路  3Comments