Ruff code auto-format

[SofiaSazonova]

Feature or Bugfix

• Refactoring

Detail

Ruff tool configured for the project.
All files are formatted
In pipelines instead of "make lint" now "make ruff" is used

Relates

#1076

Security

Please answer the questions below briefly where applicable, or write N/A. Based on
OWASP 10.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[SofiaSazonova]

Flake8 fails, but it's fine by now. It's only a first iteration of introducing Ruff.
Ruff rules are slightly different

[petrkalos]

Since this is python and even format changes can easily break functionality can you describe what short of testing did you perform to validate the PR?

[petrkalos]

I wouldn't makefile target tool specific, let's keep it as lint

[SofiaSazonova]

May be we can keep both? I don't want the name to be confusing, since it's just an alias

[petrkalos]

Previously we were running flake8 and we called the target lint and not flake8 which I think is correct because it's abstracting whatever underlying linter we use and also that way we wouldn't have to change the pipelines code.

[petrkalos]

shouldn't we run ruff format here as well?

[petrkalos]

btw forgot to say that we should be taking into account both check and format exit codes and fail the target if either of them fail.

[petrkalos]

Should we keep target-version as 39 which is the lambda runtime version we use?

[petrkalos]

why exclude migrations?

[SofiaSazonova]

Alembic has one weakness, you sometimes have to keep unused imports and other strange stuff. Also, migrations are usually something very specifically tailored, so I thought it's better to exclude this.
But of course I can just add 'noqa'-statements, where it's needed

[petrkalos]

If there are standard strange stuff for Alembic perhaps it's better to use per-file-ignores than noqa

[SofiaSazonova]

I enabled all formatting back. And added block-comment for current unused imports. In future, if something like this comes up again, we can decide on-the-go, if any other re-configuration is needed

[SofiaSazonova]

And the problem with flake8 testing of this PR is
E704 multiple statements on one line (def)
It's a known disagreement, e.g. discussed here
May be we should reconfigure the Github testing then.

[SofiaSazonova]

Since this is python and even format changes can easily break functionality can you describe what short of testing did you perform to validate the PR?

1. Run 'make test' to ensure, that integration test are fine
2. Run 'cdk list' to ensure, that deployment is build without errors (there were some troubles with imports, that i caught that way)
3. Perform migrations (drop and upgrade) for local database
4. Check that CICD pipeline completed

[petrkalos]

And the problem with flake8 testing of this PR is E704 multiple statements on one line (def) It's a known disagreement, e.g. discussed here May be we should reconfigure the Github testing then.

Oh I thought we were going to drop flake8 on a next PR.
I don't think it makes sense to keep 2 formatters/linters.

[petrkalos]

Since this is python and even format changes can easily break functionality can you describe what short of testing did you perform to validate the PR?

1. Run 'make test' to ensure, that integration test are fine
2. Run 'cdk list' to ensure, that deployment is build without errors (there were some troubles with imports, that i caught that way)
3. Perform migrations (drop and upgrade) for local database
4. Check that CICD pipeline completed

I think another thing you could run is to make some requests through the cdkproxy, an action that will create a new stack (i.e create a new dataset or environment etc)

[dlpzx]

Looks good to me