https://github.com/kunihiros/idx-python-uvx-wrapper

Tool designed to enhance Python development experience in Google IDX environments.
https://github.com/kunihiros/idx-python-uvx-wrapper

developer-tools google-idx idx nix package-management python

Last synced: 25 days ago
JSON representation

Tool designed to enhance Python development experience in Google IDX environments.

• Host: GitHub
• URL: https://github.com/kunihiros/idx-python-uvx-wrapper
• Owner: KunihiroS
• License: mit
• Created: 2025-03-16T14:49:22.000Z (7 months ago)
• Default Branch: main
• Last Pushed: 2025-03-16T15:22:02.000Z (7 months ago)
• Last Synced: 2025-03-16T15:46:58.865Z (7 months ago)
• Topics: developer-tools, google-idx, idx, nix, package-management, python
• Language: Nix
• Homepage: https://developers.google.com/idx
• Size: 0 Bytes
• Stars: 0
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

          
# IDX-Python-UVX-Wrapper

## Project Overview

IDX-Python-UVX-Wrapper is a powerful tool designed to overcome the unique constraints of Python development in Google IDX environments. By providing a custom wrapper, this tool enables seamless package management and development workflows that are otherwise hindered by IDX's strict environment isolation and session persistence challenges. It effectively bridges the gap between standard Python tools (like pip) and the limitations imposed by IDX, allowing developers to install and manage packages efficiently.

For an in-depth analysis, please refer to the [Analistic Report](UniquityReporter_analysis_KunihiroS_IDX-Python-UVX-Wrapper_20250317000114.md).

## Note

💡 This is not the official `uvx` tool. This project aims to overcome the limitations of the IDX environment.  The name "uvx" is used for this wrapper to make its function easier to understand. Please note that this project is in the early research stage, and there may be misunderstandings or knowledge gaps regarding the technical background and implementation details.

## Working Sample

[sample.dev.nix](sample.dev.nix)

## 🔍 Problem Statement

Python development in Google IDX environments faces several significant challenges:

1. **Environment Isolation Constraints**: IDX strictly separates build processes from user sessions, causing standard Python virtual environment tools (like venv) to malfunction.

2. **Outdated Nix Packages**: The available `pkgs.uv` in IDX's `dev.nix` is an older version (0.1.45 at the time of author verification), limiting access to the latest features and improvements.

3. **Session Persistence Challenges**: Environmental changes are not preserved across IDX session restarts, leading to a loss of installed packages and configurations.

## 🆚 Comparison: `pkgs.python311Packages.pip` vs. `uvx`

While `pkgs.python311Packages.pip` is available in IDX environments, it faces significant limitations due to the managed environment constraints. Here are the key differences and why `uvx` stands out:

### `pkgs.python311Packages.pip`

- **Environment Isolation**: Direct usage of `pip install` and `pip install --user` is restricted, leading to errors such as `externally-managed-environment`.

- **Package Installation**: Attempts to install packages with `pip` fail due to immutability of the `/nix/store` filesystem.

- **Session Persistence**: Installed packages and environment changes do not persist across session restarts, causing loss of configurations and dependencies.

### `uvx` Wrapper

- **Environment Isolation Handling**: Uses temporary directories and sets `PYTHONPATH` to manage and isolate packages, bypassing the restrictions of the `/nix/store` filesystem.

- **Package Installation Success**: Successfully installs packages in temporary directories, allowing seamless usage within the session.

- **Session Persistence Management**: Implements mechanisms to maintain persistent package directories, ensuring that essential configurations and dependencies are preserved across session restarts.

By adopting `uvx`, developers can seamlessly manage Python packages and maintain a consistent development environment in IDX, overcoming the inherent limitations of `pkgs.python311Packages.pip`.

## 🚀 Future Development Possibilities

The design principles and approaches used in the `uvx` wrapper can be extended to develop other useful functionalities in the IDX environment. Here are a few potential enhancements:

### 1. Project-specific Virtual Environment Management

Implementing a project-specific virtual environment management system that isolates dependencies per project can be highly beneficial. This can be achieved by:

- Introducing a `.uvx-project` configuration file at the project root.

- Creating a package directory for each project at `~/.uvx/projects//`.

- Adding project-specific environment variables.

- Implementing a `uvx venv` subcommand for virtual environment management.

