omnipkg v2.0.6 - Rare Knowledge Base Hanging Resolved

This release fixes a high-priority regression where omnipkg status or omnipkg install would hang indefinitely during the "Updating knowledge base" phase.

🐛 Critical Bug Fixes

• Resolved Infinite Hang in Metadata Builder: Removed a "dead" dictionary comprehension in src/omnipkg/package_meta_builder.py.
  • Root Cause: This regression was introduced during a recent automated refactor by formatters/linters. The tooling inadvertently transformed a loop into an orphaned dictionary comprehension that exhaustively iterated over a generator without side effects, causing the process to hang on large environments.
  • The Fix: The phantom code block has been removed, restoring instant execution speed to the Knowledge Base updater.

⚙️ Maintenance

• Development Sync: Merged pending improvements from the development branch, resolving merge conflicts by prioritizing the latest stable code paths in core.py and loader.py.

📦 Installation

pip install --upgrade omnipkg

Full Changelog: v2.0.5...v2.0.6

omnipkg v2.0.5 - Security Hardening & New Long-Term Support Infrastructure

Executive Summary

This release strengthens omnipkg's security posture across Python 3.7–3.14, introduces a production-ready Long-Term Support (LTS) package ecosystem, and establishes the operational framework for maintaining secure dependency chains on legacy Python versions where upstream support has ended.

Key Outcomes:

• Backported a critical security fix for filelock to Python 3.7–3.9 via a new, public LTS ecosystem.
• Expanded CI coverage to the full Python 3.7-3.14 range with automated release gating.
• Streamlined the CI/CD pipeline for reliability, replacing over 30 noisy, non-functional workflows with a focused suite of integrated open-source security scanners.
• Patched multiple critical stability, bootstrapping, and security issues.
• Documented an explicit, transparent security model for legacy Python environments.

---

🛡️ The Filelock LTS Ecosystem (CVE-2025-68480)

The Problem

The filelock project patched CVE-2025-68480 (a TOCTOU race condition) only for Python ≥ 3.10. This left 10–15% of daily PyPI installations—millions of environments on Python 3.7–3.9—exposed with no upstream remediation path.

The Solution

We have created a Long-Term Support (LTS) backport of the upstream security fix for all affected legacy Python versions. The fix was applied verbatim to the last release supporting each runtime, with no feature or behavior changes.

Implementation

omnipkg now automatically selects the correct dependency:

Python Version	Installed Package	Base filelock Version
3.7–3.9	filelock-lts on PyPI	(Version-specific backport)
≥ 3.10	Official filelock	3.20.1+

LTS Repository: github.com/1minds3t/filelock-lts
This repository serves as the reference model for future LTS packages, with CalVer versioning, OIDC trusted publishing, and full auditability.

---

🧪 CI/CD Optimization & Reliability

• CI Streamlining: Removed over 30 non-functional, paid-tier security workflows that were generating constant noise and failures. The CI pipeline now relies exclusively on integrated, passing, open-source security tools like CodeQL and Dependabot.
• Expanded Test Matrix: Added native CI testing for Python 3.8–3.14 and a dedicated Docker-based environment for Python 3.7.
• Release Gating: All releases must now pass tests on Python 3.7, 3.8, 3.11, and 3.14 before publishing.
• Guardrails: Added an enforcement workflow (no-paid-scanners.yml) to prevent the reintroduction of noisy, API-gated scanners.

---

🐛 Stability & Correctness Fixes

• Snapshot Restore: Resolved a TypeError crash in _safe_restore_from_snapshot.
• Knowledge Base: Fixed a critical bug that caused global metadata deletion during partial uninstalls.
• Python 3.14 Bootstrapping: Corrected logic that incorrectly pulled legacy dependencies.
• Python 3.7 Compatibility: Removed walrus operator (:=) usage and corrected dataclasses backport constraints to restore clean installs.

---

🛡️ Security Hardening

Command Execution Safety

• Removed shell=True usage from internal pip verification calls, replacing shell pipelines with safe subprocess invocation and native Python parsing.

Dependency Security Updates

