comfy-build-pins

Diagnose and resolve pip dependency conflicts in comfy-build.yaml pipDependencies before building.

961|148|Updated Apr 14, 2024
One-click install
npx skills add https://github.com/Comfy-Org/comfy-cli --skill comfy-build-pins
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: comfy-build-pins
Source: https://github.com/Comfy-Org/comfy-cli/tree/main/comfy_cli/skills/comfy-build-pins
Command: npx skills add https://github.com/Comfy-Org/comfy-cli --skill comfy-build-pins

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

ComfyUI cloud builds frequently fail on dependency conflicts caused by inherited pip freeze pins in comfy-build.yaml, and each failed build costs minutes. This Skill explains which pins to delete, which to keep, and how to predict conflicts from requirements files before spending a build.

Core Features & Use Cases

  • Pin triage rules: Identifies lines to always delete (torch, torchvision, torchaudio, triton, xformers, nvidia-*, platform-specific wheels) and rules for pins worth keeping, such as numpy/scipy and opencv-python/opencv-python-headless pairs that must move together.
  • Pre-build conflict prediction: Concatenates ComfyUI core and custom node pack requirements.txt files (cloning packs at their pinned gitRef when needed) and resolves them with uv pip compile against the target Python version and manylinux platform tag.
  • Failure pattern recognition: Detects three conflict shapes in requirements text — two packages providing one import, a ceiling pin on a shared package, and a pack pinned far below the install's running versions.
  • Use Case: Before submitting a comfy-build, clone each declared pack at its pinned ref, concatenate requirements files, strip torch-stack lines, and run uv pip compile with the base image's Python and manylinux_2_34 platform to surface the real blocker without spending a build.

Quick Start

Ask the AI to review the pipDependencies in your comfy-build.yaml and predict any dependency conflicts using the comfy-build-pins reference before starting the build.

Frequently Asked Questions about comfy-build-pins

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I fix dependency conflicts in a comfy-build.yaml?

Empty the pipDependencies section first, since the inherited pip freeze overrides what packages declare and forces source-platform versions onto the build. Keep a pin only when a pack's docs demand it or a known failure requires it, and pin coupled packages like numpy/scipy together.

How do I predict a pip dependency conflict before building?

Concatenate ComfyUI core's requirements.txt with each custom node pack's requirements.txt, cloning packs at their pinned gitRef. Strip torch-stack and platform-specific lines, then run uv pip compile with the base image's Python version and the manylinux platform tag the build uses.

Why should torch pins be removed from pipDependencies?

A pin for one torch-stack member replaces the base image's line for it and releases the others, so pinning torch silently un-pins torchvision and torchaudio. The build owns torch, torchvision, and torchaudio, so they should always be deleted from overrides.

Why does a build fail even when uv pip compile resolves cleanly?

A clean resolve only means constraints are satisfiable, not that versions are compatible at runtime. A ceiling pin like opencv-python-headless<=4.7.0.72 resolves fine but predates NumPy 2 and aborts at import, and binaries compiled against other versions fail invisibly to the resolver.

Does the build read dependencies declared in pyproject.toml?

No, the build only resolves requirements.txt files — ComfyUI's own plus one per pack. A constraint declared only in a pack's pyproject.toml is never applied, and a pack shipping no requirements.txt declares nothing and gets whatever other packs pulled in.

What are the limitations of predicting build conflicts from requirements files?

Static analysis cannot detect binaries compiled against a different library version, which fail at import despite satisfied constraints. Pack install scripts also run at build time outside the lock, so the final environment can differ from the one you resolved.