PDM is a modern Python package and dependency manager that implements the latest PEP standards (517, 518, 621, 582, 735, 751). It provides a comprehensive CLI tool for managing project dependencies, virtual environments, Python interpreters, and publishing packages. The architecture is modular: a core `Project` class orchestrates configuration, lockfile management, environment abstraction, and workspace (monorepo) support. Dependency resolution is handled by either a built-in resolvelib-based resolver or an optional uv backend, with a pluggable installer/synchronizer layer. The tool supports multiple lockfile formats (pdm.lock, pylock.toml), export/import to various formats (requirements.txt, Pipfile, Poetry, Flit, setup.py), and a rich plugin system via entry points and signals. It also includes build backend integration, PEP 582 local package directories, and shell completions. The codebase is well-structured with clear separation of concerns, extensive test coverage, and active maintenance.
Homebrew is a mature, cross-platform package manager for macOS and Linux implemented in Ruby. It provides command-line tools for installing, updating, and managing software packages (formulae) and GUI applications (casks). The architecture features a modular design with clear separation of concerns, including command patterns, strategy patterns for download/unpack operations, OS abstraction layers, and DSLs for package definitions. Key entry points include the brew executable, cmd/ directory for user commands, and dev-cmd/ for developer tools. The system handles dependency resolution, binary package distribution (bottles), tap repositories, Brewfile dependency management, analytics tracking, and service management. External dependencies include system tools (git, curl, compilers), Ruby runtime, and various external services for version checking and vulnerability scanning.
sbt is a build tool for Scala, Java, and other JVM languages. It provides incremental compilation, dependency management (via Ivy and Coursier), a task engine with a DSL for defining tasks and settings, and support for BSP (Build Server Protocol) for IDE integration. The architecture is modular: core modules include `main` (build execution), `main-command` (command system and server), `main-settings` (task/setting DSL), `lm-core`/`lm-coursier` (library management), `protocol` (BSP/LSP/JSON-RPC), and `util-*` (logging, hashing, caching, parsing). Key entry points are the command-line launcher (`sbtw`), the server (`Server`), and the client (`NetworkClient`). Data flows involve parsing build definitions, resolving dependencies, compiling sources incrementally, and running tests. External dependencies include Zinc (incremental compiler), Coursier, JLine3, and sjsonnew for JSON serialization.
Pipenv is a Python dependency management CLI tool that unifies dependency resolution, virtualenv management, and environment setup. It provides commands like install, lock, sync, shell, and run, operating on Pipfile/Pipfile.lock files. The architecture is a monolithic Python application built around a custom resolver subprocess with a typed JSON protocol, a pluggable resolver backend system (currently defaulting to a heavily patched and vendored copy of pip), and a set of utility modules for lockfile handling, source management, virtualenv discovery, and credential security. It heavily vendors pip, rich, urllib3, packaging, and other libraries to ensure consistent behavior across environments. Pipenv also includes experimental support for a new pylock.toml format and a pure-Python PEP 691 client, showcasing modern packaging ecosystem integration. The codebase is well-structured with clear separation of CLI, routines, utilities, and resolver components, and has an extensive unit and integration test suite. While some modules are tightly coupled to internal state, several components (atomic file writes, parallel fetching, disk caching, credential redaction) are well-isolated and could be reused in other Python tooling projects.
This repository provides a comprehensive shell script (`install-php-extensions`) that automates the installation of PHP extensions in official Docker PHP images (both Alpine and Debian variants). The script handles dependency resolution, version pinning, source-based compilation, and cleanup of build artifacts. It supports over 160 extensions, including those bundled with PHP source, PECL packages, and proprietary agents (New Relic, Blackfire, Datadog). The repo also includes a structured compatibility database (`data/supported-extensions`, `data/dependencies.json`) that tracks extension-to-PHP-version mappings, library version pins, and detection mechanisms. CI workflows automatically test extension installation across a large matrix of PHP versions and distros, and a daily update checker monitors new releases and runs tests, notifying maintainers via Telegram if issues arise. The project is a developer utility, not a service or library, and is distributed as a Docker image and standalone script.
Boundary is an Elixir library that enables developers to define and enforce architectural boundaries within their applications. By specifying which modules belong to which boundaries and what dependencies are allowed between them, teams can prevent unwanted coupling and maintain clean architectural layers (e.g., keeping the web layer from directly accessing database modules). The library works as a mix compiler that hooks into Elixir's compilation process using compilation tracers. During compilation, it records all module/function calls, then validates these calls against the defined boundary rules. Violations are reported as compiler warnings, allowing developers to identify and fix dependency issues early in the development process. Beyond enforcement, Boundary provides a suite of mix tasks for visualizing and analyzing dependencies. These include tools to generate dependency graphs at both the module and function level, identify external dependencies, and create documentation groupings. The implementation demonstrates advanced Elixir techniques including effective use of GenServer for state management, ETS for efficient data storage during compilation, and clever tricks for incremental analysis to maintain performance in large projects.
box is an R package that provides a modern, modular module system for organizing R code into hierarchical, composable, and reusable modules. It replaces the traditional `library` and `require` functions with a declarative, explicit import syntax (`box::use`) that supports selective name attachment, aliasing, and scoped imports. The system handles both packages and local R scripts as first-class modules, supports S3 method registration, cyclic imports, interactive help, and module lifecycle hooks (`.on_load`, `.on_unload`). The architecture is built on custom environment manipulation, a PEG-like specification parser, a caching layer for loaded modules, and a small C extension for performance-critical operations. The codebase is well-structured, extensively tested, and demonstrates advanced use of R's environment and S3 dispatch mechanisms.
This repository is the official build infrastructure for .NET Docker images. It generates, tests, and publishes Docker images for .NET SDK, runtime, ASP.NET Core, and related tools (monitor, Aspire Dashboard) across multiple operating systems (Alpine, Ubuntu, Debian, Azure Linux, Windows) and architectures (amd64, arm64v8, arm32v7). The core of the system is a template engine (Cottle) that produces Dockerfiles from parameterized templates, combined with a comprehensive test suite that validates generated artifacts against approved baselines and verifies image behavior at runtime. The repository also includes a sophisticated dependency update tool (C# CLI) that automatically updates .NET versions, PowerShell, Syft, Chisel, and other dependencies by fetching release information from GitHub, Azure DevOps, and internal build services, then creating pull requests against the repository. The CI/CD pipeline (Azure Pipelines) orchestrates building, testing, signing, and publishing images to Microsoft Container Registry and other registries. Sample applications demonstrate common .NET deployment patterns in Docker and Kubernetes. Architecture: The system is organized into several layers: (1) Dockerfile templates in `eng/dockerfile-templates/` that generate the actual Dockerfiles in `src/`; (2) a dependency update tool in `eng/update-dependencies/` that automates version bumps; (3) a test suite in `tests/` that validates generated artifacts and image behavior; (4) pipeline definitions in `eng/pipelines/` and `eng/docker-tools/` that orchestrate CI/CD; and (5) sample applications in `samples/` for testing and documentation. Key entry points include the update-dependencies CLI (`Program.cs`), the test runner (`run-tests.ps1`), and the pipeline YAML files. External dependencies include Azure DevOps (pipelines, blob storage), GitHub (releases), and various package registries. Data flows: Version metadata flows from `manifest.json` and `manifest.versions.json` into the template engine to generate Dockerfiles with correct version numbers and checksums. The update-dependencies tool fetches new versions from external sources (GitHub releases, Azure DevOps pipelines, BAR service) and updates the manifest files, then creates pull requests. The test suite reads the manifest to build a test matrix, builds Docker images from the generated Dockerfiles, and runs validation tests (package lists, environment variables, HTTP endpoints).
This repository provides a generic-based dependency injection framework for Go, called 'kod' (Killer Of Dependency), along with a CLI tool for code generation, component registration, and dependency graph validation. It features a rich interceptor chain for cross-cutting concerns (retry, validation, tracing, rate limiting, circuit breakers, etc.), and includes a comprehensive test suite and examples. The codebase also incorporates an extensive set of AI agent skills for software development workflows (grilling, code review, TDD, domain modeling) from the mattpocock/skills ecosystem. The primary value is the DI framework that leverages Go generics to provide compile-time safety for component wiring, with generated boilerplate code. The architecture is modular with clear separation of core, interceptors, internal utilities, and tests. It is actively maintained with modern Go features.
Package Control is the official package manager for Sublime Text, handling installation, upgrade, and removal of packages and libraries. It is implemented as a Sublime Text plugin with a command-based interface and deep integration with the editor's API. The system fetches package metadata from multiple sources (GitHub, GitLab, Bitbucket, PyPI, and custom JSON channels/repositories) using a pluggable downloader architecture that supports caching, rate limiting, proxy authentication, and SSL validation. It includes a full PEP 440 version parser and specifier engine for dependency resolution, and manages package lifecycle through background threads to keep the editor responsive. The codebase is well-structured with extensive unit tests, but is tightly coupled to the Sublime Text runtime environment, limiting direct reuse outside of ST plugins.
This is the official Heroku buildpack for Python applications. It implements the standard buildpack lifecycle (detect, compile, release, report) to install a Python runtime and manage dependencies using pip, pipenv, poetry, or uv. It handles Django collectstatic, NLTK corpora downloads, user-supplied hooks (pre/post compile), and Heroku CI. The codebase is a collection of modular shell scripts with a consistent library pattern, extensive integration tests via Hatchet/RSpec, and support for multiple Heroku stacks. It is actively maintained, with Dependabot for dependency updates and CI workflows for every commit. The architecture is straightforward: each lifecycle phase is a standalone script that sources reusable libraries from lib/. While the core logic is specific to Heroku's platform, the library functions (e.g., caching, version resolution, build data reporting) demonstrate good shell scripting practices and could be adapted for other build systems.
Safety is a commercial CLI tool for software supply chain security, primarily scanning Python (and limited npm) dependencies for known vulnerabilities. It operates as a multi-command CLI built with Click and Typer, offering commands such as `scan`, `check`, `auth`, `firewall`, `init`, and `codebase`. The architecture is modular: a core scanning engine (`safety/scan/`) discovers dependency files (requirements.txt, pyproject.toml, Pipfile.lock, etc.), resolves packages, and matches them against a proprietary vulnerability database fetched from the Safety platform. Results are formatted via a pluggable formatter system (JSON, HTML, screen, text, SPDX) and can be uploaded to the platform for reporting. The tool also includes a firewall mode that intercepts pip/poetry/uv/npm install commands to block malicious packages in real time, using shell aliases (Unix) or registry/autorun (Windows). Authentication is multi-modal: OAuth2 (browser-based), API keys, and machine tokens, with a complex enrollment flow for enterprise MDM. An internal event bus (`safety/events/event_bus/bus.py`) provides async telemetry and audit trail emission, used throughout auth, init, and scan workflows. The codebase demonstrates strong engineering practices: layered configuration resolution (CLI > env > config file > default), a command wrapper pattern for package managers, and a policy file system (YAML) for ignoring vulnerabilities by severity, CVSS score, or expiration. However, there is notable technical drift: the legacy `check` and `license` commands are deprecated but still present, typing is incomplete in several modules, and the Windows firewall interceptor relies on fragile registry manipulation. The test suite is extensive but heavily mocks external services, making integration tests brittle. External dependencies include `httpx`, `authlib`, `tenacity`, `rich`, `pydantic`, `dparse`, `packaging`, `certifi`, `filelock`, and the proprietary `safety-schemas` package. The tool is distributed as a PyPI package and as a GitHub Action, with CI/CD pipelines building platform-specific binaries via PyInstaller and PyApp. Overall, Safety is a mature, feature-rich security tool with a well-architected core, though some areas show signs of rapid feature growth and legacy debt.
This repository is the official vcpkg registry, a collection of build recipes (ports) for over 2000 C/C++ libraries, managed by Microsoft. It is not the vcpkg tool itself but the package database that the tool consumes. The primary purpose is to define how each library is downloaded, patched, built, and installed across multiple platforms (Windows, Linux, macOS, Android, etc.) using CMake and other build systems. The architecture is a flat directory of port definitions, each containing a `vcpkg.json` metadata file and a `portfile.cmake` build script, along with patches and CMake config templates. The registry also includes a version database (`versions/`) for baseline and versioning resolution, CI test ports, and helper scripts for tool acquisition and deployment. While the codebase is well-organized and follows consistent patterns, it is primarily a data repository of package definitions rather than a reusable software library. The vcpkg tool itself is maintained in a separate repository.
Grazel is a Gradle plugin that migrates Android projects from Gradle to Bazel build systems. It analyzes Gradle project configuration, extracts Android-specific information (dependencies, variants, resources, manifest), and generates equivalent Bazel BUILD and WORKSPACE files. The plugin supports incremental migration, allowing parts of a project to use Bazel while others remain on Gradle. Architecture follows Gradle plugin conventions with modular separation: core plugin implementation, extension points for configuration, dependency analysis/resolution components, Android-specific extraction logic, Bazel rule generation using a type-safe Kotlin DSL for Starlark, and task management for orchestrating the migration process. Dependency injection via Dagger/Hilt ensures loose coupling and testability.
Yarn v1 (Classic) is a Node.js package manager CLI tool that handles dependency resolution, installation, and locking for JavaScript projects. The codebase implements a monolithic architecture with modular components for package resolution, fetching, linking, and reporting. Entry points include bin/yarn.js which routes through src/cli/index.js to command implementations in src/cli/commands/. Primary data flows involve parsing package.json, resolving dependencies through the resolver hierarchy, generating yarn.lock files, and installing packages into node_modules with hoisting logic. External dependencies include npm/yarn registries, git repositories, and offline mirrors for caching. This repository is in maintenance mode per the README - new features are developed in yarnpkg/berry (Yarn 2.x/3.x). The codebase demonstrates solid engineering with extensive test coverage (Jest/Jasmine), Flow type annotations, and well-defined patterns (Resolver, Fetcher, Reporter). However, it uses legacy tooling (Webpack 2, Babel 6, Flow 0.66) and supports EOL Node versions. The dependency management logic is complex and production-tested across millions of projects, making it genuinely reusable despite its age.
openupm-cli is a command-line interface for managing Unity Package Manager (UPM) dependencies. It allows users to add, remove, search, view, and list Unity packages from various registries (primarily OpenUPM and Unity's official registry). The tool modifies the Unity project's manifest.json file to add/remove dependencies and handles scoped registries for package resolution. It features a modular architecture with clear separation between CLI interface, application logic, domain models, and I/O operations. The codebase is written in TypeScript with comprehensive test coverage and follows semantic versioning for releases.
Dependency Guard is a Gradle plugin that monitors and protects against unintentional dependency changes in JVM-based projects. It creates baseline files of project dependencies for specified configurations and compares current dependencies against these baselines during build execution. When unintended changes are detected, it fails the build and provides a clear diff of what changed, allowing developers to either re-baseline for intentional changes or investigate problematic dependency drift. The plugin supports both simple list format and hierarchical tree format for dependency reporting, with the list format being recommended for CI usage due to less noise. It integrates with Gradle's lifecycle by automatically attaching to the 'check' task and provides clear commands for creating and updating baselines.
rules_boost is a Bazel repository providing build rules for the Boost C++ libraries. It allows Bazel users to depend on Boost libraries using labels like @boost//:algorithm. The repository fetches Boost source code and provides platform-specific build configurations for hundreds of Boost components, handling separate compilation requirements for libraries like ASIO and Beast. While the README indicates it's legacy compared to Bazel Central Registry, it remains maintained for compatibility. The core reusable component is the boost_library macro in boost/boost.bzl, which encapsulates patterns for building C++ libraries with Bazel.
This repository provides a GitHub Action to run Composer commands within a Docker container. It wraps the Composer CLI, allowing users to specify a command (default `install`), PHP version, Composer version, and various flags like `--no-dev`, `--no-progress`, and `--no-interaction`. The action downloads the appropriate Composer PHAR from getcomposer.org, sets up SSH keys for private repositories if provided, and executes the command inside a Docker container based on the php-actions/php-build image. The workspace is mounted at `/app`. The implementation is a single composite action with a bash script that handles argument parsing, SSH key setup, and Docker execution. It is a straightforward, well-documented action that solves the common problem of running Composer in CI pipelines. No reusable components beyond the action itself exist; the bash script is tightly coupled to GitHub Actions and Docker.