### 2. Package Cache Optimization

To optimize package installation times, a caching mechanism can be introduced. This can involve:

- Building a local cache of wheel packages at `~/.uvx/cache/`.

- Implementing fast search through package metadata indexing.

- Developing delta installation logic to reuse existing packages.

- Adding cache integrity verification mechanisms.

### 3. Dependency Analysis Tool

A tool to visualize and optimize project dependencies can enhance development efficiency. Key features could include:

- Dependency graph construction and visualization.

- Detection of redundant dependencies and version conflicts.

- Automatic dependency optimization suggestions.

### 4. Multiple Python Version Support

Supporting multiple Python versions simultaneously can enhance flexibility. This can be achieved by:

- Adding a `--python` flag to specify the desired Python version.

- Implementing a version-specific package directory structure.

- Utilizing symbolic links for dynamic version switching.

- Verifying package compatibility for different Python versions.

### 5. Automatic Update Functionality

Automating regular package updates and security checks can improve the development environment's safety and currency. This can involve:

- Implementing a `uvx update` subcommand.

- Developing an API client to retrieve package update information.

- Integrating with a security vulnerability database.

- Adding configurable update policies and rollback functionality.

By leveraging these design principles and approaches, the IDX-Python-UVX-Wrapper can be extended to provide a robust and flexible development environment that meets the unique constraints of the IDX platform.

## 🔬 Technical Characteristics and Constraints of IDX Environment

The IDX environment is designed based on the principles of Immutable Infrastructure, resulting in fundamentally different operational characteristics compared to traditional development environments.

### Separation of Build and Execution Phases

```

┌────────────────────────────┐

│    Build Phase             │

│  ┌──────────────────────┐  │

│  │  dev.nix Evaluation  │  │

│  │  Package Installation│  │

│  │  Environment Variable│  │

│  │  Runtime Image      │  │

│  └──────────────────────┘  │

└───────────┬────────────────┘

            ↓

┌────────────────────────────┐

│    Execution Phase         │

│  ┌──────────────────────┐  │

│  │  Container Launch    │  │

│  │  User Session Start  │  │

│  │  User Operations     │  │

│  └──────────────────────┘  │

└────────────────────────────┘

```

This separation is based on Nix's principles of "purity" and "reproducibility," ensuring that environment construction is declarative and deterministic.

https://en.wikipedia.org/wiki/Nix_(package_manager)

### Filesystem and Context Constraints

Packages evaluated during the build phase are stored in paths like `/nix/store/[hash]-[package-name]`, which are immutable because the path is hashed based on content. In the execution phase (user session):

1. Access to packages in `/nix/store` is possible

2. Writing new files to `/nix/store` is impossible

3. Users can only write to specific directories like `$HOME`

### Environment Variable and PATH Inheritance Mechanism

Environment variables set during the build phase are inherited by the execution phase but remain **statically fixed**:

```bash

# Typical environment variables set during build phase

PATH=/nix/store/[hash]-python3-3.11.10/bin:/nix/store/[hash]-pipx-1.4.3/bin:...

PYTHONPATH=/nix/store/[hash]-python3-packages/lib/python3.11/site-packages

```

Changes made by users during runtime through commands like `pip install` are not automatically reflected in environment variables.

### Virtual Environment (venv) Dysfunction

In normal Python development, `venv` is used to create isolated environments, but in IDX environments, the following issues arise:

1. Environment variables set by the `activate` script do not persist between sessions

2. Symbolic links to `site-packages` directories may not function properly

3. Integration with IDX's build process is challenging

## 🎯 Project Objectives

1. Streamline Python package management in IDX environments

2. Maintain consistent development environments across sessions

3. Implement key `uv`/`pip` functionalities despite environmental constraints

4. Allow developers to work without being conscious of environmental details

## 🛠️ Technical Approach

This project employs the following technical approaches to address the challenges:

### 1. Hierarchical Package Management Architecture

The package management is designed with a 3-tier structure to accommodate different persistence requirements:

```

┌─────────────────────────────────────────┐

│  1. Session-local Packages              │ ← Highest Priority

│     /tmp/uvx-packages-$                │    (Session-only)

├─────────────────────────────────────────┤

│  2. Persistent Package Directory        │ ← Medium Priority

│     ~/.uvx/packages                    │    (Shared across sessions)

├─────────────────────────────────────────┤

│  3. User Site Packages                  │ ← Low Priority

│     ~/.local/lib/python3.11/site-packages│   (Standard location)

└─────────────────────────────────────────┘

```

This hierarchical structure applies the "Defense in Depth" design pattern, offering these technical benefits:

1. **Performance Optimization**: Most frequently accessed packages are placed in temporary directories closer to memory

2. **Fault Tolerance Enhancement**: If one layer fails, other layers function as backups

3. **Context Isolation Respect**: Respects IDX's separation model while enabling necessary coordination

This design resolves the contradictory requirements of session isolation and persistence.

### 2. Argument Classification Processing Model

The command-line argument processing adopts a "classification processing pattern" to effectively handle complex argument structures:

```bash

# State transition-based argument classification

while [ $# -gt 0 ]; do

  if [ "$1" = "--user" ]; then

    HAS_USER_FLAG=1         # State flag change

  elif [ $HAS_USER_FLAG -eq 1 ]; then

    # Context-dependent argument processing

    # Arguments after --user flag are treated as user packages

    if [ -z "$USER_PKGS" ]; then

      USER_PKGS="$1"         # Initial value setting

    else

      USER_PKGS="$USER_PKGS $1" # Value accumulation

    fi

  else

    # Default context argument processing

    # Other arguments treated as regular packages/options

    if [ -z "$REGULAR_PKGS" ]; then

      REGULAR_PKGS="$1"      # Initial value setting

    else

      REGULAR_PKGS="$REGULAR_PKGS $1" # Value accumulation

    fi

  fi

  shift                     # Iteration advancement

done

```

This design is based on the concept of "Finite State Automaton," treating argument processing as clearly defined state transitions:

1. **Initial State**: Normal argument mode

2. **State Transition**: State change upon `--user` flag detection

3. **State-Dependent Processing**: Different argument processing logic based on current state

4. **State Maintenance**: State maintained through flags and accumulated values

This approach enables the implementation of complex processing dependent on the order and combination of arguments as a clear logical structure.

### 3. Command Dispatch Pattern

The subcommand processing adopts a "Command Dispatch Pattern" to ensure extensibility:

```bash

case "$command" in

  python)

    # Python command processing

    # - Environment variable setting

    # - Argument processing

    # - Command execution

    ;;

  pip)

    # pip command processing

    # - Flag analysis

    # - Package management

    # - Result processing

    ;;

  *)

    # Unknown command processing

    # - Error handling

    # - Help display

    ;;

esac

```

This pattern applies the "Command Pattern" and "Strategy Pattern" from object-oriented design to shell scripting. This approach offers these technical advantages:

1. **Separation of Concerns**: Processing logic for each command is clearly separated, minimizing interdependencies

2. **Extensibility**: Adding new commands does not impact existing code

3. **Maintainability**: Individual command processing logic can be tested and updated independently

This dispatch mechanism forms an important design foundation for future functional extensions (e.g., `uvx venv`, `uvx update`).

### 4. Nix Shell Script Integration

Implemented as a shell script fully integrated into the IDX `dev.nix` environment, appropriately managing environment variables and PATH:

```nix

(pkgs.writeShellScriptBin "uvx" ''

  #!/usr/bin/env bash

  

  # Environment variable and directory setup

  PERSISTENT_PKG_DIR="$HOME/.uvx/packages"

  mkdir -p "$PERSISTENT_PKG_DIR"

  

  # PATH extension

  export PATH="$HOME/.local/bin:$PATH"

  

  # Temporary directory setup and automatic cleanup

  TEMP_PKG_DIR="/tmp/uvx-packages-$"

  mkdir -p "$TEMP_PKG_DIR"

  trap 'rm -rf "$TEMP_PKG_DIR"' EXIT

  

  # Command processing logic

  # ...

'')

```

This implementation is based on the following technical principles:

1. **Declarative Configuration**: Tool configuration is declaratively defined in line with Nix's philosophy

2. **Self-contained Package**: Explicitly includes dependencies, ensuring execution independent of environment

3. **Atomic Operations**: Script execution is designed as a series of atomic operations, preventing failures in intermediate states

4. **Resource Management**: Proper resource cleanup using `trap` prevents resource leaks