• Authlib: Implemented version splitting to provide the highest-possible (though still vulnerable) version for Python 3.7 and 3.8, while using fully patched versions for 3.9+.
• tqdm: Updated to >=4.67.1 for all Python versions to patch CVE-2024-34062.
• Transitive Override (Marshmallow / CVE-2025-68480):
  • Problem: The safety security scanner itself depends on marshmallow versions vulnerable to a DoS attack.
  • Solution: We now force marshmallow>=4.1.2 on Python ≥ 3.10, overriding safety's loose constraints to protect our users.
  • Upstream Report: We have reported this issue to the maintainers in pyupio/safety#826.

---

⚠️ Legacy Python Security Model (3.7–3.8)

This release introduces a transparent security model for legacy Python. Some dependencies cannot be fully secured on Python < 3.9 due to upstream abandonment.

• authlib: Older branches retain known JWT/DoS issues.
• urllib3: Versions < 2.0 (used by requests) include unresolved CVEs.

Many production systems cannot upgrade due to regulatory, hardware, or operational constraints. omnipkg explicitly documents these risks and applies the safest achievable configuration rather than forcing upgrades or breaking compatibility. This is an informed, opt-in security posture, not a claim of complete safety.

---

🔮 LTS Ecosystem Roadmap

The filelock-lts project is the first step. Our roadmap includes:

• Planned LTS Packages: marshmallow-lts, authlib-lts, and urllib3-lts.
• Planned Capabilities: Automated CVE backporting, immutable artifact publishing, and lightweight background CVE monitoring.

This initiative aims to provide a practical, auditable model for maintaining security in environments that the upstream ecosystem has moved past, supporting the millions of daily installations on legacy runtimes.

---

Full Changelog: v2.0.4...v2.0.5

omnipkg v2.0.4 — Filelock CVE-2025-68146 Closed · ARM32 + ARM64 Verified · 23+ Platforms

This is a landmark release for omnipkg, focused on hardening security, achieving near-universal platform verification, and implementing a robust, automated CI/CD pipeline. Version 2.0.4 introduces critical security patches, adds complete ARM64 and ARM32 test coverage, and brings native support for Apple Silicon.

🌟 Major Highlights

• 🔒 Security Hardening (CVE-2025-68146): Patched a critical file-locking vulnerability by vendoring a patched version of filelock, ensuring users on all Python versions are protected out-of-the-box.
• 🚀 Complete ARM Architecture Verification: Introduced an exhaustive testing suite for both ARM64 and ARM32 architectures.
  • ARM64 (aarch64): Now verified across 6 major Linux distributions using a powerful QEMU emulation pipeline.
  • ARM32 (armv7): Now automatically verified by scraping build results from the trusted piwheels.org repository.
• 🍏 Native Apple Silicon (macOS ARM64) CI: Added a dedicated job using GitHub's macos-14 native M-series runners, ensuring flawless performance on modern Macs.
• 🤖 Bulletproof Release Pipeline: The PyPI publishing process is now gated, and will not run until all critical cross-platform and ARM64 verification tests have passed successfully.
• 📝 Major Documentation Overhaul: The README.md has been massively updated with detailed, auto-generated platform support matrices, reflecting the live results of our new CI pipelines.

---

Detailed Changes

1. Security Enhancements

• Vendored filelock for CVE-2025-68146: To protect users on older Python versions (< 3.10) from a symlink-based vulnerability in filelock, we have vendored a patched version of the library directly into omnipkg. This provides an immediate, seamless fix without requiring users to manage complex dependencies. Python 3.10+ will continue to use the latest secure version from PyPI.
• Upgraded Security Scanners: The dependency logic in pyproject.toml has been refined to use the latest safety for supported Python versions and pip-audit as a fallback, ensuring continuous security scanning across our entire Python version range (3.7-3.14).

2. Massive CI/CD Expansion

