Bug#970804: awscli: Please package AWS CLI 2.0
> I've looked at this a little more. From what I can tell, the dependency
> on botocore v2 is really going to make this hard to package. We can't
> simply update the botocore packages to version 2, since it is not
> backwards compatible with v1. Existing packages that depend on botocore
> would need to be updated, but worse would be all the custom code that
> we'd be breaking with such an upgrade.
Thanks for investigating. I wasn't aware of such a breaking change on
botocore.
> It doesn't help that the botocore project still isn't actually making
> releases from the v2 branch (See https://github.com/boto/botocore/issues/2080)
That issue links to: https://github.com/aws/aws-cli/issues/5282
I've asked there if using awscli with botocore v1 is possible.
> I'm not sure that we've got any good options right now, but maybe I'm
> missing something. We can do one of the following:
>
> 1. Leave awscli v2 and botocore v2 unpackaged (current state)
That would be the easiest solution...
> 2. Package botocore v2 as a new package that conflicts with v1 (this
> allows both to co-exist in the archive, but not on an installed system.
This would definitely cause problems when v1 is needed for other tools.
> 3. Package botocore v2 as a new package in such a way as to permit
> side-by-side installation with v1. This likely involves essentially
> renaming the package, which means a bunch of mangling of python import
> paths. This requires any client code using botocore to be written (or
> patched) to specifically target this modified version.
AWS provides bundled installers:
https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-linux.html#cliv2-linux-install
Perhaps there is a way to re-package this in a way that doesn't affect
other software in the system? Not the best approach, sure, but this
deviation can be cleaned up when botocore v2 enters Debian.
> Is there something else I'm missing? Given that awscli v2 specifically
> depends on botocore v2, I doubt it's reasonable to port it to v1, but
> that could potentially be another option.
Let's see if upstream can help.
Reply to: