omnipkg
Advanced tools
Runtime Hypervisor. Run infinite Python package & interpreter versions concurrently in one environment in milliseconds.
Run infinite Python package & interpreter versions concurrently in one environment in milliseconds.
omnipkg is not just another package manager. It's an intelligent, self-healing runtime orchestrator that breaks the fundamental laws of Python environments. For 30 years, developers accepted that you couldn't run multiple Python versions in one script, or safely switch C-extensions like NumPy mid-execution. Omnipkg proves this is no longer true.
Born from a real-world nightmareโa forced downgrade that wrecked a production environmentโomnipkg was built to solve what others couldn't: achieving perfect dependency isolation and runtime adaptability without the overhead of containers or multiple venvs.
Multi-version installation tests run every 3 hours. Live results here.
The Multi-Version Nightmare is Over: Modern projects are messy. You need tensorflow==2.10 for a legacy model but tensorflow==2.15 for new training. A critical library requires numpy==1.21 while your latest feature needs numpy==2.0. Traditional solutions like Docker or virtual environments force you into a painful choice: duplicate entire environments, endure slow context switching, or face crippling dependency conflicts.
The Multi-Interpreter Wall is Gone: Legacy codebases often require older Python versions (e.g., Django on 3.8) while modern ML demands the latest (Python 3.11+). This forces developers to constantly manage and switch between separate, isolated environments, killing productivity.
The omnipkg Solution: One Environment, Infinite Python Versions & Packages, Zero Conflicts, Downtime, or Setup. Faster than UV.
omnipkg doesn't just solve these problemsโit makes them irrelevant.
torch==2.0.0 and torch==2.7.1 in the same script without restarting.This is the new reality: one environment, one script, everything just works.
Our "Quantum Multiverse Warp" demo, validated live in CI across multiple platforms, executes a single script across three different Python interpreters and three package versions concurrently in the same environment. The hot worker performance isn't just fast; it redefines what's possible for high-performance Python automation.
| Task (Same Script, Same Environment) | Hot Worker Execution |
|---|---|
| ๐งต Thread 1: Python 3.9 + Rich 13.4.2 | โ 2.2ms |
| ๐งต Thread 2: Python 3.10 + Rich 13.6.0 | โ 2.3ms |
| ๐งต Thread 3: Python 3.11 + Rich 13.7.1 | โ 2.3ms |
| ๐ Total Concurrent Runtime | 2.3ms |
| โฑ๏ธ Total Test Duration (with setup) | 2.14s |
Platform-Specific Performance:
| Platform | Hot Worker Benchmark | Total w/ Setup | CI Link |
|---|---|---|---|
| ๐ง Linux | 3.8ms avg (3.2-4.5ms range) | ~580ms | View CI |
| ๐ macOS | 2.3ms avg (2.2-2.3ms range) | 2.14s | View CI |
The numbers that matter are the hot worker benchmarks (sub-5ms). This is the actual execution time for running code across three concurrent Python interpreters with three different package versions. The "Total w/ Setup" includes one-time initialization:
Why This Is Revolutionary:
This isn't just a speedup; it's a paradigm shift. What traditionally takes minutes with Docker or complex venv scripting, omnipkg accomplishes in milliseconds. This isn't a simulation; it's a live, production-ready capability for high-performance Python automation.
Our production benchmark follows industry-standard practices:
Key Achievement: The hot worker performance (2-4ms) represents the actual overhead of omnipkg's multiverse orchestration. Once warmed up, switching between Python interpreters and package versions is faster than most function calls.
Don't believe it? See the live proof, then run Demo 8 to experience it yourself:
uv pip install omnipkg && omnipkg demo
# Select option 8: ๐ Quantum Multiverse Warp
Live CI Output from Multiverse Benchmark:
โก Phase 3: PRODUCTION BENCHMARK (hot workers, concurrent execution)
----------------------------------------------------------------------------------------------------
[T1] โก Benchmarking Python 3.9 + Rich 13.4.2...
[T1] โ
Benchmark: 2.2ms
[T2] โก Benchmarking Python 3.10 + Rich 13.6.0...
[T2] โ
Benchmark: 2.3ms
[T3] โก Benchmarking Python 3.11 + Rich 13.7.1...
[T3] โ
Benchmark: 2.3ms
====================================================================================================
๐ PRODUCTION BENCHMARK RESULTS
====================================================================================================
Thread Python Rich Warmup Benchmark
----------------------------------------------------------------------------------------------------
T1 3.9 13.4.2 3.4ms 2.2ms
T2 3.10 13.6.0 3.0ms 2.3ms
T3 3.11 13.7.1 3.5ms 2.3ms
----------------------------------------------------------------------------------------------------
โฑ๏ธ Sequential time (sum of all): 6.8ms
โฑ๏ธ Concurrent time (longest one): 2.3ms
====================================================================================================
๐ฏ PERFORMANCE METRICS:
----------------------------------------------------------------------------------------------------
Warmup (cold start): 3.3ms avg
Benchmark (hot workers): 2.3ms avg
Range: 2.2ms - 2.3ms
Speedup (warmupโhot): 1.5x
Concurrent speedup: 2.93x
----------------------------------------------------------------------------------------------------
๐ BENCHMARK COMPLETE!
โจ KEY ACHIEVEMENTS:
โ
3 different Python interpreters executing concurrently
โ
3 different Rich versions loaded simultaneously
โ
Hot worker performance: sub-50ms execution!
โ
Zero state corruption or interference
โ
Production-grade benchmark methodology
โฑ๏ธ Total test duration: 2.14s
๐ This is IMPOSSIBLE with traditional Python environments!
For CI/CD Pipelines:
For Development:
This is the new reality: one environment, one script, everything just works โ and it's blazing fast.
Omnipkg treats your environment as a State Engine โ a deterministic, rebuildable artifact rather than a collection of installed files. Two commands drive this:
8pkg export โ Snapshot your environment8pkg export
Scans all registered interpreters and writes two files:
<venv>/.omnipkg/omnipkg.lock โ full environment inventory including interpreter registry, active packages, and bubble state per Python version~/.config/omnipkg/locks/states/sha256_<hash>.toml โ a privacy-scrubbed, path-free cryptographic fingerprint of your environment (safe to commit or share)If the environment has changed since the last export, the SHA transitions automatically:
๐ Environment changed โ updating lock file
sha256:aaaaaa... โ sha256:bbbbbb...
If nothing changed, it's a no-op.
8pkg sync โ Rebuild or verify from a lock file8pkg sync
Runs an interactive flow. Auto-selects the most recent lock file for the current environment, shows a full sync plan across all registered interpreters, then computes a live SHA and compares it against the lock.
If the environment already matches:
โ
Environment already matches lock file (sha256:bbbbbb...).
What would you like to do?
[1] Exit โ nothing to do (default)
[2] Rebuild anyway
[3] Sync from a different lock file
[4] Manage lock files (delete old ones)
If the environment has drifted:
โ ๏ธ This will DESTROY and rebuild the listed python environments.
Proceed? (y/N):
The destructive rebuild warning is explicit โ sync is not a partial patch, it fully reconstructs all listed interpreter environments to match the lock exactly.
--pick)If you have multiple environments or historical snapshots:
8pkg sync --pick
Presents a numbered list of every lock file Omnipkg knows about, grouped by environment:
โโ my_env โโ
1) <venv>/.omnipkg/omnipkg.lock
python: 3.11 9 interpreter(s) 918 active packages โ most recent
โโ ? โโ
2) sha256_bbbbbb...toml 9 interpreters 918 pkgs 2026-04-16
3) sha256_aaaaaa...toml 9 interpreters 826 pkgs 2026-04-14
โโ used by: other_env โโ
4) sha256_cccccc...toml 3 interpreters 152 pkgs 2026-04-06
Select by number, or [m] to manage/delete old states.
| Layer | Location | Contains | Shareable? |
|---|---|---|---|
| Local lock | <venv>/.omnipkg/omnipkg.lock | Paths, env kind, distro, venv origin | No |
| Canonical state | ~/.config/omnipkg/locks/states/ | Package hashes, ABI tags, arch, Python version | Yes โ zero PII |
The canonical SHA is deterministic: same packages + same arch + same Python patch version always produces the same hash, regardless of machine or user. Two machines can confirm environment parity by comparing SHAs without exchanging any local path data.
CI flags and --yes / -y are not yet implemented โ sync is currently interactive only. For unattended use, pipe input directly:
echo "y" | 8pkg sync
Non-interactive flag support is planned for a future release.
### 2. Intelligent Script Runner (`omnipkg run`) [](https://github.com/1minds3t/omnipkg/actions/workflows/old_rich_test.yml)
`omnipkg run` is an intelligent script and CLI executor that **automatically detects and fixes** dependency errors using bubble versionsโwithout modifying your main environment.
## What is `omnipkg run`?
Think of it as a "smart wrapper" around Python scripts and CLI commands that:
1. **Tries to execute** your script or command
2. **Detects errors** (ImportError, ModuleNotFoundError, version conflicts)
3. **Finds the right version** from existing bubbles or creates new ones
4. **Re-runs successfully** in millisecondsโall automatically
**The magic:** Your broken main environment stays broken, but everything works anyway.
## Two Modes of Operation
### Mode 1: Script Execution (`omnipkg run script.py`)
Automatically heals Python scripts with dependency conflicts:
```bash
$ python broken_script.py
AssertionError: Incorrect rich version! Expected 13.4.2, got 13.7.1
$ omnipkg run broken_script.py
๐ Runtime version assertion failed. Auto-healing...
- Conflict identified for: rich==13.4.2
๐ ๏ธ Installing bubble for rich==13.4.2...
โก HEALED in 16,223.1 ฮผs (16.2ms)
โ
Script completed successfully!
Performance vs UV:
UV Failed Run : 210.007ms (fails, no recovery)
omnipkg Activation : 16.223ms (succeeds automatically)
๐ฏ omnipkg is 12.94x FASTER than UV!
omnipkg run <command>)Automatically heals broken command-line tools:
# Regular execution fails
$ http --version
ImportError: cannot import name 'SKIP_HEADER' from 'urllib3.util'
# omnipkg run heals and executes
$ omnipkg run http --version
โ ๏ธ Command failed (exit code 1). Starting Auto-Healer...
๐ Import error detected. Auto-healing with bubbles...
โป๏ธ Loading: ['urllib3==2.6.3']
โก HEALED in 12,371.6 ฮผs (12.4ms)
3.2.4
โ
Success!
What happened: The main environment still has urllib3 1.25.11 (broken), but omnipkg run used urllib3 2.6.3 from a bubble to make the command work.
omnipkg run recognizes multiple error patterns:
# Import errors
ModuleNotFoundError: No module named 'missing_package'
ImportError: cannot import name 'SKIP_HEADER'
# Version conflicts
AssertionError: Incorrect rich version! Expected 13.4.2, got 13.7.1
requires numpy==1.26.4, but you have numpy==2.0.0
# C-extension failures
A module compiled using NumPy 1.x cannot run in NumPy 2.0
Analyzes the error and identifies what's needed:
๐ Comprehensive Healing Plan Compiled (Attempt 1): ['rich==13.4.2']
For CLI commands, it includes the owning package:
๐ Analyzing error: ImportError from urllib3
โป๏ธ Loading: ['urllib3==2.6.3']
Checks if the needed version exists:
# Bubble exists - instant activation
๐ INSTANT HIT: Found existing bubble urllib3==2.6.3 in KB
โก HEALED in 12.4ms
# Bubble doesn't exist - create it
๐ ๏ธ Installing bubble for rich==13.4.2...
๐ Bubble: 4 packages, 0 conflicts
โก HEALED in 16.2ms
Re-runs the script/command with the correct versions activated:
๐ omnipkg auto-heal: Wrapping with loaders for ['rich==13.4.2']...
๐ Fast-activating rich==13.4.2 ...
๐ Bubble: 4 packages, 0 conflicts
๐งน Purging 4 module(s) from memory...
๐ Linked 20 compatible dependencies to bubble
โ
Bubble activated
๐ Running target script inside the bubble...
โ
Successfully imported rich version: 13.4.2
After execution, environment is restored to original state:
๐ omnipkg loader: Deactivating rich==13.4.2...
โ
Environment restored.
โฑ๏ธ Swap Time: 35,319.103 ฮผs (35.3ms)
Scenario: Script needs rich==13.4.2 but main environment has rich==13.7.1
$ omnipkg run test_rich.py
๐ Runtime version assertion failed. Auto-healing...
- Conflict identified for: rich==13.4.2
๐ ๏ธ Installing bubble for rich==13.4.2...
- ๐งช Running SMART import verification...
โ
markdown-it-py: OK
โ
rich: OK
โ
mdurl: OK
โ
Pygments: OK
โก HEALED in 16.2ms
โ
Script completed successfully inside omnipkg bubble.
Main environment after execution:
$ python -c "import rich; print(rich.__version__)"
13.7.1 # Still the original version - untouched!
Scenario: httpie broken by urllib3 downgrade to 1.25.11
# Shows the error first
$ http --version
Traceback (most recent call last):
File "/usr/bin/http", line 13, in <module>
from urllib3.util import SKIP_HEADER
ImportError: cannot import name 'SKIP_HEADER' from 'urllib3.util'
# Heals and executes
$ omnipkg run http --version
โ ๏ธ Command 'http' failed. Starting Auto-Healer...
๐ Analyzing error: ImportError from module
- Installing missing package: urllib3
๐ Resolving latest version for 'urllib3'...
๐ INSTANT HIT: Found existing bubble urllib3==2.6.3
๐ [omnipkg loader] Running in Python 3.11 context
๐ Fast-activating urllib3==2.6.3 ...
๐ Bubble: 1 packages, 0 conflicts
๐งน Purging 31 modules for 'urllib3'
โก HEALED in 12.4ms
๐ Re-launching '/usr/bin/http' in healed environment...
3.2.4
โ
Success!
Main environment after execution:
$ python -c "import urllib3; print(urllib3.__version__)"
1.25.11 # Still broken - but who cares? omnipkg run works!
| Operation | Time | Status |
|---|---|---|
| UV failed run | 210.007ms | โ Fails, no recovery |
| omnipkg detection | <1ms | โ Instant |
| omnipkg healing | 16.223ms | โ Creates bubble |
| omnipkg execution | ~35ms | โ Runs successfully |
| Total recovery | ~51ms | 12.94x faster than UV |
| Operation | Traditional | omnipkg run |
|---|---|---|
| Error detection | Manual (minutes) | Automatic (<1ms) |
| Finding fix | Manual research | Automatic KB lookup |
| Applying fix | 30-90s (reinstall) | 12.4ms (bubble activation) |
| Main env impact | โ ๏ธ Modified | โ Untouched |
| Success rate | ~50% (manual) | 100% (automated) |
Traditional approach:
$ pip install old-package==1.0.0
# Breaks 5 other packages
# Spend 30 minutes fixing
omnipkg run approach:
$ omnipkg run script-needing-old-version.py
# Works instantly
# Main environment untouched
Recognizes and fixes:
ModuleNotFoundError โ Installs missing packageImportError โ Fixes import conflictsAssertionError (version checks) โ Switches to correct version๐ Analyzing script for additional dependencies...
โ
No additional dependencies needed
# Or if dependencies are found:
๐ [omnipkg loader] Linked 20 compatible dependencies to bubble
Automatically detects and includes all required dependencies, not just the primary package.
Once a bubble is created, it's instantly available:
# First time - creates bubble
๐ ๏ธ Installing bubble for rich==13.4.2...
โก HEALED in 16.2ms
# Second time - instant activation
๐ INSTANT HIT: Found existing bubble rich==13.4.2
โก HEALED in <1ms
# Run a Python script with auto-healing
omnipkg run script.py
# Pass arguments to the script
omnipkg run script.py --arg1 value1 --arg2 value2
# Run any CLI command with auto-healing
omnipkg run http GET https://api.github.com
# Run tools that depend on specific library versions
omnipkg run pytest
omnipkg run black mycode.py
omnipkg run mypy myproject/
# See detailed healing process
omnipkg run -v script.py
omnipkg runpython script.pyTraditional Workflow (Broken Tool):
1. Tool fails ........................... 0s
2. Debug error (find root cause) ....... 300s (5 min)
3. Research fix ........................ 600s (10 min)
4. Apply fix (reinstall) ............... 60s (1 min)
5. Test fix ............................ 10s
6. Fix breaks other things ............. 1800s (30 min)
Total: 2770s (46 minutes) โ
omnipkg run Workflow:
1. omnipkg run <command> ............... 0.012s (12ms)
Total: 0.012s (12 milliseconds) โ
Speedup: 230,833x faster
# Install omnipkg
uv pip install omnipkg
# Run Demo 7: Script auto-healing
omnipkg demo
# Select option 7
# Run Demo 10: CLI auto-healing
omnipkg demo
# Select option 10
See for yourself how omnipkg run turns minutes of frustration into milliseconds of automated healing.
This healing capability is the foundation for our vision of transparent package management:
# Coming soon: omnipkg intercepts all package managers
$ pip install broken-package==old-version
โ ๏ธ This would break 3 packages in your environment
๐ก๏ธ omnipkg: Creating bubble instead to protect environment
โ
Installed to bubble - use 'omnipkg run' to access
# Everything just works
$ omnipkg run my-script-using-old-version.py
โ
Success (using bubbled version)
$ python my-script-using-new-version.py
โ
Success (using main environment)
The endgame: Infinite package coexistence, zero conflicts, microsecond switchingโall invisible to the user.
omnipkg allows you to switch package versions mid-script and run conflicting dependencies simultaneously. It offers two distinct modes depending on the severity of the dependency conflict:
Traditional Python wisdom says you cannot switch frameworks like PyTorch or TensorFlow without restarting the interpreter. This is true. Their C++ backends (_C symbols) bind to memory and refuse to let go.
What happens if you try to force-switch PyTorch in-process?
# โ THIS CRASHES IN STANDARD PYTHON
import torch # Loads version 2.0.1
# ... try to unload and reload 2.1.0 ...
import torch
# NameError: name '_C' is not defined
The C++ backend remains resident, causing symbol conflicts and segfaults.
Instead of fighting the C++ backend, omnipkg accepts it. We spawn persistent, lightweight worker processes for each framework version.
We ran omnipkg demo (Scenario 11: Chaos Theory) to prove capabilities that should be impossible.
The Challenge: Run TensorFlow, PyTorch, and NumPy (different versions) at the exact same time.
๐ฅ ROUND 1: Truly Concurrent Execution
โก NumPy Legacy โ (0.71ms)
โก NumPy Modern โ (0.71ms)
โก PyTorch โ (0.80ms)
โก TensorFlow โ (1.15ms)
๐ RESULT: 4 Frameworks executed in 1.69ms total wall-clock time.
The Challenge: Kill and respawn a TensorFlow environment 5 times.
The Challenge: Toggle between PyTorch 2.0.1 (CUDA 11.8) and 2.1.0 (CUDA 12.1) doing heavy tensor math.
ROUND | WORKER | VERSION | TIME
-------------------------------------------------------
#1 | torch-2.0.1 | 2.0.1+cu118 | 0.63ms
#2 | torch-2.1.0 | 2.1.0+cu121 | 1570ms (Cold)
#3 | torch-2.0.1 | 2.0.1+cu118 | 0.66ms (Hot)
#4 | torch-2.1.0 | 2.1.0+cu121 | 0.44ms (Hot)
...
#10 | torch-2.1.0 | 2.1.0+cu121 | 0.37ms (Hot)
Best for nested dependencies and libraries that clean up after themselves.
from omnipkg.loader import omnipkgLoader
# Layer 1: NumPy 1.24
with omnipkgLoader("numpy==1.24.3"):
import numpy as np
print(f"Outer: {np.__version__}") # 1.24.3
# Layer 2: SciPy 1.10 (Nested)
with omnipkgLoader("scipy==1.10.1"):
import scipy
# Works perfectly, sharing the NumPy 1.24 context
print(f"Inner: {scipy.__version__}")
Best for heavy ML frameworks and conflicting C++ backends.
from omnipkg.isolation.worker_daemon import DaemonClient
client = DaemonClient()
# Execute code in PyTorch 2.0.1
client.execute_smart("torch==2.0.1+cu118", """
import torch
print(f"Running on {torch.cuda.get_device_name(0)} with Torch {torch.__version__}")
""")
# Instantly switch to PyTorch 2.1.0 (Different process, shared memory)
client.execute_smart("torch==2.1.0", "import torch; print(torch.__version__)")
You might think running multiple worker processes consumes massive RAM. It doesn't.
omnipkg uses highly optimized stripping to keep workers lean.
Live omnipkg daemon monitor Output:
โ๏ธ ACTIVE WORKERS:
๐ฆ torch==2.0.1+cu118 | RAM: 390.1MB
๐ฆ torch==2.1.0 | RAM: 415.1MB
๐ฏ EFFICIENCY COMPARISON:
๐พ omnipkg Memory: 402.6MB per worker
๐ฅ vs DOCKER: 1.9x MORE EFFICIENT (saves ~700MB)
โก Startup Time: ~5ms (vs 800ms+ for Docker/Conda)
Don't believe us? Run the torture tests yourself.
omnipkg demo
# Select option 11: ๐ Chaos Theory Stress Test
Available Scenarios:
omnipkg eliminates language barriers with advanced AI localization supporting 24+ languages, making package management accessible to developers worldwide in their native language.
Key Features: Auto-detection from system locale, competitive AI translation models, context-aware technical term handling, and continuous self-improvement from user feedback.
# Set language permanently
omnipkg config set language zh_CN
# โ
Language permanently set to: ไธญๆ (็ฎไฝ)
# Temporary language override
omnipkg --lang es install requests
# View current configuration
cat ~/.config/omnipkg/config.json
Zero setup requiredโworks in your language from first run with graceful fallbacks and clear beta transparency.
omnipkg automatically reorders installations and isolates conflicts, preventing environment-breaking downgrades.
Example: Conflicting torch versions:
omnipkg install torch==2.0.0 torch==2.7.1
What happens? omnipkg reorders installs to trigger the bubble creation, installs torch==2.7.1 in the main environment, and isolates torch==2.0.0 in a lightweight "bubble," sharing compatible dependencies to save space. No virtual environments or containers needed.
๐ Reordered: torch==2.7.1, torch==2.0.0
๐ฆ Installing torch==2.7.1... โ
Done
๐ก๏ธ Downgrade detected for torch==2.0.0
๐ซง Creating bubble for torch==2.0.0... โ
Done
๐ Restoring torch==2.7.1... โ
Environment secure
omnipkg goes beyond simple version tracking, building a deep knowledge base (in Redis or SQLite) for every package. In v1.5.0, this now includes live import validation during bubble creation.
sys.path entries.omnipkg now runs an isolated import test for every single dependency. It detects failures (e.g., absl-py: No module named 'absl_py') and even attempts to automatically repair them, ensuring bubbles are not just created, but are guaranteed to be functional.Example Insight:
omnipkg info uv
๐ KEY DATA for 'uv':
๐ฏ Active Version: 0.8.11
๐ซง Bubbled Versions: 0.8.10
---[ Health & Security ]---
๐ Security Issues : 0
๐ก๏ธ Audit Status : checked_in_bulk
โ
Importable : True
| Intelligence Includes | Redis/SQLite Superpowers |
|---|---|
| โข Binary Analysis (ELF validation, file sizes) | โข 0.2ms metadata lookups |
| โข CLI Command Mapping (all subcommands/flags) | โข Compressed storage for large data |
| โข Security Audits (vulnerability scans) | โข Atomic transaction safety |
| โข Dependency Graphs (conflict detection) | โข Intelligent caching of expensive operations |
| โข Import Validation (runtime testing) | โข Enables future C-extension symlinking |
If an external tool (like pip or uv) causes damage, omnipkg revert restores your environment to a "last known good" state in seconds.
Key CI Output Excerpt:
Initial uv version (omnipkg-installed):uv 0.8.11
$ uv pip install uv==0.7.13
- uv==0.8.11
+ uv==0.7.13
uv self-downgraded successfully.
Current uv version (after uv's operation): uv 0.7.13
โ๏ธ Comparing current environment to the last known good snapshot...
๐ The following actions will be taken to restore the environment:
- Fix Version: uv==0.8.11
๐ Starting revert operation...
โ
Environment successfully reverted to the last known good state.
--- Verifying UV version after omnipkg revert ---
uv 0.8.11
UV is saved, along with any deps!
omnipkg works out of the box with automatic SQLite fallback when Redis isn't available. Redis is optional for enhanced performance.
Typing 8pkg no longer spawns a Python process. A compiled C binary handles routing in under 1ms, compiling itself automatically on first run (MSVC on Windows, gcc/clang on Linux/macOS). For edge cases it can't handle natively, it hands off to the Python dispatcher transparently.
Force Python dispatch if you need to debug:
OMNIPKG_FORCE_PYTHON_DISPATCH=1 8pkg install numpy
Ready to end dependency hell?
uv pip install omnipkg && omnipkg demo
See the magic in under 30 seconds.
omnipkg is a pure Python package (noarch) with no C-extensions, ensuring universal compatibility across all platforms and architectures.
| Platform | Architecture | Status | Installation Notes |
|---|---|---|---|
| Linux x86_64 | x86_64 | โ | Native installation |
| Platform | Architecture | Status | Installation Notes |
|---|---|---|---|
| macOS Intel | x86_64 (Intel) | โ | Native installation |
| macOS ARM64 | ARM64 (Apple Silicon) | โ | Native installation |
| Platform | Architecture | Status | Installation Notes |
|---|---|---|---|
| Windows Server | x86_64 | โ | Latest Server |
| Platform | Architecture | Status | Installation Notes |
|---|---|---|---|
| Debian 12 (Bookworm) | x86_64 | โ | --break-system-packages required |
| Debian 11 (Bullseye) | x86_64 | โ | Standard install |
| Ubuntu 24.04 (Noble) | x86_64 | โ | --break-system-packages required |
| Ubuntu 22.04 (Jammy) | x86_64 | โ | Standard install |
| Ubuntu 20.04 (Focal) | x86_64 | โ | Standard install |
| Platform | Architecture | Status | Installation Notes |
|---|---|---|---|
| Fedora 39 | x86_64 | โ | Standard install |
| Fedora 38 | x86_64 | โ | Standard install |
| Rocky Linux 9 | x86_64 | โ | Standard install |
| Rocky Linux 8 | x86_64 | โ | Requires Python 3.9+ (default is 3.6) |
| AlmaLinux 9 | x86_64 | โ | Standard install |
| Platform | Architecture | Status | Installation Notes |
|---|---|---|---|
| Arch Linux | x86_64 | โ | --break-system-packages required |
| Alpine Linux | x86_64 | โ | Requires build deps (gcc, musl-dev) |
Modern Debian/Ubuntu enforce PEP 668 to protect system packages:
# Use --break-system-packages flag
python3 -m pip install --break-system-packages omnipkg
# Or use a virtual environment (recommended for development)
python3 -m venv .venv
source .venv/bin/activate
pip install omnipkg
EL8 ships with Python 3.6, which is too old for modern pyproject.toml:
# Install Python 3.9 first
sudo dnf install -y python39 python39-pip
# Make python3 point to 3.9
sudo ln -sf /usr/bin/python3.9 /usr/bin/python3
sudo ln -sf /usr/bin/pip3.9 /usr/bin/pip3
# Now install omnipkg
python3 -m pip install omnipkg
Alpine requires build tools for dependencies like psutil:
# Install build tools first
apk add --no-cache gcc python3-dev musl-dev linux-headers
# Then install omnipkg
python3 -m pip install --break-system-packages omnipkg
# Arch uses --break-system-packages for global installs
python -m pip install --break-system-packages omnipkg
# Or use pacman if available in AUR (future)
yay -S python-omnipkg
Supported: Python 3.7 - 3.15 (including beta/rc releases)
Architecture: noarch (pure Python, no compiled extensions)
This means omnipkg runs on any architecture where Python is available:
omnipkg is fully verified on ARM64. This was achieved without needing expensive native hardware by using a powerful QEMU emulation setup on a self-hosted x86_64 runner. This process proves that the package installs and functions correctly on the following ARM64 Linux distributions:
| Platform | Architecture | Status | Notes |
|---|---|---|---|
| Debian 12 (Bookworm) | ARM64 (aarch64) | โ | QEMU Emulation |
| Ubuntu 24.04 (Noble) | ARM64 (aarch64) | โ | QEMU Emulation |
| Ubuntu 22.04 (Jammy) | ARM64 (aarch64) | โ | QEMU Emulation |
| Fedora 39 | ARM64 (aarch64) | โ | QEMU Emulation |
| Rocky Linux 9 | ARM64 (aarch64) | โ | QEMU Emulation |
| Alpine Linux | ARM64 (aarch64) | โ | QEMU Emulation |
This verification acts as a critical pre-release gate, ensuring that any version published to PyPI is confirmed to work for ARM64 users before it's released.
| Azure |
|
Available via UV, pip, conda-forge, Docker, brew, Github, and piwheels. Support for Linux, Windows, Mac, and Raspberry Pi.
-6/6%20Verified-success?logo=linux&logoColor=white){kind=icon}
uv pip install omnipkg
pip install omnipkg
# Add to your project
pixi add omnipkg
# Run globally without installation
pixi global install omnipkg
Official conda-forge (Recommended):
# Using prefix.dev (Ultra-fast resolver)
conda install -c https://prefix.dev/conda-forge omnipkg
# Standard conda-forge
conda install -c conda-forge omnipkg
# Using mamba
mamba install -c conda-forge omnipkg
Personal minds3t channel (Latest features first):
# Using conda
conda install -c minds3t omnipkg
# Using mamba
mamba install -c minds3t omnipkg
Docker Hub (Development + Releases):
# Latest release
docker pull 1minds3t/omnipkg:latest
# Specific version
docker pull 1minds3t/omnipkg:2.0.3
# Development branch
docker pull 1minds3t/omnipkg:main
GitHub Container Registry (Releases Only):
# Latest release
docker pull ghcr.io/1minds3t/omnipkg:latest
# Specific version
docker pull ghcr.io/1minds3t/omnipkg:2.0.3
Multi-Architecture Support:
linux/amd64 (x86_64)linux/arm64 (aarch64)# Add the tap first
brew tap 1minds3t/omnipkg
# Install omnipkg
brew install omnipkg
3.0.0 | Python: 3.9 (Bullseye), 3.11 (Bookworm), 3.13 (Trixie) | View on piwheels
pip3 install omnipkg==3.0.0
Verified Platforms:
https://www.piwheels.org/simple/omnipkg/omnipkg-3.0.0-cp311-cp311-linux_armv7l.whl
For users on Raspberry Pi, use the optimized wheels from piwheels for faster installation:
pip install --index-url=https://www.piwheels.org/simple/ omnipkg
# Clone the repo
git clone https://github.com/1minds3t/omnipkg.git
cd omnipkg
# Install in editable mode (optional for dev)
pip install -e .
omnipkg demo
Choose from:
# Let omnipkg manage your native Python automatically
omnipkg status
# ๐ฏ Your native Python is now managed!
# See available interpreters
omnipkg info python
# Install a new Python version if needed (requires Python >= 3.10)
omnipkg python adopt 3.10
# Hot-swap your entire shell context
omnipkg swap python 3.10
python --version # Now Python 3.10.x
For maximum performance, install Redis:
Linux (Ubuntu/Debian):
sudo apt-get update && sudo apt-get install redis-server
sudo systemctl enable redis && sudo systemctl start redis
macOS (Homebrew):
brew install redis && brew services start redis
Windows: Use WSL2 or Docker:
docker run -d -p 6379:6379 --name redis-omnipkg redis
Verify Redis: redis-cli ping (should return PONG)
Already working in production: Our "Quantum Multiverse Warp" demo proves you can run Python 3.9, 3.10, and 3.11 concurrently in the same script, same environment, in under 6.22 seconds.
Already working in CI: Mid-script interpreter switching now works reliably in automated environments with atomic safety guarantees.
Ensures your bubbles are 100% working and auto heals if they don't.
Learn more about omnipkg's capabilities:
omnipkg commands.omnipkgLoader for dynamic, mid-script version changes.omnipkg uses a dual-license model designed for maximum adoption and sustainable growth:
Commercial inquiries: omnipkg@proton.me
This project thrives on community collaboration. Contributions, bug reports, and feature requests are incredibly welcome. Join us in revolutionizing Python dependency management.
Translation Help: Found translation bugs or missing languages? Submit pull requests with corrections or new translationsโwe welcome community contributions to make omnipkg accessible worldwide.
________________________________________________________________
/ \
| pip: "Version conflicts? New env please!" |
| Docker: "Spin up containers for 45s each!" |
| venv: "90s of setup for one Python version!" |
| |
| omnipkg: *runs 3 Python versions concurrently in 580ms, |
| caches installs in 50ms* |
| |
| "Hold my multiverseโI just ran your entire |
| CI matrix faster than you blinked." |
\________________________________________________________________/
\ ^__^
\ (๐)\_______
(__)\ )\/\
||----w |
|| ||
~ omnipkg: The Multiverse Package Manager ~
FAQs
Runtime Hypervisor. Run infinite Python package & interpreter versions concurrently in one environment in milliseconds.
We found that omnipkg demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago.ย It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
pnpm 11 turns on a 1-day Minimum Release Age and blocks exotic subdeps by default, adding safeguards against fast-moving supply chain attacks.
Security News
The remediated findings include organization permission bugs, stale project access after transfers, OIDC replay edge cases, audit logging gaps, and an IDOR in API token deletion.
Research
/Security News
GitHub account BufferZoneCorp published sleeper packages that later added credential theft, GitHub Actions tampering, fake go wrappers, and SSH persistence.