• ARM64 Verification via QEMU: A new workflow (arm64-verification.yml) now runs on every tag and release, testing omnipkg inside Podman containers on emulated ARM64 environments for Debian, Ubuntu, Fedora, Rocky Linux, and Alpine.
• Native Apple Silicon Testing: The primary build verification workflow now includes a macos-14 runner, adding native ARM64 testing on Apple's M-series hardware to our matrix.
• Automated ARM32 (Raspberry Pi) Verification: A new workflow (piwheels-arm32-verification.yml) runs on a schedule and after releases to scrape piwheels.org, confirming that builds for Raspberry Pi are available and updating the README with the results.
• Gated PyPI Publishing: The publish.yml workflow now explicitly waits for the main cross-platform and ARM64 tests to complete successfully before allowing a package to be published. This prevents accidental releases of broken code.
• Automated Branch Syncing: New workflows (sync-main.yml, auto-merge-to-main.yml) have been implemented to keep the development and main branches synchronized, improving development velocity and stability.
• Multi-Arch Docker Builds: The Docker build process (docker-ci-ghcr.yml) is now more robust, building and pushing multi-architecture images (amd64, arm64) to both Docker Hub and GitHub Container Registry.

3. Bug Fixes and Refinements

• Fixed KB Initialization Deadlock: Resolved a NoneType error in the package_meta_builder that could occur during the very first knowledge base build when trying to run a security scan before the bubble manager was fully initialized.
• Dockerfile Simplification: Removed the Redis server from the official Docker image. omnipkg's automatic fallback to a built-in SQLite database makes this unnecessary for most users and results in a lighter, more secure container.

This release represents a huge leap forward in the reliability, security, and professional-grade quality assurance of omnipkg.

omnipkg v2.0.3 - Live Daemon Monitoring + Code Quality Overhaul

🎯 New Feature: Real-Time Daemon Monitor

Added 8pkg daemon monitor - a live TUI dashboard for monitoring worker daemon performance.

# View current daemon metrics
8pkg daemon monitor

# Live auto-refresh dashboard (watch mode)
8pkg daemon monitor --watch

Metrics Display:

• 📊 Real-time worker stats per package version
• 💾 Memory usage tracking
• 📈 Request counts & cache hit rates
• ⏱️ Worker idle time
• ❌ Per-worker failure tracking
• 🐍 Python interpreter mapping

---

🔧 Code Quality & Security Overhaul

Automated Linting & Formatting

• Fixed undefined variables, unused imports, dead code
• Added proper type hints
• Improved code formatting consistency
• Fixed shadowed variables

Security Infrastructure

• Added 30+ security scanning workflows (Snyk, Trivy, SonarCloud, Checkmarx, etc.)

Bug Fixes (Linter-Induced Issues)

No bugs existed in the original code. These fixes correct issues introduced by automated linting tools:

• Restored walrus operator in file hashing (linter removed it → infinite loop)
• Fixed loop variable in smart_uninstall (linter changed wrong variable)
• Resolved merge conflicts from automated changes

---

📦 Upgrade

8pkg upgrade omnipkg

Note: Legacy daemon status still available for simple snapshot view.

omnipkg v2.0.2 - Security Patch & Microsecond Conflict Detection

🚨 Critical Security Update (CVE-2025-68146)

Addressed a TOCTOU race condition in filelock by implementing strict version pinning with environment markers in pyproject.toml. This ensures the security patch is applied on supported Python versions while maintaining installation compatibility for legacy environments:

• Python 3.10+: Enforced filelock>=3.20.1 (Patched)
• Python 3.8-3.9: Pinned filelock>=3.13,<3.20.1
• Python <3.8: Pinned filelock>=3.12,<3.13

⚡ Performance: Redis Pipelining

The Legacy In-Process Loader has been optimized to remove filesystem bottlenecks during conflict detection.

• New Method: Added _detect_conflicts_via_redis() using Redis pipelining.
• Optimization: Replaced O(N) filesystem scanning (glob/scandir) with O(1) batched cache lookups.
• Metric: Reduced conflict detection overhead from ~2.3ms to ~0.09ms.
• Fallback: Added _detect_conflicts_legacy() for environments without Redis.

🐛 Fixes & Improvements