This design functions appropriately within IDX's strict filesystem constraints, bridging the build environment and user environment.

## 💡 Features and Design Patterns

### 1. Environment Constraint Encapsulation - Adapter Pattern

This tool applies the "Adapter Pattern" to completely encapsulate the complex constraints of the IDX environment:

```

┌────────────────────┐    ┌────────────────┐    ┌────────────────┐

│                    │    │                │    │                │

│ Standard Python    │    │     uvx        │    │  IDX Environment│

│ Development Workflow│━━━▶│   Adapter     │━━━▶│  Constraints   │

│ (Client)           │    │ (Interface)    │    │ (Adaptee)      │

│                    │    │                │    │                │

└────────────────────┘    └────────────────┘    └────────────────┘

```

This adapter allows developers to maintain standard workflows without being conscious of environmental details.

### 2. Multi-layered Package Management - Composite Pattern

The 3-tier structure of session-local packages, persistent packages, and user site packages is a design that combines the "Composite Pattern" and "Chain of Responsibility":

```

┌─────────────────────┐

│ Package Request     │

└──────────┬──────────┘

           ▼

┌──────────────────────┐     Failure   ┌─────────────────────┐     Failure   ┌────────────────────────┐

│ Session-local Packages│────────────▶│ Persistent Packages │────────────▶│ User Site Packages     │

└──────────────────────┘             └─────────────────────┘             └────────────────────────┘

```

This approach enables reliable package management even under environmental constraints.

### 3. Self-healing Package Synchronization - Observer Pattern

The automatic synchronization mechanism between temporary and persistent directories is a type of "Observer Pattern":

```

┌───────────────────┐                  ┌───────────────────┐

│ Temporary Directory│                  │ Persistent Directory│

│ (Subject)        │─────Change Notification─▶│ (Observer)       │

└───────────────────┘                  └───────────────────┘

```

This implementation:

1. Generates an event upon successful package installation

2. The event handler executes the copy process to the persistent directory

3. Ensures package state is maintained after session restart

### 4. Nested State Management - State Pattern

The state transition in command-line argument processing is an application of the "State Pattern":

```

┌───────────────┐     --user     ┌───────────────┐

│ Normal Argument│───────────────▶│ User Argument │

│ Mode (State A) │               │ Mode (State B)│

└───────────────┘               └───────────────┘

```

This state transition logic enables accurate command construction according to context.

## 📊 Performance and Effect

- **Package Installation Time**: Speed equivalent to standard `pip install`

- **Environment Consistency**: Development environment maintained after session restart

- **Development Experience**: Standard Python development workflow realized even in IDX environments

## 🚀 Usage

### Basic Usage

```bash

# Run Python scripts

uvx python script.py

# Execute Python code directly

uvx python -c 'print("Hello, World!")'

# Install packages

uvx pip install numpy pandas matplotlib

# Install packages permanently to user environment

uvx pip install --user scipy

# Check installed packages

uvx pip list

```

### Integration with dev.nix

```nix

{ pkgs, ... }: {

  channel = "stable-24.05";

  

  packages = [

    pkgs.python311

    pkgs.pipx

    

    # uvx command integration

    (pkgs.writeShellScriptBin "uvx" ''

      #!/usr/bin/env bash

      # Script body (retrieved from repository)

    '')

  ];

  

  # Other IDX settings

}

```

## 🔮 Future Development Possibilities and Architectural Extensions

The design of this project considers extensibility, and the following directional functional extensions are conceivable. For each extension point, architectural considerations and implementation approaches are explained.

### 1. Project-specific Virtual Environment Management

To realize environments isolated for each project, the following architectural extensions are possible:

```

┌─────────────────────────────────────┐

│ Project Environment Management     │

│ (Extension)                         │

│                                     │

│  ┌─────────────────┐ ┌────────────┐ │

│  │ Environment     │ │ Dependency │ │

│  │ Metadata        │ │ Management │ │

│  │ (.uvx-project)  │ │            │ │

│  └─────────────────┘ └────────────┘ │

│                                     │

│  ┌─────────────────┐ ┌────────────┐ │

│  │ Project-specific│ │ Environment│ │

│  │ Package Directory│ │ Isolation │ │

│  │                 │ │ Mechanism  │ │

│  └─────────────────┘ └────────────┘ │

└─────────────────────────────────────┘

```

