Update supported Python and package versions.

* [Python] Remove EOL versions

  Remove versions that are end of life (3.8 and 3.9).

* [Python] Add new stable versions

  Add new stable versions (3.13 and 3.14).

* [pip] Update dependencies

  Updated dependencies for tools, partly to support new versions
  , to have new features available, fix pip-audit findings or to
  be in sync with other S-CORE repos.

Author: tbreckle

.bazelrc

@@ -18,11 +18,11 @@ 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:python_3_13 --python=3.13
+build:python_3_14 --python=3.14
 build --config=python_3_12
 
 common --flag_alias=use_bazel_tools_python_toolchains=//bazel/toolchains/python:bazel_tools_python_toolchains

CONTRIBUTING.md

@@ -1,4 +1,5 @@
 # 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).
@@ -19,19 +20,23 @@ Want to contribute? You're welcoe and we're happy to accept your pull requests!
 ### 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). 
+
+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/).
@@ -65,4 +70,4 @@ Other options are also available through other pip hub aliases, for example, the
 #### 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).
+To do that, simply run [`scripts/run_all_tests.sh`](scripts/run_all_tests.sh) from the repo root.

MODULE.bazel

@@ -12,7 +12,7 @@
 # *******************************************************************************
 module(
     name = "score_bazel_tools_python",
-    version = "0.1.3",
+    version = "0.1.4",
     compatibility_level = 0,
     repo_name = "bazel_tools_python",
 )
@@ -23,14 +23,16 @@ 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)
 
 # docs-as-code