• Profiling Silence:
  • Changed enable_profiling default to False.
  • Updated _profile_end() and _aggressive_module_cleanup() to strictly respect the profiling flag.
  • Standard execution is now completely silent.
• Code Organization:
  • Refactored loader.py logic; moved _activate_bubble and split conflict detection strategies for better readability and maintenance.

Full Changelog: v2.0.1...v2.0.2

omnipkg v2.0.1 - Microsecond Install Verifications, Concurrent-Safe >1ms Overhead Daemon Spawns, and Windows Daemon Support

This is a significant point release that addresses critical stability issues, introduces massive performance enhancements, and implements a more robust, concurrent architecture for the daemon.

🚀 Performance Overhaul: Microsecond Activation

The omnipkgLoader has been obsessively profiled and optimized, pushing every controllable operation to its physical limits.

• ~50 Microsecond Pre-flight Checks: The package satisfaction check (check_package_installed_fast) has been rewritten to use direct, cache-less filesystem scans. This has reduced the time to validate an existing package from ~24 milliseconds to ~50 microseconds—a nearly 500x speedup.
• Sub-Millisecond Activation: For packages already in the main environment, the total activation time (including all checks and cloaking of conflicting bubbles) is now consistently under 1 millisecond.
• Surgical Knowledge Base Updates: The metadata discovery logic now uses a "fast-path" to surgically locate only newly installed packages, dramatically accelerating post-install operations.

🐛 Critical Stability & Cross-Platform Fixes

• Windows Support (No-Fork Mode): The worker daemon has been re-architected to support Windows by implementing a --no-fork startup mode that uses subprocess.Popen, enabling full daemon functionality on all platforms.
• First-Run Initialization Bugs:
  • Resolved multiple recursion loops during first-time setup by correcting initialization order and enforcing minimal_mode.
  • Fixed an AttributeError for _info_cache that would occur on the very first Knowledge Base build, preventing a clean initial setup without requiring 8pkg reset.
• Daemon psutil Bug: Fixed a faulty import check that caused 8pkg daemon status to incorrectly report "psutil not installed" even when it was present.
• Package Discovery (canonicalize_name): Patched a NameError in the package discovery logic, improving the reliability of metadata gathering.
• Scope and PATH Bugs:
  • Resolved an UnboundLocalError in the GPU pipeline by correcting logic scope.
  • Implemented PATH environment variable manipulation in the loader to enable proper binary executable isolation (e.g., uv).

✨ Architectural Enhancements

• Centralized Quantum Healing: The existing "Quantum Healing" logic for Python version conflicts has been centralized into a single _handle_quantum_healing method to simplify the codebase.
• Concurrent Daemon Spawning: The daemon architecture was hardened with more granular locking around filesystem cloaking. This allows multiple daemon workers to be spawned concurrently in a thread-safe manner.
• Smart Installation Verification: A new verification system intelligently groups and tests interdependent packages (e.g., the httpx stack) together to ensure robust installations.
• Automatic Index Detection: A new package index registry automatically detects and uses special URLs for variants like PyTorch CUDA builds.
• Snapshot-Based Stability: smart_install now takes pre-install snapshots and can perform a "safe restore" if an operation fails.

omnipkg v2.0.0 - The Python Hypervisor Release

Release Date: 2025-12-08

This release marks a fundamental paradigm shift from "Package Loader" to "Distributed Runtime Architecture." OmniPkg 2.0 introduces a persistent daemon kernel, universal GPU IPC, and hardware-level isolation, effectively functioning as an Operating System for Python environments.

We have shattered the performance barrier. What once took 2 seconds now takes 60 milliseconds. What once crashed due to ABI conflicts now runs concurrently on the same GPU.

🚀 Major Architectural Breakthroughs

• Universal GPU IPC (Pure Python/ctypes):

  • Implemented a custom, framework-agnostic CUDA IPC protocol (UniversalGpuIpc) using raw ctypes.
  • Performance: Achieved ~1.5ms latency for tensor handoffs, beating PyTorch's native IPC by ~30% and Hybrid SHM by 800%.
  • Enables true zero-copy data transfer between isolated processes without relying on framework-specific hooks.

