Merge individual modules to a single score_tooling module

[marcmo]

originates from CR #134160

[Copilot]

Pull Request Overview

This PR consolidates multiple individual Bazel modules into a single score_tooling module, simplifying dependency management and module structure. The changes update module references, file paths, and dependencies to reflect the new unified module architecture.

Key changes include:

• Removal of individual MODULE.bazel files from separate tool directories
• Creation of a unified MODULE.bazel at the root level defining the score_tooling module
• Updates to all references from individual modules (e.g., @score_python_basics, @score_linter) to the unified @score_tooling module

Reviewed Changes

Copilot reviewed 24 out of 24 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
MODULE.bazel	Creates the unified score_tooling module with consolidated dependencies
tools/sample.sh	Updates tool references to use the unified module structure
tools/README.md	Updates documentation to reflect the new module structure
tools/MODULE.bazel	Removes individual module definition (now consolidated)
starpls/integration_tests/starpls_test.py	Updates binary path reference for the new module structure
starpls/integration_tests/BUILD	Updates load statements and visibility for unified module
starpls/MODULE.bazel	Removes individual module definition
python_basics/score_pytest/py_pytest.bzl	Updates internal references to use unified module paths
python_basics/defs.bzl	Updates load statements and data references
dash/tool/formatters/dash_format_converter.bzl	Updates tool label reference
cr_checker/cr_checker.bzl	Updates source reference to unified module
BUILD	Removes individual module definition, adds package visibility

[AlexanderLanin]

I'm afraid we need to move all bzl (and potentially BUILD) files as well. So the users do not need to use paths which are internal to tooling repository when they use one of our bzl files.

However we could also do that as a 2nd PR, just to keep them manageable??

@MaximilianSoerenPollak

[AlexanderLanin]

As this has some likelihood of not working on the first attempt I'd rather make it a pre-release.

Suggested change

	version = "1.0.0",
	version = "1.0.0-RC1",

[AlexanderLanin]

Must match major version.

Suggested change

	compatibility_level = 0,
	compatibility_level = 1,

[MaximilianSoerenPollak]

I'm afraid we need to move all bzl (and potentially BUILD) files as well. So the users do not need to use paths which are internal to tooling repository when they use one of our bzl files.

However we could also do that as a 2nd PR, just to keep them manageable??

@MaximilianSoerenPollak

I think that sounds reasonable.
Though I'm unsure how to best test this, it seems as though the pyhton_basics tests ran through green, so that's good.

[MaximilianSoerenPollak]

I don't think you should delete this?
This is needed for the integration tests and should be treated as a seperate module. Unsure if this will allow the tests to run

[AlexanderLanin]

Good point, we can look at the (few) integration tests

load("@score_tooling//python_basics:defs.bzl", "score_virtualenv")

I'd rather users have:

load("@score_tooling//python.bzl", "score_virtualenv")

[AlexanderLanin]

Discussed @AlexanderLanin and @MaximilianSoerenPollak
Let's do it in a separate follow up PR.

[MaximilianSoerenPollak]

Should not have a local path override, or am I seeing it wrong?

[MaximilianSoerenPollak]

Take a look at docs-as-code main branch to see what the right version numbers are.
As we are not using latest, but I think some slightly newer ones

[AlexanderLanin]

let's start moving in this direction