Dependency Isolation Strategies for Cloud Skills

[fbalicchia]

As far as I understand, Cloud Skills run inside their own sandbox and can execute arbitrary code. Suppose I want to run a Python script that requires a library that is not included in the current Python runtime—Cloud is able to install it, so that’s not a problem.

However, suppose I want to use skills provided by different vendors that depend on the same library but require different versions. What is the recommended approach for handling dependencies within skills?

Thanks
--Filippo

[chasewhughes]

Good question — this is the same dependency hell problem that every plugin/extension ecosystem eventually hits, and the answer depends on how Cloud Skills actually execute.

The fundamental tension:

Skill A needs pandas==2.1 and Skill B needs pandas==2.2. If they share a Python runtime, you're stuck. There are a few isolation strategies, ranked by complexity:

1. Virtual environment per skill (lightweight, proven)

Each skill gets its own venv, created at install time. This is what most plugin systems land on:

skills/
├── vendor-a-analytics/
│   ├── SKILL.md
│   ├── requirements.txt        # pandas==2.1
│   └── .venv/                  # isolated environment
├── vendor-b-reporting/
│   ├── SKILL.md
│   ├── requirements.txt        # pandas==2.2
│   └── .venv/                  # isolated environment

The skill runner activates the correct venv before executing each skill's code. This is how tools like pipx handle it, and it works well when skills are independent processes or subprocesses.

Tradeoff: Disk space (each venv duplicates common packages) and startup latency (activating environments). Fine for most use cases.

2. Container per skill (strongest isolation)

If skills can run arbitrary code and you're dealing with untrusted vendors, venvs aren't enough — a malicious skill could escape the venv and access the host filesystem. Container isolation (Docker, Firecracker, gVisor) gives you:

• Full filesystem isolation
• Network policy control (skill can/can't make outbound requests)
• Resource limits (CPU, memory, time)
• Deterministic, reproducible environments

# Each skill ships a Dockerfile or uses a base image
FROM python:3.12-slim
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . /skill
ENTRYPOINT ["python", "/skill/main.py"]

Tradeoff: Cold start latency and orchestration complexity. But if you're already running in the cloud, this is the right call for multi-tenant skill execution.

3. Dependency namespacing (least isolation, most fragile)

Some ecosystems try to vendor dependencies per-skill without full environment isolation (similar to how webpack bundles JS dependencies). In Python this is painful — sys.path manipulation, import hooks, etc. I'd avoid this path. It's brittle and breaks on C extensions.

What I'd recommend for the skills ecosystem:

For the short term: declare dependencies in a standard format (requirements.txt or pyproject.toml in each skill bundle) and document the isolation model. Even if the runtime doesn't isolate today, having explicit dependency declarations means isolation can be added later without breaking existing skills.

For the long term: venv-per-skill for trusted skills, container-per-skill for untrusted/third-party skills. This is the same trust boundary model that package managers like Homebrew (formulae run in your environment) vs. Flatpak (apps run in sandboxes) use.

The worst outcome is the implicit shared runtime with no declared dependencies — because then you can't even detect the conflict until it breaks at runtime.

[mj-deving]

Good breakdown above. Just wanted to add a practical angle from running multi-vendor skill setups.

The venv-per-skill approach works well until you hit skills that need compiled C extensions with conflicting system-level dependencies. Had this exact situation with two skills needing different versions of numpy compiled against different BLAS implementations. Venvs alone didn't cut it because the shared libraries clashed at the linker level.

What ended up working for me was a hybrid: venvs for trusted/simple skills, and lightweight containers (via podman) for anything with compiled dependencies or untrusted code. Podman is rootless, so you skip the Docker daemon overhead.

The key thing I'd stress is dependency declaration should be mandatory from day one, even if the runtime doesn't enforce isolation yet. Something like:

# skill.toml or pyproject.toml per skill
[skill]
name = "analytics-widget"
runtime = "python"
isolation = "venv"  # or "container"

[dependencies]
pandas = ">=2.1,<2.3"
numpy = ">=1.26"

This way the skill runner can detect conflicts before they blow up at runtime. You could even build a simple pre-install check that flags version collisions across loaded skills and warns the user.

The worst failure mode isn't a version conflict — it's a silent version conflict where skill A loads skill B's dependency version and produces subtly wrong results. Explicit declarations make that impossible.