• Persistent Worker Daemon ("The Kernel"):

  • Replaced ad-hoc subprocess spawning with a persistent, self-healing worker pool (WorkerPoolDaemon).
  • Reduces environment context switching time from ~2000ms (process spawn) to ~60ms (warm activation).
  • Implements an "Elastic Lung" architecture: Workers morph into required environments on-demand and purge themselves back to a clean slate.

• Selective Hardware Virtualization (CUDA Hotswapping):

  • Implemented dynamic LD_LIBRARY_PATH injection at the worker level.
  • The daemon now scans active bubbles to inject the exact CUDA runtime libraries required by the specific framework version (e.g., loading CUDA 11 libs for TF 2.13 while the host runs CUDA 12).
  • Result: Successfully ran TensorFlow 2.12 (CPU), TF 2.13 (CPU), and TF 2.20 (GPU) simultaneously in a single orchestration flow without crashing.

⚡ Core Enhancements

• Fail-Safe Cloaking: Added _force_restore_owned_cloaks() to guarantee filesystem restoration even during catastrophic process failures or OOM events. No more "zombie" cloaked files.
• Global Shutdown Silencer: Implemented an atexit hook that synchronizes CUDA contexts and redirects stderr to /dev/null during final interpreter shutdown, eliminating harmless but noisy C++ "driver shutting down" warnings.
• Composite Bubble Injection: The loader now automatically constructs "Meta-Bubbles" at runtime, merging the requested package bubble with its binary dependencies (NVIDIA libs, Triton) on the fly.

🐛 Critical Fixes

• PyTorch 1.13+ Compatibility: Patched the worker daemon to handle TypedStorage serialization changes in newer PyTorch versions, preventing crashes during native IPC.
• Deadlock Prevention: Implemented ThreadPoolExecutor in the daemon manager to allow recursive worker calls (Worker A calling Worker B) without deadlocking the socket.
• Lazy Loading: Made psutil and torch imports lazy within the daemon to prevent "poisoning" the process with default environment versions before isolation takes effect.

📊 Benchmarks (vs v1.x)

Metric	v1.x (Hybrid)	v2.0 (Universal)	Speedup
IPC Tensor Handoff	14ms	1.5ms	9.3x
Context Switch (Cold)	~2500ms	~2500ms	1.0x
Context Switch (Warm)	~2000ms	~0.06s	33x
Recursive Depth	5 levels	Unlimited	∞

📦 Upgrade

# Via pip
pip install --upgrade omnipkg

# Via omnipkg itself
8pkg upgrade

Welcome to the Singularity.

omnipkg v1.6.2 - Universal Runtime Healing Introduced

This release transforms omnipkg into a truly universal execution environment. It can now accept Python code via any method (scripts, inline -c, heredocs, pipes, or CLI binaries) and wrap them in an immortal, self-healing context.

🚀 New Features

• Universal Input Support: 8pkg run now handles stdin execution (python <<EOF or cat script.py | 8pkg run python). If the piped code fails, omnipkg captures it, analyzes the crash, auto-heals the environment, and re-runs it transparently.
• StdLib Guard: The heuristic engine now strictly filters out Python standard library modules (like sys, os, math, json). It will no longer attempt to "install" these if a script has a syntax error involving them.
• Smart Dependency Batching: When a ModuleNotFoundError occurs, the healer instantly scans the rest of the script for other missing imports and installs them all in a single batch operation, drastically reducing repair time.
• CLI Healing: You can now run system tools like 8pkg run http --version. If httpie is broken due to dependency conflicts (e.g., urllib3 version mismatch), omnipkg automatically detects the tool's owner package, creates an isolated bubble, and executes the tool successfully—without touching your main environment.

🛡️ improvements & Fixes

