Closed wichert closed 1 year ago
Seconding this, to be honest I don't really care about linting styles but black is great because the autofix allows you to never worry about linting. I configure VSCode to automatically run black on save - it's saved me a lot of time.
Seconding (thirding?) this. Black is so widely used that by depending on the old click version you're severely limiting the environments this library can be installed in.
Things have been going slower this month for me than I planned, but I will have it this week. However, I'm interested in your (@wichert @Almenon @jorenverspeurt) usage of aws-sso-util
as a library. aws-sso-util
is intended to be installed as a standalone CLI utility (e.g., through pipx); all library use cases are supposed to be supported through aws-sso-lib
, which doesn't use click at all. As an example, get_token_fetcher()
is in aws_sso_lib.sso
, it's not actually in the aws-sso-util
code at all.
After some recent refactoring we still have a dependency on aws-sso-util
to have aws-sso-util credential-process
available for use in profile configuration.
Are you sure you still need aws-sso-util credential-process
? Almost all the language SDKs support SSO configuration now.
I haven't touched the standalone credential process I made since I folded it into aws-sso-util but it might still work and doesn't use click: https://github.com/benkehoe/aws-sso-credential-process
Released in aws-sso-util v4.31.
aws-sso-util uses click v7. This is not compatible with black, which requires click v8. This is a bit problematic for me since I'm working on a package that calls into some aws-sso-util cli internals (
get_token_fetcher
in particular), and I can't run black to enforce consistent coding style due to this conflict.