Implementation Approach:

1. Introduce `.uvx-project` configuration file at project root

2. Create package directory for each project at `~/.uvx/projects//`

3. Add project-specific environment variable setting functionality

4. Implement `uvx venv` subcommand for virtual environment management

This enables the important Python development paradigm of "project-level environment isolation" even under IDX constraints.

### 2. Package Cache Optimization

Extensions to optimize cache mechanisms are possible for accelerating package installation:

```

┌─────────────────────────────────────┐

│ Cache Optimization System          │

│ (Extension)                         │

│                                     │

│  ┌─────────────────┐ ┌────────────┐ │

│  │ Wheel Cache     │ │ Metadata   │ │

│  │                 │ │ Index      │ │

│  └─────────────────┘ └────────────┘ │

│                                     │

│  ┌─────────────────┐ ┌────────────┐ │

│  │ Delta Install   │ │ Cache      │ │

│  │                 │ │ Verification│ │

│  └─────────────────┘ └────────────┘ │

└─────────────────────────────────────┘

```

Implementation Approach:

1. Build local cache of wheel packages at `~/.uvx/cache/`

2. Fast search through package metadata indexing

3. Implement delta installation logic (reuse existing packages)

4. Add cache integrity verification mechanism

This extension significantly accelerates repetitive installation operations and reduces network usage.

### 3. Dependency Analysis Tool

Adding tools to visualize and optimize project dependencies can enhance development efficiency:

```

┌─────────────────────────────────────┐

│ Dependency Analysis System         │

│ (Extension)                         │

│                                     │

│  ┌─────────────────┐ ┌────────────┐ │

│  │ Dependency Graph│ │ Redundant  │ │

│  │ Generation      │ │ Dependency │ │

│  │                 │ │ Detection  │ │

│  └─────────────────┘ └────────────┘ │

│                                     │

│  ┌─────────────────┐ ┌────────────┐ │

│  │ Version Conflict│ │ Optimization│ │

│  │ Resolution      │ │ Suggestion │ │

│  └─────────────────┘ └────────────┘ │

└─────────────────────────────────────┘

```

Implementation Approach:

1. Add `uvx deps` subcommand

2. Implement dependency graph construction and visualization functionality

3. Develop algorithms to detect unnecessary dependencies and conflicts

4. Automatic dependency optimization suggestion feature

This extension facilitates the management of complex Python project dependencies and enables early detection of potential issues.

### 4. Multiple Python Version Support

Extensions to simultaneously support different Python versions significantly enhance flexibility:

```

┌─────────────────────────────────────┐

│ Multi-Python Version Management    │

│ (Extension)                         │

│                                     │

│  ┌─────────────────┐ ┌────────────┐ │

│  │ Version Switch  │ │ Symbolic   │ │

│  │                 │ │ Link       │ │

│  │                 │ │ Mechanism  │ │

│  └─────────────────┘ └────────────┘ │

│                                     │

│  ┌─────────────────┐ ┌────────────┐ │

│  │ Version-specific│ │ Compatibility│ │

│  │ Package Management│ │ Verification│ │

│  │                 │ │            │ │

│  └─────────────────┘ └────────────┘ │

└─────────────────────────────────────┘

```

Implementation Approach:

1. Add version specification functionality with `--python` flag

2. Implement version-specific package directory structure

3. Dynamic version switching mechanism utilizing symbolic links

4. Add package compatibility verification functionality

This extension enables the parallel use of multiple Python versions even within the IDX environment.

### 5. Automatic Update Functionality

Extensions to automate regular package updates and security checks are conceivable:

```

┌─────────────────────────────────────┐

│ Automatic Update System            │

│ (Extension)                         │

│                                     │

│  ┌─────────────────┐ ┌────────────┐ │

│  │ Update Detection│ │ Security   │ │

│  │ Mechanism       │ │ Scan       │ │

│  │                 │ │            │ │

│  └─────────────────┘ └────────────┘ │

│                                     │

│  ┌─────────────────┐ ┌────────────┐ │

│  │ Rollback        │ │ Update     │ │

│  │ Mechanism       │ │ Policy     │ │

│  │                 │ │ Configuration│ │

│  └─────────────────┘ └────────────┘ │

└─────────────────────────────────────┘

```