-bazel_dep(name = "score_tooling", version = "1.0.4", dev_dependency = True)
+bazel_dep(name = "score_tooling", version = "1.0.5", 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")
+bazel_dep(name = "bazel_skylib", version = "1.9.0")
 
 # 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")
+# Updating it to newer than 1.6.3 currently breaks our build due to changes in rules_python
+# and we have to update score_score_tooling as well to accommodate those changes.
+bazel_dep(name = "rules_python", version = "1.6.3")
 
 # We patch rules_python patch to python coverage files.
 # This enable us to select our own .coveragerc file when issuing a bazel coverage command.
@@ -43,11 +45,11 @@ single_version_override(
 # Python toolchain and dependencies
 
 PYTHON_VERSIONS = [
-    "3.8",
-    "3.9",
     "3.10",
     "3.11",
     "3.12",
+    "3.13",
+    "3.14",
 ]
 
 # By default, one can't add `dev_dependency = True` to `python` extension from
@@ -80,11 +82,11 @@ python = use_extension("@rules_python//python/extensions:python.bzl", "python")
 # 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",
+    bazel_tools_python_python_3_13 = "python_3_13",
+    bazel_tools_python_python_3_14 = "python_3_14",
 )
 
 [

README.md

@@ -32,12 +32,12 @@ The next sections explain the steps to achieve a proper config for each Bazel de
 
 ### Requirements
 
-It's important to note that this repository does not supply python toolchains but only its pip dependencies. Therefore one must set up its own python toolchain. This repository support major python versions from `3.8` to `3.12`.
+It's important to note that this repository does not supply python toolchains but only its pip dependencies. Therefore one must set up its own python toolchain. This repository support major python versions from `3.10` to `3.14`.
 
 Additionaly, one must have the following bazel repositories already in place:
 
-- bazel_skylib >= 1.7.1
-- rules_python >= 1.4.1
+- bazel_skylib >= 1.9.0
+- rules_python >= 1.7.0
 
 ### Select python pip hub version
 

bazel/rules/rules_python_pip_hub.bzl

@@ -143,8 +143,9 @@ This is needed so this custom pip hub can select which rules python pip hub shou
 deps_to_config_map = {
             "@rules_python_pip_hub_3_10": "@your_repo_name//label/to/your:config_setting_3_10",
             "@rules_python_pip_hub_3_11": "@your_repo_name//label/to/your:config_setting_3_11",
-            "@rules_python_pip_hub_3_8": "@your_repo_name//label/to/your:config_setting_3_8",
-            "@rules_python_pip_hub_3_9": "@your_repo_name//label/to/your:config_setting_3_9",
+            "@rules_python_pip_hub_3_12": "@your_repo_name//label/to/your:config_setting_3_12",
+            "@rules_python_pip_hub_3_13": "@your_repo_name//label/to/your:config_setting_3_13",
+            "@rules_python_pip_hub_3_14": "@your_repo_name//label/to/your:config_setting_3_14",
         }
 ```
 

bazel/toolchains/python/versions.bzl

@@ -14,11 +14,11 @@
 """This module defines which python version are supported."""
 
 PYTHON_VERSIONS = [
-    "3.8",
-    "3.9",
     "3.10",
     "3.11",
     "3.12",
+    "3.13",
+    "3.14",
 ]
 
 def unsupported_python_configuration_error(custom_message):

pyproject.toml

@@ -41,7 +41,7 @@ max-line-length=120
 disallow_untyped_defs = false
 explicit_package_bases = true
 incremental = false
-python_version = "3.9"
+python_version = "3.10"
 
 [tool.pylint.messages_control]
 disable = [

quality/private/python/pycoverage/test/test_pycoverage_report_generator.py

@@ -60,4 +60,3 @@ def test_pycoverage_reporter_main(mocker, caplog, reports_file, st_size, output_
 
     if reports_file == "lcov_files_no_py_targets.tmp":
         assert "No python coverage reports found." in caplog.text
-        return

quality/private/python/tools/black_runner.py

@@ -20,17 +20,6 @@
 WOULD_REFORMAT_MSG = "would reformat"
 
 
-def _removeprefix(text: str, prefix: str) -> str:
-    """Remove a certain prefix from a a given text.
-
-    This function is supposed to add backwards compartibility with python 3.8 as
-    python versions equal or greater than 3.9 already offer this as a built in.
-    """
-    if text.startswith(prefix):
-        return text[len(prefix) :].strip()
-    return text
-
-
 def get_black_command(aspect_arguments: python_tool_common.AspectArguments) -> t.List[str]:
     """Returns the command to run a black subprocess."""
 
@@ -54,7 +43,7 @@ def black_output_parser(tool_output: python_tool_common.SubprocessInfo) -> pytho
 
     for line in tool_output.stderr.splitlines():
         if line.startswith(WOULD_REFORMAT_MSG):
-            file = _removeprefix(line, WOULD_REFORMAT_MSG)
+            file = line.removeprefix(WOULD_REFORMAT_MSG)
             findings += [
                 python_tool_common.Finding(
                     path=pathlib.Path(file),

quality/private/python/tools/python_tool_common.py

@@ -157,18 +157,6 @@ def execute_subprocess(
     )
 
 
-def _is_relative_to(path: pathlib.Path, root: pathlib.Path):
-    """Helper function that mimics what pathlib.Path.is_relative_to does.
-
-    This is needed to ensure support for python 3.8.
-    """
-    try:
-        path.relative_to(root)
-        return True
-    except ValueError:
-        return False
-
-
 @dataclasses.dataclass
 class AspectArguments:  # pylint: disable=too-many-instance-attributes
     """Class that provides a clean and verified interface between aspect and runner."""
@@ -188,7 +176,7 @@ def resolve_paths(paths: t.List[str], prepend_path: str = "") -> t.Set[pathlib.P
             resolved_paths = set()
             for path in paths:
                 try:
-                    if _is_relative_to(pathlib.Path(path), pathlib.Path(self.tool_root)):
+                    if pathlib.Path(path).is_relative_to(pathlib.Path(self.tool_root)):
                         # This is the usual branch for local files or libraries.
                         # The code go through here when path is relative to the sandbox root.
                         resolved_paths.add(pathlib.Path(path).relative_to(self.tool_root).resolve(strict=True))