Eclipse infra (#2)

* [python] Create our first python bazel quality rule

This commit:
- create a generic python aspect that can interface multiple runners;
- create our first python runner that runs pylint;
- create the aspect user interface at defs.bzl;
- create a default pylint runner config at quality/BUILD;
- adds `quality/private/python` to our poetry/tox setup;
- adds pylint aspect config to .bazelrc;
- create a target for pyproject.toml.

* [black] Add black aspect and runner

This commit:
- adds a functional black aspect and runner;
- offers the aspect though quality/defs.bzl;
- as planned, make use of both python_tool_aspect.bzl and python_tool_common.py;
- add a black config to .bazelrc.

* Toolchains from rules_python and support for both bzlmod and workspace

We currently have our own python toolchain and support only bazel workspace,
 even though we have bzlmod activated.

This commit removes our python toolchain in favor of rules_python toolchain.
 By doing this we increase toolchain support for multiple system, add support
 for both bzlmod and workspace, add support for multiple OSs, and easily
 update our toolchain version when a new one is released.

Other minor changes were made:
- change bazel labels to fit the new python toolchain;
- add a tools availability to our README.md

* [python] Improve LinterSubprocessError content

This modification allows the caller to have access to the actual subprocess
 stdout and stderr. This is important because the caller may rely on that
 information in case of a non-zero return code.

Example, isort returns 1 when it finds something, but we still want
 execute_subprocess to throw so we, on the application level, may be able to
 catch and evaluate it.

Each application will do its own evaluation.

* [isort] Add isort aspect and runner

This commit:
- adds a functional isort aspect and runner;
- offers the aspect though quality/defs.bzl;
- as planned, make use of both python_tool_aspect.bzl and python_tool_common.py;
- add a isort config to .bazelrc.

* [python] Fix how python_tool_common check for relative paths

The current approach is wrong because it relies on the string `startswith`
 method.

This work on some cases but throws an exception on another ones, for example,
 "myapp" is not relative to "myapp_lib/path/..." but  "myapp_lib/path/.."
 startswiuth "myapp".

To avoid this we should rely on pathlib `is_relative_to`. This ensures that a
 path is actually relative to the other one instead of just comparing the
 string.

* [python] Add mypy aspect and runner

This commit:
- adds a functional mypy aspect and runner;
- offers the aspect though quality/defs.bzl;
- as planned, make use of both python_tool_aspect.bzl and python_tool_common.py;
- add a mypy config to .bazelrc.

* [python] Fix mypy findings

This commit fixes every finding that doesn't come from clang-tidy or qac
 targets. Later PRs can fix those as well.

* [python] Change how we create python aspect output file name

Multiple python runners may use the same entry_point, for example, ruff. With
 that in mind one might expect that, as the output file name is based on the
 tool and not on the runner, a conflict will happen when both runners are
 triggered.

This commit prevents that by changing how we name the output file, which will
 from now on be based on the runner name.

This commit also renamed runners, for example, pylint_runner to pylint, and
 also add an "_entry_point" to the py_console_script_binaries to avoid
 confusion. With this, for example, the pylint output file will still be
 called pylint_output_target_name.

* [python] Add ruff aspect and runner

This commit:
- adds two functional ruff aspects and runners, one to check files and another
 to format files;
- offers the aspects through quality/defs.bzl;
- as planned, make use of both python_tool_aspect.bzl and python_tool_common.py;
- add a ruff config to .bazelrc.

Two runners were created because ruff has both a check and a formatter. Each
 one of those must be invoked individually and therefore we have two output
 files. Knowing that the aspect requires one output file, ruff runner was
 splitted into two.

Also, as ruff python library doesn't provide a default entry point, a
 ruff_entry_point.py had to be created.

* [python] Create a support directory with a default pyproject file

The default config should not be tied to the one that we have in our root.

Also, as every python_tool_config was the same we only need to keep one of
 those. With that, label_flag can now references to the same python config.

* [python] Fix mypy nomenclature

Mypy is still using the old nomenclature style.

This happened because while other python tools were being refactored mypy
 was being added to the repo.

* [python] Add more `mypy` types dependencies

To ensure that mypy can type check more code we need to add type libraries.

These libraries ususally come from https://github.com/python/typeshed, and
 most are daily released.

This also add those libraries to mypy entry point dependencies.

* [python] Improve mypy configuration

With this we set mypy as no incremental mode to both our repo and our default
 aspect config. The reason is that while it does speed up check, it also makes
 mypy bugprone and therefore we are disabling it.

For our repo mypy config we are also fixing it to python 3.9. This means that,
 if we change our python version, mypy will still check against 3.9 style.

* [python] Make python aspect py38 compatible

As we aim to not provide our toolchains anymore, we, unfortunatelly, will need
 to support python 3.8. This mostly means replacing some built-ins typehints
 with typing

* [python] Improve how python aspect collects information

There was a fundamental flaw in the python aspect design. It was not
 collecting information from the whole dependency tree.

This commit fixes it by splitting the aspect into two aspects.

The `python_collect_aspect` parse the whole dependency tree and stores it at
 the `PythonCollectInfo` provider.

The already existing `python_tool_aspect` then inherits `PythonCollectInfo`
 and use that information to call our tool runners.

* [python] Change python modules names that were shadowing libs

Naming files with the same name as libraries is a bad practice and can
 lead some tools to undefined behaviour.

* [python] Add common classes that will standardize every tool output

Ideally we want two outputs, a json using quality-tools Fidings format and
 also a text output so we can output findings to the terminal. Diff outputs
 are additional.

This commit add a Findings definition that follows what quality-tools
 findings-converter expects. Also, a Findings and a FindingsJSONEncoder helps
 us to interface a list of Finding with string and json methods.
 Also, updates `black_runner`, to output their results using the updated
 Finding string.

* [python] Standardize isort output

This commit standardizes isort_runner output, which
is part of a bigger effort to standardize every
python tool output.

* [python] Add tests for isort runner

* [python] Create test for python black runner.

This commit will add test coverage to the current black runner.

* [python] Standarlize mypy output

This commit standardizes mypy_runner output, which
is part of a bigger effort to standardize every
python tool output.

* [python] Standarlize ruff output

This commit standardizes ruff_check_runner output, and
ruff_format_runner output which are part of a bigger effort
to standardize every python tool output.

* [python] Remove DeprecatedLinterFindingAsError

This commit will be removing the DeprecatedLinterFindingAsError
function from the python_tool_common, since it should not be
used by the tools anymore.

* [python] Stardardize pylint output

This commit standardizes pylint_runner output, which
is part of a bigger effort to standardize every
python tool output.

* [python] Add tests for pylint_runner

* [python] Black automated Fix

To better integrate our python aspect with our metrics tooling or even
with a normal CI usage we should enable our aspect to automatically apply fixes.
So in this commit black shall now be able to automatically fix a file
depending on the user command.

* [python] Isort Automated Fix

To better integrate our python aspect with our metrics tooling or even
with a normal CI usage we should enable our aspect to automatically apply fixes.
So in this commit isort shall now be able to automatically fix a file
depending on the user command.

* [python] Fix black runner test

This commit goal is to fix test_black_output_with_refactor test,
fixing the assert case to assert against the correct variable.

* [python] Ruff Automated Fix

To better integrate our python aspect with our metrics tooling or even
with a normal CI usage we should enable our aspect to automatically apply fixes.
So in this commit ruff check and ruff format shall now be able to automatically
fix a file depending on the user command.

* [docs] Improve our documentation

Simplify our main README.md into `Offered Tools`, `How to use BRQ`
 and `Contributing`.

 Create a `CONTRIBUTING.md`.

 Split, and slighty refactor, each specific tool section into its own
  README.md file.

* [python] Improve compatibility across multiple versions

Minor improvements that improve compatibility for multiple versions of python.

* [bazel] Adapt every target to the new bazel infra

With this we adapt a lot BUILD files (mainly labels) to the new bazel
 infrastructure.

Also, py_version_printer was upgraded to supply more information.

* [python] Add PYTHON_PATH routine to python_common_tool module

* [python] Fix mypy entry point

With the changes introduced in previous commits,
 the mypy runner wasn't working as expected due to
 it's entry point.

* [python] Move tool runners common code to python_tool_common

Currently, there is some duplicated code between the tool runners, so
this commit splits the tool runners behavior in three functions
(get_command, output_parser and exception_handler) and adds a function
that handles the interaction between them.

* [quality] Fix mypy issues on qac/clang_tidy modules

In order to fix all issues pointed by mypy, this commit adds missing
type hints and refactors code to match the expected types.
It also re-enables the qac and clang_tidy modules at the
playbook that runs the mypy check on CI.

* [python] Add py_pytest rule

* [python] Migrate test targets from py_test to py_pytest

* [pytest] Remove non stable pytest packages

While adding tests for python 3.8 and 3.12 a lot of non stable pytest packages
 failed to comply with both versions.

This aims to remove all non stable packages. If the end user wants, it is
 allowed to add more packages to our custom py_pytest rule as necessary.

Link to pytest plugins:
https://docs.pytest.org/en/stable/reference/plugin_list.html

* [python] Add proper typehints to python tools `execute_runner`

* [python] Add JSON output to every tool

This is needed to ease the a quality-tools metrics template creation for BRQ
 python tools. The new JSON file will ease file conversion while the the new
 output file names are going to ease file collection.

* [python] Improve `LinterFindingAsError` message

* [python] Adequate tests to new JSON output

* [python] Set default Finding line and column to 1

This is expected from findings-converter perspectve.

* [readme] Python module documentation

This commit will add a documentation to the python
README

* [python] Fix ruff check runner finding path

This commit will fix a bug found in the ruff check runner
where the Finding path was supposed of type Path but instead
it was of type string.

* [python] Improve coverage for python tool

This commit will add tests for mypy, ruff_check and ruff_format
runner, improving the coverage.

* [documentation] Hint at --features=refactor

* [pylint] Take Windows Paths into account when parsing output

* [pylint] Simplify Windows path handling

* [python] Add test to python_tool_common

This commit will add tests to the Python tool common.

* [quality] Ignore mypy var-annotate check

* [python] Parse user enabled features and raise error

This commit add a parse in the python aspect which will
raise an error or print a message when non compliant features are used
with python tools.

* [coverage] Add coverage to missing lines

This commit adds a new test case for both test_python_tool_common and
test_clang_tidy_runner, with the objective of reaching 100% coverage
with bazel coverage.

* [aspects] Add mnemonic to all actions.

See https://bazel.build/rules/lib/builtins/actions#run
and https://bazel.build/reference/glossary#mnemonic.

This helps to identify and analyze actions e.g.
when running on a remote cluster.

* [pytest] Remove `pytest-vcr` from default plugins

While pytest-vcr is a nice library it is causing too much noise when using our
 custom py_pytest rule from an external repo due to incompatible libraries
 resolution.

As it is not used and also not considered an essential lib, it makes sense to
 remove it from BRQ.

Users can still add VCR back using their own dependencies.

* [python] Create `pip-audit` `pybinary` entry point

* [python] Create pip-audit rule

This rule can be used to check python requirements files.

As it is an executable rule, it can be used with `bazel run //target` command.

From the start, it already supports:
- Locked and not locked requirement files;
- `index_url` option to change pip index;
- `no_deps` option to allow not locked files to be checked.

* [pycoverage] Move pycoverage from quality-tools

Move the pycoverage implementation from the quality-tools here. Since
pycoverage is a bazel integration it should rather be used by
quality-tools but provided by bazel-rules-quality.

* [pycoverage] Add entry point

Add entry point, allowing pycoverage to be called as a py_binary.

* [pycoverage] Adjust generator names

Update the names of output- and report generators in log messages and
tests according to the actual file name.

* [pycoverage] Update script exit code handling

Update the way the pycoverage generators report their exit code,
actually returning something from the main function and use sys.exit()
to report that value to the system.

* [pycoverage] Refactor report-generator

Update the report-generator implementation that identifies coverage data
files.

* [all] Rename to bazel-tools-python

Adjust identifiers to new repository.

* [infra] Add bazel infrastructure

Setup the bazel workspace, build files and dependencies.

* [tests] Add test workspace

Add a separate bazel workspace intended for testing the bazel
provided integrations.

* [tests] Add run_all_tests.sh

Add scripts to run linters, formatters and tests.

* [docu] Add user and contributor docs

Add user-facing documentation with the README.md and contributor-focused
documentation with the CONTRIBUTING.md.

* [copyright] Replace copyright headers

Replace the existing copyright header with the eclipse one.

* [buildsys] Remove starpls

Remove the starlark language server since the underlying rule is broken.

When attempting to invoke the stetup_starpls rule bazel reports
"declared output 'starpls_server_bin' was not created by genrule".

Since the starpls language server is anyhow not used by the project it
is fine to remove it.

* [buildsys] Remove score sphinx docs targets

Remove the score targets that build the sphinx documentation.

Those targets only work for python 3.12. Since the project has support
for python version from 3.8 up to 3.12 we also run tests for each of the
versions. However, the score docs targets do not allow to restrict them
to only being build for 3.12, hence they are disabled for now.

On top of that those targets take way too many resources to build even
though it doesn't actually have much content. With too many resources
meaning over an hour and up to 40GB memory.

* [security] Add a SECURITY.md file

It contains all information regarding secutiry and vulnerabilities
for this project.

* [ci] Add test github action

Add the test github action that executes the run_all_tests shell script
which in turn performs all tests and checks relevant for the project.

---------

Co-authored-by: Lucas Munaretto <lucas.lm.munaretto@bmw.de>
Co-authored-by: Vitor Sorpile Geraldo <vitor.sorpile@partner.bmw.com.br>
Co-authored-by: Yuri.Barboza <yuri.barboza@partner.bmw.com.br>
Co-authored-by: Daniel Merget <daniel.merget@bmw.de>
Co-authored-by: João Paulo Taylor Ienczak Zanette <joao.zanette@partner.bmw.com.br>
Co-authored-by: Sascha Moecker <sascha.moecker@bmw.de>

Author: 7 people

.bazelignore

@@ -0,0 +1 @@
+test

.bazelrc

@@ -1,9 +1,53 @@
-build --java_language_version=17
-build --tool_java_language_version=17
-build --java_runtime_version=remotejdk_17
-build --tool_java_runtime_version=remotejdk_17
-
-test --test_output=errors
+common --lockfile_mode=off
+common --enable_platform_specific_config
 
 common --registry=https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/
 common --registry=https://bcr.bazel.build
+
+build --incompatible_default_to_explicit_init_py
+build --verbose_failures
+
+test --test_output=errors
+
+common:use_workspace_mode --noenable_bzlmod
+common:use_workspace_mode --enable_workspace
+
+coverage --combined_report=lcov
+coverage --instrument_test_targets
+coverage --instrumentation_filter="[:]"
+
+# Python toolchain configurations
+common --flag_alias=python=@rules_python//python/config_settings:python_version
+build:python_3_8 --python=3.8
+build:python_3_9 --python=3.9
+build:python_3_10 --python=3.10
+build:python_3_11 --python=3.11
+build:python_3_12 --python=3.12
+build --config=python_3_12
+
+common --flag_alias=use_bazel_tools_python_toolchains=//bazel/toolchains/python:bazel_tools_python_toolchains
+build:use_bazel_tools_python_toolchains --use_bazel_tools_python_toolchains=True
+build:do_not_use_bazel_tools_python_toolchains --use_bazel_tools_python_toolchains=False
+build --config=use_bazel_tools_python_toolchains
+
+# Pylint configuration
+build:pylint --output_groups=python_tool_output
+build:pylint --aspects=@bazel_tools_python//quality:defs.bzl%pylint_aspect
+
+# Black configuration
+build:black --output_groups=python_tool_output
+build:black --aspects=@bazel_tools_python//quality:defs.bzl%black_aspect
+
+# Isort configuration
+build:isort --output_groups=python_tool_output
+build:isort --aspects=@bazel_tools_python//quality:defs.bzl%isort_aspect
+
+# Mypy configuration
+build:mypy --output_groups=python_tool_output
+build:mypy --aspects=@bazel_tools_python//quality:defs.bzl%mypy_aspect
+
+# Ruff configuration
+build:ruff_check --output_groups=python_tool_output
+build:ruff_check --aspects=@bazel_tools_python//quality:defs.bzl%ruff_check_aspect
+build:ruff_format --output_groups=python_tool_output
+build:ruff_format --aspects=@bazel_tools_python//quality:defs.bzl%ruff_format_aspect

.bazelversion

@@ -1 +1 @@
-8.3.0
+7.5.0

.github/workflows/tests.yml

@@ -0,0 +1,10 @@
+name: test
+on: push
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: bazelbuild/setup-bazelisk@v3
+      - run: scripts/run_all_tests.sh

.gitignore

@@ -0,0 +1,8 @@
+*.orig
+.vscode
+/out
+__pycache__
+bazel-*
+/.coverage
+/dist
+*.stamp

.gitlint

@@ -0,0 +1,34 @@
+# Available rules:
+#
+#   T1: title-max-length
+#   T2: title-trailing-whitespace
+#   T3: title-trailing-punctuation (disabled)
+#   T4: title-hard-tab
+#   T5: title-must-not-contain-word (disabled)
+#   T6: title-leading-whitespace
+#   T7: title-match-regex
+#   B1: body-max-line-length
+#   B2: body-trailing-whitespace
+#   B3: body-hard-tab
+#   B4: body-first-line-empty
+#   B5: body-min-length (disabled)
+#   B6: body-is-missing (disabled)
+#   B7: body-changed-file-mention (disabled)
+#
+# See http://jorisroovers.github.io/gitlint/rules/ for a full description.
+[general]
+ignore=T3,T5,B5,B6,B7
+# Ensure every title starts with a capital letter
+[title-match-regex]
+regex=^([A-Z]|(\[[a-z-]+\]))\w*
+
+[body-max-line-length]
+line-length=80
+
+[title-max-length]
+line-length=80
+
+# Allow lines starting with URLs to pass line length limit
+[ignore-by-body]
+regex=^https?:\/\/
+ignore=body-max-line-length

BUILD

@@ -12,19 +12,17 @@
 # *******************************************************************************
 load("@score_cr_checker//:cr_checker.bzl", "copyright_checker")
 load("@score_dash_license_checker//:dash.bzl", "dash_license_checker")
-load("@score_docs_as_code//:docs.bzl", "docs")
 load("@score_format_checker//:macros.bzl", "use_format_targets")
-load("@score_starpls_lsp//:starpls.bzl", "setup_starpls")
 load("//:project_config.bzl", "PROJECT_CONFIG")
 
-setup_starpls(
-    name = "starpls_server",
-    visibility = ["//visibility:public"],
-)
-
 copyright_checker(
     name = "copyright",
     srcs = [
+        "bazel",
+        "quality",
+        "scripts",
+        "test",
+        "third_party",
         "//:BUILD",
         "//:MODULE.bazel",
     ],
@@ -34,7 +32,7 @@ copyright_checker(
 )
 
 dash_license_checker(
-    src = "//examples:cargo_lock",
+    src = "//third_party/pip:requirement_locks",
     file_type = "",  # let it auto-detect based on project_config
     project_config = PROJECT_CONFIG,
     visibility = ["//visibility:public"],
@@ -43,6 +41,6 @@ dash_license_checker(
 # Add target for formatting checks
 use_format_targets()
 
-docs(
-    source_dir = "docs",
-)
+exports_files([
+    "pyproject.toml",
+])

CONTRIBUTING.md

@@ -0,0 +1,68 @@
+# Eclipse Safe Open Vehicle Core (SCORE)
+The [Eclipse Safe Open Vehicle Core](https://projects.eclipse.org/projects/automotive.score) project aims to develop an open-source core stack for Software Defined Vehicles (SDVs), specifically targeting embedded high-performance Electronic Control Units (ECUs).
+Please check the [documentation](https://eclipse-score.github.io) for more information.
+The source code is hosted at [GitHub](https://github.com/eclipse-score).
+
+The communication mainly takes place via the [`score-dev` mailing list](https://accounts.eclipse.org/mailing-list/score-dev) and GitHub issues & pull requests (PR). And we have a chatroom for community discussions here [Eclipse SCORE chatroom](https://chat.eclipse.org/#/room/#automotive.score:matrix.eclipse.org).
+
+Please note that for the project the [Eclipse Foundation’s Terms of Use](https://www.eclipse.org/legal/terms-of-use/) apply.
+In addition, you need to sign the [ECA](https://www.eclipse.org/legal/ECA.php) and the [DCO](https://www.eclipse.org/legal/dco/) to contribute to the project.
+
+## Contributing
+
+Want to contribute? You're welcoe and we're happy to accept your pull requests!
+
+- [Development](#development)
+  - [Updating python dependencies](#updating-python-dependencies)
+  - [Local quality check](#local-quality-check)
+
+### Getting involved
+
+#### Setup Phase
+This phase is part of the eclipse Incubation Phase and shall establish all the processes needed for a safe development of functions. Only after this phase it will be possible to contribute code to the project. As the development in this project is driven by requirements, the processes and needed infrastructure incl. tooling will be established based on non-functional Stakeholder_Requirements<!-- TODO: fill link to correct page with requirements -->. During setup phase the contributions are Bug Fixes and Improvements (both on processes and infrastructure).
+
+#### Bug Fixes and Improvements
+Improvements are adding/changing processes and infrastructure, bug fixes can be also on development work products like code.
+In case you want to fix a bug or contribute an improvement, please perform the following steps:
+1) Create a PR by using the corresponding template ([Bugfix PR template](.github/PULL_REQUEST_TEMPLATE/bug_fix.md) or [Improvement PR template](.github/PULL_REQUEST_TEMPLATE/improvement.md)). Please mark your PR as draft until it's ready for review by the Committers (see the [Eclipse Foundation Project Handbook](https://www.eclipse.org/projects/handbook/#contributing-committers) for more information on the role definitions). 
+2) Initiate content review by opening a corresponding issue for the PR when it is ready for review. Review of the PR and final merge into the project repository is in responsibility of the Committers. Use the [Bugfix Issue template](.github/ISSUE_TEMPLATE/bug_fix.md) or [Improvement Issue template](.github/ISSUE_TEMPLATE/improvement.md) for this.
+
+Please check here for our Git Commit Rules in the [Configuration_Tool_Guidelines](https://eclipse-score.github.io/score/process_description/guidelines/index.html).
+
+Please use the [Stakeholder and Tool Requirements Template](https://eclipse-score.github.io/score/process_description/templates/index.html) when defining these requirements.
+
+#### Additional Information
+Please note, that all Git commit messages must adhere the rules described in the [Eclipse Foundation Project Handbook](https://www.eclipse.org/projects/handbook/#resources-commit).
+
+Please find process descriptions here: [process description](https://eclipse-score.github.io/score/process_description/).
+
+### Development
+
+#### Updating python dependencies
+
+This repository uses Bazel `rules_python` pip integration plus a [custom pip hub implementation](bazel/rules/rules_python_pip_hub.bzl). Therefore, to add, remove or modify python pip dependencies, one should do as follows:
+
+1. Update the dependency and its version under [requirements.in](third_party/pip/requirements.in);
+2. Lock pip requirements by executing `bazel run //third_party/pip:update.sh`. This will update all `requirements_lock_3_*.txt` files under `third_party/pip`;
+3. Test the updated requirements by executing `bazel run //third_party/pip:test.sh`.
+
+After this was successfully done, it is possible to load pip packges into bazel targets. To load the pip dependency package itself (common use case), one can use our pip hub `pkg` alias.
+
+```python
+load("@bazel_tools_python_pip_hub//:loaders.bzl", "pkg")
+
+py_binary(
+    ...
+    deps = [
+        pkg("pip_package_name"),
+    ],
+    ...
+)
+```
+
+Other options are also available through other pip hub aliases, for example, the dependency data can be accessed using the `data` alias.
+
+#### Local quality check
+
+Ideally, one should verify code quality locally before pushing changes to the CI. This avoids unecessary CI jobs and can even speed up development.
+To do that, simply run [`scripts/run_all_tests.sh`](scripts/run_all_tests.sh).

MODULE.bazel

@@ -11,55 +11,121 @@
 # SPDX-License-Identifier: Apache-2.0
 # *******************************************************************************
 module(
-    name = "cpp_rust_template_repository",
-    version = "1.0",
+    name = "bazel_tools_python",
+    version = "0.1.0",
+    compatibility_level = 1,
 )
 
-bazel_dep(name = "rules_python", version = "1.4.1")
+# Checker rule for CopyRight checks/fixs
+bazel_dep(name = "score_cr_checker", version = "0.3.1", dev_dependency = True)
+bazel_dep(name = "score_python_basics", version = "0.3.4", dev_dependency = True)
+
+# Dash license checker
+bazel_dep(name = "score_dash_license_checker", version = "0.1.2", dev_dependency = True)
 
-PYTHON_VERSION = "3.12"
+# Format checker
+bazel_dep(name = "score_format_checker", version = "0.1.1", dev_dependency = True)
+bazel_dep(name = "aspect_rules_lint", version = "1.4.4", dev_dependency = True)
+bazel_dep(name = "buildifier_prebuilt", version = "8.2.0.2", dev_dependency = True)
 
-python = use_extension("@rules_python//python/extensions:python.bzl", "python")
-python.toolchain(
-    is_default = True,
-    python_version = PYTHON_VERSION,
+# docs-as-code
+bazel_dep(name = "score_docs_as_code", version = "1.0.1", dev_dependency = True)
+bazel_dep(name = "platforms", version = "0.0.11", dev_dependency = True)
+
+# Unfortunately bazel_skylib can not be dev_dependency because we use some of its libraries.
+bazel_dep(name = "bazel_skylib", version = "1.7.1")
+
+# Unfortunately rules_python can not be dev_dependency because we provide our pip hub using it.
+bazel_dep(name = "rules_python", version = "1.4.1")
+
+# We patch rules_python patch to python coverage files.
+# This enable us to select our own .coveragerc file when issuing a bazel coverage command.
+# Reference: https://github.com/bazelbuild/rules_python/blob/main/python/private/coverage.patch
+single_version_override(
+    module_name = "rules_python",
+    patches = ["@bazel_tools_python//third_party/rules_python:rules_python.patch"],
 )
-use_repo(python)
 
-# Add GoogleTest dependency
-bazel_dep(name = "googletest", version = "1.14.0")
+# Python toolchain and dependencies
 
-# Rust rules for Bazel
-bazel_dep(name = "rules_rust", version = "0.56.0")
+PYTHON_VERSIONS = [
+    "3.8",
+    "3.9",
+    "3.10",
+    "3.11",
+    "3.12",
+]
 
-# Checker rule for CopyRight checks/fixs
-bazel_dep(name = "score_cr_checker", version = "0.3.1")
-bazel_dep(name = "score_python_basics", version = "0.3.4")
-bazel_dep(name = "score_starpls_lsp", version = "0.1.0")
+# By default, one can't add `dev_dependency = True` to `python` extension from
+# `@rules_python//python/extensions:python.bzl` if python dependencies are
+# provided to the end user. To circumvent that, we rely on a conditional
+# statement by the mentioned extension, see:
+# https://github.com/bazelbuild/rules_python/blob/89d850aab819eb2dea9d6340beab1ca810dbe18d/python/private/pypi/extension.bzl#L111
 
-# C/C++ rules for Bazel
-bazel_dep(name = "rules_cc", version = "0.1.1")
+# The result is that `dev_dependency` can only be added to `python` extension
+# if every `pip_parse` has `python_interpreter` set. We set `python_interpreter`
+# to `python3` value because every hermetic toolchain has it as a symlink to
+# the real executable.
 
-# LLVM Toolchains Rules - host configuration
-bazel_dep(name = "toolchains_llvm", version = "1.2.0")
+# More info about this can be found at:
+# https://github.com/bazelbuild/rules_python/issues/1818#issuecomment-2271227487
 
-llvm = use_extension("@toolchains_llvm//toolchain/extensions:llvm.bzl", "llvm")
-llvm.toolchain(
-    cxx_standard = {"": "c++17"},
-    llvm_version = "19.1.0",
+python = use_extension("@rules_python//python/extensions:python.bzl", "python")
+
+[
+    python.toolchain(
+        configure_coverage_tool = True,
+        ignore_root_user_error = True,
+        is_default = False,
+        python_version = "{}".format(version),
+    )
+    for version in PYTHON_VERSIONS
+]
+
+# We can't use a loop for the following `use_repo` because we change the name of each toolchain.
+# buildifier: leave-alone
+use_repo(
+    python,
+    bazel_tools_python_python_3_8 = "python_3_8",
+    bazel_tools_python_python_3_9 = "python_3_9",
+    bazel_tools_python_python_3_10 = "python_3_10",
+    bazel_tools_python_python_3_11 = "python_3_11",
+    bazel_tools_python_python_3_12 = "python_3_12",
 )
-use_repo(llvm, "llvm_toolchain")
-use_repo(llvm, "llvm_toolchain_llvm")
 
-register_toolchains("@llvm_toolchain//:all")
+[
+    register_toolchains(
+        "@bazel_tools_python//bazel/toolchains/python:bazel_tools_python_python_{}_toolchain".format(version.replace(".", "_")),
+        dev_dependency = True,
+    )
+    for version in PYTHON_VERSIONS
+]
 
-# Dash license checker
-bazel_dep(name = "score_dash_license_checker", version = "0.1.2")
+register_toolchains(
+    "@bazel_tools_python//bazel/toolchains/python:py_undefined_trap",
+    dev_dependency = True,
+)
 
-# Format checker
-bazel_dep(name = "score_format_checker", version = "0.1.1")
-bazel_dep(name = "aspect_rules_lint", version = "1.4.4")
-bazel_dep(name = "buildifier_prebuilt", version = "8.2.0.2")
+register_toolchains(
+    "@bazel_tools_python//bazel/toolchains/python:do_not_use_bazel_tools_python_toolchains_trap",
+    dev_dependency = True,
+)
+
+pip = use_extension("@rules_python//python/extensions:pip.bzl", "pip")
+
+[
+    pip.parse(
+        hub_name = "bazel_tools_python_pip_{}".format(version.replace(".", "_")),
+        python_version = "{}".format(version),
+        requirements_lock = "//third_party/pip:requirements_lock_{}.txt".format(version.replace(".", "_")),
+    )
+    for version in PYTHON_VERSIONS
+]
+
+[
+    use_repo(pip, "bazel_tools_python_pip_{}".format(version.replace(".", "_")))
+    for version in PYTHON_VERSIONS
+]
 
-#docs-as-code
-bazel_dep(name = "score_docs_as_code", version = "1.0.1")
+rules_python_pip_hub = use_extension("@bazel_tools_python//third_party:extensions.bzl", "rules_python_pip_hub")
+use_repo(rules_python_pip_hub, "bazel_tools_python_pip_hub")