Implementation Approach:

1. Implement `uvx update` subcommand

2. Develop API client to retrieve package update information

3. Integration with security vulnerability database

4. Add configurable update policies and rollback functionality

This extension automates the process of maintaining safety and currency in the development environment.

## 🔧 Testing Method

The functionality can be verified with the following commands:

```bash

# Version check

uvx --version

# Basic package installation

uvx pip install numpy

# Multiple package installation

uvx pip install pandas matplotlib

# Installation to user environment

uvx pip install --user scipy

# Verification of installed packages

uvx python -c 'import numpy; print(f"NumPy version: {numpy.__version__}")'

```

## 📚 Lessons and Insights

The main lessons derived from this project are as follows:

### 1. Adaptive Design for Environmental Constraints - Importance of Root Cause Analysis

To address specific environmental constraints, it's important to understand the root causes rather than the surface symptoms:

```

【Problem Hierarchy Structure】

Level 1: Phenomenon → "uvx command doesn't work"

Level 2: Direct Cause → "Only old uv package (0.1.45) available"

Level 3: Technical Constraint → "Immutable package structure in IDX's nix environment"

Level 4: Architectural Constraint → "Separation design of build phase and execution phase"

Level 5: Design Philosophy → "Immutable Infrastructure principle"

```

This hierarchical understanding enabled the design of solutions addressing the fundamental constraints (environment separation architecture) rather than the surface problem (old uv package).

### 2. Argument Processing Robustness - Application of State Machine Design

Command-line argument processing requires complex state management despite appearing simple on the surface:

```

【Argument Processing Pattern Comparison】

┌──────────────────┬───────────────────┬────────────────────┐

│ Pattern          │ Advantages        │ Disadvantages      │

├──────────────────┼───────────────────┼────────────────────┤

│ Sequential       │ Simple            │ Difficult to       │

│ Processing       │ implementation    │ maintain state     │

│                  │ Easy to understand│ Weak with complex  │

│                  │                   │ arguments          │

├──────────────────┼───────────────────┼────────────────────┤

│ Classification   │ Clear separation  │ Slightly complex   │

│ Processing       │ of responsibilities│ initial           │

│ (Adopted)        │ High extensibility│ implementation     │

│                  │                   │ Requires state     │

│                  │                   │ management         │

├──────────────────┼───────────────────┼────────────────────┤

│ Tree Processing  │ Strong with       │ Very complex       │

│                  │ hierarchical      │ implementation     │

│                  │ arguments         │ Large overhead     │

│                  │ Advanced          │                    │

│                  │ verification      │                    │

│                  │ possible          │                    │

└──────────────────┴───────────────────┴────────────────────┘

```

This project adopted the intermediate "Classification Processing Pattern," achieving a balance between simplicity and robustness.

### 3. Multi-layered Defense Approach - Effectiveness of Redundancy Design

Multiple defense layers are effective in ensuring stability in environments with different constraints:

```

【Failure Scenario Analysis】

1. Temporary directory loss at session end

   → Persistent directory functions as backup

2. Failure to copy to persistent directory

   → Reinstallation from temporary directory possible in next session

3. User site package corruption

   → Temporary/persistent directories have priority, minimizing impact

```

This "Deliberate Redundancy" design eliminates Single Points of Failure, enhancing the overall robustness of the system.

### 4. Importance of Boundaries in System Design

Clear boundary setting is important when designing complex systems:

```

【Boundary Design in This Project】

1. Physical Boundaries: Temporary directory, persistent directory, site packages

2. Logical Boundaries: Python command processing, pip command processing, help processing

3. Interface Boundaries: Shell commands, environment variable settings, filesystem operations

```

Clear boundary setting allows each component to evolve independently, enhancing the overall extensibility and maintainability.

## 📄 License

MIT License

## 🤝 How to Contribute

1. Fork this repository

2. Create a new branch (`git checkout -b feature/amazing-feature`)

3. Commit your changes (`git commit -m 'Add some amazing feature'`)

4. Push to the branch (`git push origin feature/amazing-feature`)

5. Create a Pull Request

## 🙏 Acknowledgments

This project was inspired by Google IDX team's excellent development environment and tools. It is also based on the outstanding tools and knowledge from the Nix ecosystem and Python community.