Now that we've dropped Python 3.9 support, we can get rid of these. Some
of these were actually deprecated in Python 3.9 too, but they must've
slipped through after the last cleanup round.
Done with:
ruff check --select=UP006,UP035 --target-version=py310 --fix
--unsafe-fixes
plus a bit of manual cleanup.
- [x] I submit my changes into the `develop` branch
- [x] I have created a changelog fragment
- [x] I submit _my code changes_ under the same [MIT License]
---------
Co-authored-by: Petr Iosipov <petr.iosipov@cvat.ai>
The only reason to display separate UI and server version (IMO) is that
sometimes they can diverge due to deployment issues, and the information
can help with diagnostics. So it seems much more useful to use the same
version numbering as for the server, since:
* This makes it much easier to see whether a divergence exists.
* We can automate updates to it, eliminating annoying busywork for
developers.
* We don't need to show multiple versions for different UI components,
simplifying the code and the UI.
isort has a `--resolve-all-configs` options that allows you to use
different configs for different subdirectories. With this option, we can
reformat/check the whole codebase with one command. So let's just do
that.
It's a little janky, because isort's first party module detection
doesn't seem to work properly when you run it from the project root and
not the appropriate subdirectory. So I had to patch that up with
explicit `known_first_party` settings. I also didn't feel like doing
that for all of the serverless functions, so I just added them to the
ignore list for now.
Make the Black workflow just run black with default settings. Instead of
including specific directories, exclude the ones that haven't been
blackened yet via `pyproject.toml`.
Leave a few small files out of the exclusion list; blacken them instead.
This is one step towards project-wide code formatting. It also makes it
easier to format your entire patch when you touch multiple components,
since you don't have to remember which directories to apply `black` to.
This automates the first half of the current release process. The second
half will be implemented by another workflow.
The reason why it can't all be done in a single workflow is that it's
useful to let developers inspect what'll go into the release before
actually publishing it, and to apply any last-minute fixes, if
necessary. It also allows CI to complete for the release PR.
To support the new workflow, add a `--set` option to `update_version.py`
that sets the version to a custom value.
The main motivation was to add SDK and schema-related version updates,
which were missing from the original script. I also did a bunch of
refactoring to make changing the replacement rules easier, and added a
checking mode to make sure that version numbers are consistent across
the project (adding a corresponding check to CI).
Roman Donchenko