• Safety First Bubbling: Fixed a logic flaw where the healer would grab any available bubble version. It now correctly resolves the latest version from PyPI first, then checks if a bubble exists for that specific version.
• Performance Stats: The "UV vs OMNIPKG" performance comparison table is now perfectly aligned and formatted, regardless of the runner name length.
• Verbose Control: Silenced noisy sys.path injection logs during wrapper execution. Use --verbose to see them.
• Python Management: You can now install/swap Python versions using standard install syntax: 8pkg install python==3.12.

⚡ Performance

• Execution: ~7.8x faster than uv run failure-to-recovery cycles
• Bubble Activation: <25ms average (sub-millisecond for cached bubbles)
• Smart Batching: Reduces multi-package healing drastically

---

📦 Upgrade

# Via pip
pip install --upgrade omnipkg

# Via omnipkg itself
8pkg upgrade

# Or with conda
conda update -c conda-forge omnipkg

omnipkg v1.6.1 - Bulletproof Concurrency & Windows Stability

v1.6.1: Bulletproof Concurrency & Windows Stability

This is a critical stability and performance release that eliminates race conditions discovered during multi-threaded, cross-platform testing. After the massive src layout refactor, we subjected omnipkg to its most intense stress test yet, uncovered a core concurrency flaw on Windows, and completely re-engineered the self-healing and sync mechanisms to be rock-solid.

The results are staggering: what previously caused crashes and file corruption now runs flawlessly, with subsequent runs completing up to 58x faster (from 413 seconds down to 7.1 seconds).

🚀 Concurrency & Stability Overhaul (The Real Story)

The "Quantum Multiverse" demo revealed a critical race condition on Windows: the self-heal sync process would modify a managed Python environment at the exact moment another thread was scanning it, causing FileNotFoundError crashes on temporary files (~mnipkg-1.6.1.dist-info). This has been completely resolved.

Key Fixes:

• Eliminated Race Conditions: Introduced a strict "native-only" sync rule. Managed interpreters running in concurrent threads are now forbidden from initiating a sync, preventing them from modifying each other's filesystems.
• Bulletproof File Scanning: The Knowledge Base builder now gracefully handles race conditions by ignoring temporary (~) files and skipping any file or directory that is deleted mid-scan, preventing crashes.
• Conservative Windows Defaults: The self-heal sync is now disabled by default on Windows to guarantee stability in complex environments. It can be enabled for power users via OMNIPKG_ENABLE_SYNC=1.
• Massive Performance Gains: With the KB builds now stable, subsequent test runs leverage the cache perfectly, dropping execution time from ~7 minutes to ~7 seconds.

🪟 Enhanced Windows Reliability

Building on the concurrency fixes, we've further hardened Windows-specific behavior.

• Stale DLL Cache Purging: Windows now always performs a full Python context swap to clear "zombie" DLLs left in memory after concurrent operations, preventing Fatal Python error crashes.
• Universal Safe Printing: All 237 print statements containing emojis have been wrapped in safe_print() to eliminate UnicodeEncodeError crashes in Windows terminals.

🍺 Homebrew Formula Resurrection

After being stuck on v1.5.4 since October 3, 2025, the Homebrew tap is back online with automated updates!

• Automated CI/CD Pipeline: Formula updates on every release.
• Resilient PyPI Polling: Now retries up to 15 times to fetch release data.
• Install/Update:

  brew update && brew upgrade omnipkg

🛠️ Developer Tooling

Two new utilities were created to achieve this level of stability:

• emoji_print_fixer.py: Automatically converted 237 print() calls to safe_print().
• embedded_code_checker.py: Scans for and identifies missing imports in dynamically generated code strings.

📝 Upgrade Notes

This is a critical stability patch for all users, especially those on Windows or running omnipkg in complex, multi-threaded applications. The performance improvements on cached runs are a significant bonus.

---

Full Changelog: v1.6.0...v1.6.1
Homebrew Tap: https://github.com/1minds3t/homebrew-omnipkg

omnipkg v1.6.0 - The Quantum Lock & Concurrency Release

omnipkg v1.6.0: The Quantum Lock & Concurrency Release

