This repository provides a Docker-based tool for automatically discovering and backing up databases running in Docker containers. The core logic resides in a single Python script (`db-auto-backup.py`) that uses the Docker SDK to list running containers, identifies database containers by image name (PostgreSQL, MySQL/MariaDB, Redis), and executes native backup commands (pg_dumpall, mysqldump, redis-cli SAVE). Backups are written to a configurable directory with optional compression (gzip, lzma, bz2, zstd) and can be scheduled via cron expressions using the pycron library. The tool also supports success hooks (e.g., healthchecks.io, Uptime Kuma) and environment variable configuration. It is designed to run as a standalone Docker container with access to the Docker socket, making it a lightweight, self-contained backup solution for Docker hosts. The codebase is well-structured with type hints, linting, and a comprehensive test suite that validates backup generation and compression across multiple database types.
This repository is a massive, community-driven collection of algorithm and data structure implementations in Python, explicitly designed for education and reference. It contains over 1,700 files organized into topical directories such as maths, sorts, graphs, strings, ciphers, dynamic programming, machine learning, and Project Euler solutions. Each module is self-contained, typically with extensive docstrings, type hints, and doctests, making it easy to study or extract individual algorithms. The code is written for clarity and learning, not production performance, and many implementations include references to Wikipedia or academic sources. Despite its educational focus, the repository exhibits some technical drift. A handful of files still use Python 2 syntax (e.g., `except ValueError, EOFError:`), which will cause SyntaxError in modern Python. Several web-scraping scripts depend on the non-standard `httpx2` library and external APIs that may break. The project targets Python 3.15 (including free-threading), which is bleeding-edge and may cause compatibility issues with some tools. However, the majority of the codebase uses modern Python features (type hints, dataclasses, PEP 695 generics) and is actively maintained with CI workflows, pre-commit hooks, and regular contributions. This is not a production application or a data research pipeline; it is a reference library for learning and teaching algorithms. The sheer breadth and consistency of the implementations make it a valuable resource for students, educators, and developers looking for clear examples of classic algorithms. The most reusable components are the standalone data structures (e.g., kd-tree, suffix tree, Fenwick tree) and algorithm implementations (e.g., Dinic max flow, Huffman coding, federated averaging) that can be extracted with minimal modification.
Sherlock is a monolithic Python CLI for username enumeration across social networks. For a given username it fans out concurrent HTTP probes to roughly 400 external sites (defined declaratively in sherlock_project/resources/data.json), then classifies each response as Claimed / Available / Unknown / Illegal / WAF using three detection modes: HTTP status code, presence/absence of a site-specific error message in the response body, or redirect behavior (redirects disabled, 2xx/3xx means claimed). Requests run in parallel via a requests-futures session capped at 20 workers; an optional per-site regex short-circuits illegal usernames without sending a request, and hardcoded fingerprint strings detect Cloudflare / PerimeterX / AWS WAF blocks. The CLI accepts one or more usernames, supports {?} wildcard expansion into `_`, `-`, `.` variants, and reports results to the terminal via a QueryNotify observer, with optional .txt, .csv, and .xlsx export. The system is fully data-driven: no per-site code exists. Each manifest entry declares the probe URL, error detection method, error signatures, optional headers/request method/JSON payload, and NSFW flag; a JSON Schema (data.schema.json) enforces conditional consistency (e.g., errorMsg required when errorType includes 'message'). By default the manifest is fetched live from https://data.sherlockproject.xyz, with an ephemeral false-positive exclusion list pulled from a dedicated GitHub branch; --local, --json, and --site flags override this behavior. Entry points are the `sherlock` console script, `python -m sherlock_project`, a Docker image entrypoint, and an Apify Actor (.actor/) that wraps the Docker image and pushes JSON results into an Apify dataset. Engineering strengths include the declarative manifest/schema design, a genuinely useful test suite (schema validation, live-target probe tests, randomized false-positive fuzzing, a Unicode regression test for issue #2730), and CI that runs a tox matrix across Python 3.10-3.14t on three OSes, validates only manifest entries modified by a PR, comments the validation summary back on the PR, and updates the exclusions list daily. Weaknesses: nearly all orchestration and output-format logic lives in a ~1,200-line sherlock.py; notify.py uses a module-global result counter; sites.py has mutable default arguments and a dead username_unclaimed parameter; the --print-found flag is always True (store_true combined with default=True); stem is an unused declared dependency; and the request layer relies on requests-futures, an effectively unmaintained library. The project is actively maintained and extremely popular (93k+ stars), and its health depends on hundreds of external sites remaining stable, hence the extensive removed-sites documentation and dedicated false-positive/false-negative issue templates. Technical drift is moderate rather than severe: the Python ^3.9 floor is now EOL, requests-futures is unmaintained, the WAF fingerprint catalog has not been extended since late 2024, and the PyPI readme still documents removed --tor flags.
This repository provides the Nerd Fonts project, a CLI tool and collection of scripts that patch popular developer fonts with a large set of icon glyphs (including Font Awesome, Devicons, Octicons, Material Design Icons, and many more). The core entry point is the `font-patcher` Python script, which uses FontForge to merge icon glyphs into existing monospace fonts. Supporting scripts handle font name parsing, CSS generation, fontconfig configuration, release automation, and testing. The repository also contains pre-patched fonts in `patched-fonts/` and the raw icon sources in `src/glyphs/`. It is a mature, widely-used tool with active maintenance and a large community.
NetEase-MusicBox is a Python 3.10+ terminal client for NetEase Cloud Music (music.163.com), sold as the `musicbox` command. It is a hybrid application: an interactive curses TUI, an agent-facing stateless CLI, and a resident background daemon (`musicboxd`) that owns playback state. The TUI and daemon are mutually exclusive via a flock single-owner lock; control commands reach the daemon over a 0600-permission Unix domain socket using newline-delimited JSON-RPC. Audio plays through subprocess backends (mpg123 for MP3, mpv for FLAC/hi-res with IPC seek/volume control), and all NetEase API access goes through reverse-engineered weapi/eapi encryption (RSA+AES and AES-ECB with PKCS7/gzip handling). Login is QR-code scan only; session cookies and player state persist to XDG-compliant JSON/text files.
This repository is a production-grade, full-stack enterprise AI agent platform developed by iFlytek (Astron Agent). The system allows organizations to create, configure, deploy, and manage conversational AI agents (bots) with advanced workflow automation, knowledge retrieval (multi-strategy RAG), a plugin ecosystem (including MCP and HTTP tools), and multi-tenant team collaboration. The architecture is polyglot and service-oriented: a Java Spring Boot console backend handles bot lifecycle management, publishing to channels (API, WeChat, Feishu, marketplace), RBAC permissions, enterprise spaces, and notification systems. Python FastAPI core services power the workflow engine (20+ node types including LLM, code, decision, memory, knowledge), agent runtime with skill sandbox execution, knowledge indexing and retrieval, and plugin integrations (link server, RPA, MCP). A Go service manages tenant authentication and app key verification. The React + TypeScript frontend provides an interactive console for workflow design, model management, resource management (databases, knowledge bases, skill files), trace logs, and chat interfaces. External dependencies include multiple LLM providers (iFlytek Spark, OpenAI, Anthropic, Google, DeepSeek), MySQL, Redis, Kafka, S3-compatible storage, and Casdoor for SSO. The codebase demonstrates professional engineering with test coverage (JUnit, pytest, Jest), Flyway and Alembic database migrations, CI/CD pipelines, and a modular design using strategy, factory, and AOP patterns. However, it shows signs of complexity from polyglot maintenance, some duplicated frontend components, and legacy credential handling that has been addressed through targeted migration fixes. Overall, it is a well-maintained, actively developed platform suitable for mid-to-large enterprise deployments.
Jesse is a mature, full-stack algorithmic trading framework designed for cryptocurrency backtesting, live/paper trading, hyperparameter optimization, Monte Carlo simulation, and rule significance testing. It combines a Python library with a FastAPI web server and a Nuxt.js dashboard, offering a comprehensive environment for developing and validating trading strategies. The repository also includes an MCP (Model Context Protocol) server for AI-assistant integration, over 180 technical indicators (many with Rust-accelerated backends), and a research API for programmatic strategy analysis. Architecture is modular with distinct layers: CLI entrypoint → web controllers / MCP tools → service layer → simulation engine (backtest/optimize/live) → exchange adapters. State management uses global singletons for in-memory simulation state, while persistent data is stored via Peewee ORM (PostgreSQL, optional TimescaleDB). The indicator library showcases a clean pattern with sequential/non-sequential modes and Rust fallback. However, the codebase shows signs of organic growth with some tightly coupled modules (global config, store singletons) and a large static frontend bundle that is opaque to analysis. Key strengths include the breadth of supported exchanges (10+), robust backtesting with realistic fee/margin/leverage modeling, and a well-designed MCP tool layer for AI-assisted development. Weaknesses include exchange driver duplication, a complex Rust subprocess for coordination, and dependency on many external APIs that require ongoing maintenance.
Gita is a CLI tool that manages multiple git repositories from a single command. It allows users to register repositories, organize them into groups, and perform batch git operations such as fetch, pull, status, and custom commands across all or selected repos. The tool also displays a side-by-side summary of repository states including branch, commit message, time, and status symbols for staged/unstaged/untracked changes and local-remote branch relationships. The architecture is a monolithic Python application with a clear separation of concerns: `__main__.py` defines the CLI interface via argparse and delegates to action functions; `utils.py` provides file I/O, configuration parsing, and async execution utilities; `info.py` contains all logic for gathering and formatting repo status information; `common.py` handles config file paths; and `io.py` parses clone configuration files. The tool uses subprocess and asyncio to run git commands concurrently for multiple repos, falling back to synchronous execution for interactive commands like difftool or when only one repo is targeted. Gita stores repository metadata in CSV files under `$XDG_CONFIG_HOME/gita/` and supports extensive customization via additional config files for colors, symbols, displayed info columns, and custom commands defined in JSON. The codebase is well-tested with pytest and exercised on CI across multiple Python versions and operating systems. While the core functionality is tightly integrated with its own config schema, several internal patterns (async subprocess execution, git status extraction via diff --quiet) are cleanly abstracted and could be repurposed in other git tooling with minor adaptation.
The pm4py repository is a process mining library for Python, providing various algorithms for process discovery, conformance checking, and enhancement. It supports multiple process mining techniques, including inductive mining, alpha miner, and heuristics miner. The library is well-structured, with a clear organization and documentation. However, the large number of modules and algorithms might pose maintenance challenges.
ListenBrainz Server is the backend and frontend for ListenBrainz, an open-source music listening history platform operated by the MetaBrainz Foundation. In production it ingests listening events from multiple sources (Spotify, Last.fm, Libre.fm, Maloja, file uploads, and direct API submissions), stores them in TimescaleDB, enriches them with MusicBrainz identifiers via an MBID mapping pipeline, and exposes them through a public REST API, a Last.fm-compatible API, WebSocket streams, and a React single-page application. The system also computes per-user and site-wide statistics, artist/recording/user similarity, collaborative-filtering recommendations, and annual 'Year in Music' summaries using Apache Spark batch jobs orchestrated through RabbitMQ and HDFS. The architecture is a hybrid of a traditional Flask web application and a set of background data-processing services. The main web server handles user authentication, API endpoints, playlist management, social features, and page rendering, while separate workers consume RabbitMQ queues for timescale writes, Spark job requests, metadata cache crawling (Spotify, Apple Music, SoundCloud, Internet Archive), and background imports/exports. The frontend is a large TypeScript/React application with React Router, TanStack Query, Jotai state, and a custom multi-source audio player called BrainzPlayer. Although the repository is primarily an application, it contains substantial data-engineering machinery—Spark incremental stats engines, dump generation/import, MBID canonicalization, and similarity algorithms—making it a genuinely hybrid codebase with the application character dominant. The codebase is well-structured for its size: it has clear module boundaries, abstract base classes for importers and OAuth services, a reusable incremental stats query-provider pattern, and extensive unit and integration tests. However, it also carries significant complexity and technical debt: multiple database backends, duplicated SQL across Spark entity stats, legacy compatibility endpoints, hardcoded external URLs, and some skipped or heavily mocked tests. The project is actively maintained, with a steady stream of schema migrations and feature additions through 2026.
This is a personal dotfiles repository for macOS, automating the setup of a developer environment. It is not a traditional application but a configuration management system using dotbot to symlink config files and Homebrew to install software. The repository manages shell configuration (zsh with oh-my-zsh and zplug), editor settings (VS Code, nano, hyper), browser hardening (Firefox/Zen with arkenfox user.js), macOS system preferences, and a curated set of CLI tools and applications. The core entry point is a bash install script that runs dotbot pipelines. The codebase is well-organized, follows minimalism and security principles, and is actively maintained by a single developer. It demonstrates thoughtful patterns for fzf integration, Docker-based AI agent runners, and peripheral auto-launching, though it remains a personal configuration rather than a reusable library.
NyaProxy is a lightweight API gateway/proxy service built with FastAPI and Uvicorn that manages authentication, credential rotation, load balancing, rate limiting, and observability for HTTP APIs. It acts as an intermediary between clients and upstream services, injecting credentials, enforcing quotas, and providing features like retry logic, key quarantine, and request/response transformation. The system includes a web dashboard for monitoring traffic, metrics, and queue status, and exposes Prometheus metrics for external monitoring. The architecture follows a modular design with separate concerns: core proxy logic (queue-first request handling), traffic management (load balancing and rate limiting), configuration management (using Nacho for layered config and schema validation), services (metrics, state persistence), and a dashboard interface. Requests are processed via a priority queue with worker pools, enabling prioritization of retries and high-priority requests. State persistence saves rate limit windows and key cooldowns to disk using SHA256-hashed keys to avoid storing secrets, allowing survival across restarts. Key entry points include the CLI (`python -m nya` or `nyaproxy` script) and the main application factory in `nya/server/app.py`. The system relies on dependencies like FastAPI, Uvicorn, Pydantic, Nacho, and the Prometheus client, with explicit version pins in `pyproject.toml` and regular updates shown in the changelog. The codebase demonstrates strong engineering practices including comprehensive test coverage (unit and end-to-end), secure secret handling, and clean separation of concerns.
PythonMonkey is a Python C extension that embeds Mozilla's SpiderMonkey JavaScript engine, enabling seamless bidirectional interop between Python and JavaScript. It allows Python code to evaluate JS expressions, require CommonJS modules (including .py modules), and manipulate JS objects as native Python types via proxy objects with shared memory semantics. The library integrates JS promises and timers with Python's asyncio event loop, and provides a CLI tool (pmjs) similar to Node.js. The architecture is a native module with extensive C++ proxy handlers for type coercion, a CommonJS module system, and built-in JS modules (console, timers, URL, XMLHttpRequest). External dependencies include SpiderMonkey (built from source), Python 3.8–3.13, npm, cmake, and rust. The codebase is actively maintained by Distributive Corp. and reached MVP in September 2024, but carries medium technical drift due to tight coupling to a specific SpiderMonkey version and Python version shims.
This repository is the `lingam` Python package, a comprehensive, research-oriented library for causal discovery from observational data using LiNGAM (Linear Non-Gaussian Acyclic Model) and its numerous extensions. It implements over 20 algorithms, including DirectLiNGAM, ICALiNGAM, VAR-LiNGAM, RCD, CAM-UV, RESIT, LiM, mLiNGAM, GroupLiNGAM, MultiGroup variants, and more. The library provides a consistent API where each algorithm exposes `fit()` on a data matrix, followed by properties like `causal_order_` and `adjacency_matrix_`, and all support bootstrap-based stability analysis via a shared `BootstrapMixin`. Key contributions include handling of latent confounders, time series, missing data, mixed data types, and multiple datasets, alongside utilities for causal effect estimation, visualization, model evaluation, and synthetic data generation. The code is well-structured, uses standard scientific Python dependencies (numpy, scipy, scikit-learn, graphviz), and includes a thorough test suite and extensive Jupyter notebook tutorials.
BittyTax is a Python CLI application suite for computing UK cryptocurrency tax liabilities. It consists of three console tools: bittytax_conv normalizes raw CSV/XLSX exports from approximately 80 exchanges, wallets, block explorers and accounting platforms into standardized transaction records; bittytax applies HMRC rules such as same-day matching, bed-and-breakfast, Section 104 pooling, and ten-day matching for companies, then generates PDF/Excel/console reports for capital gains, income, margin trading, holdings, and audit; bittytax_price fetches historical and latest asset prices from CoinGecko, CoinPaprika, CoinStats, Frankfurter, and BittyTaxAPI with local JSON caching. The repository is fundamentally an application rather than a data-research project: it exposes CLI entry points, has a plugin-based parser architecture, config-driven behavior, test suites, and CI pipelines, while the data-heavy parser and price modules are application subsystems rather than analytical pipelines.
tksheet is a pure Python Tkinter widget library that provides a full-featured, interactive spreadsheet-like table and treeview component for embedding in desktop applications. It renders only visible cells using Tkinter canvases, supporting cell editing, dropdowns, checkboxes, progress bars, notes/tooltips, find/replace, sorting, undo/redo, clipboard operations, and extensive theming. The architecture is modular, with separate classes for the main table, column headers, row index, text editor, and dropdown windows, all orchestrated by a central `Sheet` class that exposes a rich API for data manipulation and event handling. The library demonstrates strong software craftsmanship through its use of reusable patterns such as `Span` objects for addressing cell ranges with method chaining, `DotDict` for attribute-accessible configuration dictionaries, and a consistent `EventDataDict` structure for undo/redo and event propagation. It also includes self-contained utility modules for data formatting (`Formatter` class) and sorting (natural, version, and fast sort keys) that could be extracted and reused independently. Development of tksheet has officially ceased except for bug fixes and behavioral issues, as stated in the README. The codebase is mature and stable, with extensive documentation and a changelog spanning multiple major versions. While the library is tightly coupled to Tkinter and has some code duplication across similar components (e.g., column headers and row index), it remains a high-quality, production-ready widget for any Python GUI application requiring tabular data interaction.
KaHIP (Karlsruhe High Quality Partitioning) is a high-performance C++ library and command-line toolkit for graph partitioning, node ordering, and mapping. It implements multilevel partitioning with advanced refinement techniques including Fiduccia-Mattheyses local search, flow-based min-cut refinement, cycle improvements, and tabu search. The library provides a C API for integration into external applications, along with Python bindings and a Java JNI wrapper. The codebase includes both a sequential version and a distributed-memory parallel version (ParHIP) using MPI, enabling partitioning of large graphs on clusters. Core algorithms are well-structured with modular coarsening, initial partitioning, and uncoarsening/refinement phases, supporting multiple matching strategies (GPA, random, label propagation) and quality/speed trade-offs via preconfigured modes (Strong, Eco, Fast, Social). Despite research-grade complexity and some code duplication between serial and parallel variants, the library is actively maintained and widely used in scientific computing and graph analytics.
This repository implements a fully autonomous pipeline that generates, produces, and uploads educational YouTube videos daily. It uses the Gemini 2.5 Flash API to create lesson scripts and curricula, gTTS for narration, Pexels for background imagery, and MoviePy/Pillow for video rendering. The pipeline runs on a GitHub Actions cron schedule, requiring no manual intervention. It produces both a long-form lesson video and a YouTube Short, uploads them with custom thumbnails, and updates the content plan repository. The code is well-structured for its purpose, with proper error handling, retry logic for TTS rate limits, and credential management for YouTube OAuth. While not a reusable library, it demonstrates good software engineering practices for a CI/CD-based content generation system.
This repository implements a threshold-based vertical autoscaling system for Proxmox VE virtual machines. It runs as a systemd service that periodically polls VM CPU and RAM usage via SSH commands (qm, pvesh) and adjusts CPU cores and RAM by 1 core or 512 MB when configurable high/low thresholds are crossed. The system includes host resource safety limits, per-VM threshold overrides, independent cooldowns for CPU and RAM, and optional billing tracking with CSV export and webhook notifications. It also provides a lightweight Prometheus metrics endpoint built on stdlib, supports Gotify and SMTP notifications, and offers a dry-run mode for safe evaluation. The architecture is a single-threaded polling loop with in-memory state, designed for simplicity and reliability rather than horizontal scaling or predictive analytics. The codebase is well-tested with over 290 unit tests and end-to-end tests against real Proxmox nodes, and includes comprehensive documentation via a VitePress site. Key reusable components include a generic SSH client with retry/backoff and host key policies, a thread-safe Prometheus metrics registry without external dependencies, and a configuration validation module that reports all errors at once.
GQLAlchemy is a Python library and Object Graph Mapper (OGM) for the Memgraph graph database, with secondary support for Neo4j. It provides a fluent Cypher query builder, declarative node/relationship models (Pydantic v2-based), and full lifecycle management of graph database instances (Docker/binary), streams (Kafka, Pulsar), triggers, and high-availability routing. The library also includes a rich set of transformations for bidirectional conversion between Memgraph/Neo4j and popular graph machine learning frameworks (NetworkX, DGL, PyG, TF-GNN), as well as tabular data import (CSV, Parquet, ORC, Feather) from local filesystem, S3, and Azure Blob Storage. While primarily a software library for building graph applications, it has strong data research capabilities through its graph ML translators and ETL importers, making it a hybrid tool suited for both production graph apps and data science pipelines. The codebase is well-tested (unit and integration tests), has comprehensive CI/CD, and follows a modular architecture with abstract base classes for extensibility. However, some modules are large (e.g., monolithic query builders), and optional dependencies (PyTorch, DGL, TF-GNN, PyArrow) increase maintenance surface, with a medium level of technical drift due to some deprecated Pydantic v1 patterns and skipped tests.