You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat(tools): provision tools from declared environment selections - #198
Adding or removing a tool currently means following several installation scripts and separate version files. Maintainers need one place to see which tools each environment provides, and to change that selection without rewriting installation steps.
For developers, basedpyright and pytest become available to all DevContainer users alongside pre-commit, rather than being installed into one user's home directory. They also gain Bazel targets using the same package versions. Invalid selections, missing declared dependencies and unsupported platform artifacts are reported before installation starts.
What changes
Tool selection:tools/environments.json lists the directly managed tools for the two existing container features and this repository's own setup.
Package definitions:tools/providers.json holds Python/npm packages, APT policies and special setup metadata. Native release versions and checksums stay in the existing lockfiles; Bazel reads Python definitions from the same JSON source.
Installation: each setup requests its selection with one installer call. The installer manages temporary build packages, tool setup, cleanup and required privileges, while npm retains the development user's environment. Tool-specific setup lives beside the installer.
Cleanup and fixes: remove the replaced YAML definitions and yq bootstrap, and repair config/state parent ownership without changing existing private permissions.
Existing tool versions and APT policies are retained. Distribution-selected packages still follow Ubuntu; the change does not make those packages exactly pinned.
If this PR is too large to review as one change, we could split it into the following independently usable steps. Extractions #200 and #201 are ready for review, each based directly on main and independent of the other. This PR retains the complete implementation until the extractions land.
Introduce providers.json and the Bazel adapter; replace the Python/YAML definitions and yq. Adapt existing installers to read the new metadata and expose the additional Python Bazel targets.
Shared definitions, with existing installation flows largely retained.
3. Migrate repository setup
Add environment selection, validation and native/Python/npm installation with privilege handling; migrate post_create_command.sh.
The new model is used by this repository's own setup.
4. Migrate container features
Add APT, temporary build dependencies and declared setup scripts; migrate both features, including system-wide Python tools, and remove their inline installation logic.
The complete behavior proposed by this PR.
Steps 2 → 3 → 4 build on each other. Step 1 is independent and should land before step 4. If step 4 is still too large, it can be split further by bazel-feature and s-core-local. Tests and documentation would accompany their respective changes; intermediate steps would keep one source for each version rather than introducing duplicate definitions.
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
CodeQL invokes tar -I zstd without declaring a zstd dependency, allowing validation to pass and extraction to fail on images without zstd; add "requires": ["zstd"] to its provider definition.
This PR consolidates tool selections for SCORE’s existing development environments, separating caller membership from version metadata and installation logic. It builds on the shared catalog reader without adding a new image.
Changes:
Declare complete environment selections and apply them through validated build, runtime and cleanup phases.
Consolidate provider metadata and Python pins, replacing feature YAML files and the downloaded yq parser.
Expose basedpyright and pytest system-wide and through Bazel, with updated tests and documentation.
File
Description
tools/tests/environment_test.py
Adds selection validation and installer integration coverage.
tools/tests/catalog_test.py
Updates expected Python catalog membership.
tools/README.md
Adds basedpyright and pytest to the tool table.
tools/providers.json
Defines package policies and special setup metadata.
tools/lockfiles/python_tools.bzl
Adds shared basedpyright and pytest pins.
tools/internal/sync_readme.py
Validates selections during documentation generation.
tools/internal/README.md
Documents selections, provider ownership and installation phases.
install -d applies its default mode 0755 even to existing directories. If a user has made .config or .local private with mode 0700, this ownership fix makes it traversable by other users and can expose readable configuration/state files that relied on the parent's permissions. Create missing parents with mkdir -p, then change ownership non-recursively so existing access permissions are preserved.
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
The installer omits JAVA_HOME setup for non-root APT-only OpenJDK selections and unnecessarily requires sudo and modifies system packages for native-only s-core-local installs.
AlexanderLanin
changed the title
refactor(tools): declare complete environment selections
feat(tools): provision tools from declared environment selections
Nov 4, 2026
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
The privileged provisioning lifecycle and shared Python environments require real amd64/ARM64 container validation and generated-catalog resolution through Bazel, which unavailable runtime results and mocked privilege tests cannot establish.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Adding or removing a tool currently means following several installation scripts and separate version files. Maintainers need one place to see which tools each environment provides, and to change that selection without rewriting installation steps.
For developers, basedpyright and pytest become available to all DevContainer users alongside pre-commit, rather than being installed into one user's home directory. They also gain Bazel targets using the same package versions. Invalid selections, missing declared dependencies and unsupported platform artifacts are reported before installation starts.
What changes
tools/environments.jsonlists the directly managed tools for the two existing container features and this repository's own setup.tools/providers.jsonholds Python/npm packages, APT policies and special setup metadata. Native release versions and checksums stay in the existing lockfiles; Bazel reads Python definitions from the same JSON source.Existing tool versions and APT policies are retained. Distribution-selected packages still follow Ubuntu; the change does not make those packages exactly pinned.
Part of #190; builds on #196.
Possible split if this is too large
If this PR is too large to review as one change, we could split it into the following independently usable steps. Extractions #200 and #201 are ready for review, each based directly on
mainand independent of the other. This PR retains the complete implementation until the extractions land.providers.jsonand the Bazel adapter; replace the Python/YAML definitions and yq. Adapt existing installers to read the new metadata and expose the additional Python Bazel targets.post_create_command.sh.Steps 2 → 3 → 4 build on each other. Step 1 is independent and should land before step 4. If step 4 is still too large, it can be split further by
bazel-featureands-core-local. Tests and documentation would accompany their respective changes; intermediate steps would keep one source for each version rather than introducing duplicate definitions.