After a monumentally productive weekend and over 70 developer commits, this release transforms omnipkg from a powerful tool into a battle-hardened, production-grade orchestrator. This isn't just an update; it's a foundational rewrite of the core engine, focused on eliminating race conditions, conquering state corruption, and achieving true, safe concurrency on all platforms, including Windows.

With over 6,000 lines of code changed, this release introduces an entirely new level of intelligence, compatibility, and resilience to the system.

🚀 New Features & Major Architectural Victories

True, Multi-Platform Concurrency: The "Impossible" Achieved

Omnipkg now fully supports simultaneous, parallel operations without corrupting its own state. The "Quantum Multiverse" is no longer just a concept—it's a reality. Our Windows CI now proves that three concurrent threads can simultaneously swap to different Python versions, install different package versions, and operate in the same environment without a single failure.

This was made possible by a ground-up re-architecture of state management:

• Atomic Registry Operations: All writes to the interpreter registry.json are now protected by file locks and atomic move operations.
• The "Admin vs. Worker" Firewall: A critical safety rule has been implemented. The "native" interpreter is a protected "admin" context, and "worker" contexts (e.g., a thread on Python 3.9) are forbidden from modifying the native environment, solving the primary source of self-syncing bugs and race conditions.

Intelligent, Trustworthy Self-Healing

The "zombie state"—where an interpreter exists on disk but is unknown to the registry—has been eradicated. The core commands are now self-aware and capable of healing the system.

• Smart swap Command: Now features a multi-tiered fallback that will automatically trigger a full filesystem rescan to find and register "zombie" interpreters before proceeding.
• Hardened adopt & remove: These commands are now fully transactional, performing a final rescan to verify the ground truth before reporting success. The system will never lie to you again.

Full Python 3.7+ Compatibility & Next-Gen Resolution

• Legacy Project Support: Omnipkg now fully supports managing projects running on Python 3.7. The entire dependency chain has been updated, and omnipkg can now download and manage standalone Python 3.7 interpreters.
• Smarter Dependency Resolution: Omnipkg now intelligently calculates the correct intersection of version requirements (e.g., numpy<2.0 vs. numpy>=1.26).

Platform-Aware Intelligence & User Experience

• Platform-Aware Wheel Selection: Omnipkg now inspects all available package files, parsing wheel tags to select the best binary wheel for your specific OS, CPU architecture, and Python version.

  Pip may still be a reckless time traveler, but with omnipkg, it's now carrying the right passport.

• "Return to Origin" Install Guarantee: The install command now automatically returns you to your original Python context after a "Quantum Healing" event.
• Blazing Fast Startup (204x Faster Self-Heal): The startup self-heal check has been optimized with a multi-tiered caching strategy, reducing its execution time from 138ms down to a mere 0.677ms on a cache hit.

📝 Important Notes & Known Issues

• Native Interpreter Sync: To ensure maximum safety and respect for the user's environment, the self-healing mechanism will sync all managed interpreters automatically, but it will not automatically upgrade the native omipkg installation. This is intentional. To upgrade the native installation, please use the explicit omnipkg upgrade omnipkg command, or pip install -e . for developers.
• Python 3.7 Self-Heal: While Python 3.7 is now fully supported for adoption, installation, and swapping, the self-healing logic for identifying it as a "native" interpreter is still under development. This is a known issue that will be resolved in an upcoming patch release.

🔮 What's Next: Activating "Quantum Installation"

The individual pieces of our next great leap are already here. This release doesn't just promise future features; it ships the proven, foundational technology for them.

The install command's "Quantum Healing" engine can already perform fully autonomous, cross-interpreter installations—detecting Python version incompatibilities, adopting the correct Python version, installing the package, and seamlessly returning to the original context. The run command's auto-healing loader can already activate version "bubbles" at runtime.

The next major step is to integrate these two proven technologies.

In a near-future release, the omnipkg run loader will be wired directly into the Quantum Healing engine. When a script imports a package that requires a completely different version of Python, the loader won't just fail—it will trigger the full, cross-dimensional installation workflow that omnipkg install uses today.

The architecture is built. The engine is battle-tested. The final integration is the next logical step. The multiverse is not just expanding; it's becoming fully interactive.