Dependencies Installed in Wrong Environment When `comfy-cli` is Installed with Python Application Managers

[INFCode]

Describe the Bug

Currently, comfy-cli attempts to install dependencies into the environment it is running in. This can lead to incorrect behavior when comfy-cli is installed in a different (virtual) environment than ComfyUI. This situation often occurs when using Python application managers like pipx or uv tool, which isolate CLI tools in their own environments.

To Reproduce

1. Ensure you have a Python application management tool installed (e.g., uv tool).

2. Install comfy-cli using uv:

   uv tool install comfy-cli  
   

   This creates a dedicated environment for comfy-cli.

3. Clone ComfyUI:

   git clone [email protected]:comfyanonymous/ComfyUI.git  
   

4. Create and activate a virtual environment for ComfyUI:

   python3 -m venv comfy-env  
   source ./comfy-env/bin/activate  
   

5. Run comfy install --restore.

Observed behavior: Installation fails, complaining that pip is not available. The error indicates that it's trying to use the Python interpreter from the uv environment rather than the currently activated virtual environment.

6. You want to apply the workaround suggested in #245 and run ensurepip for that Python. Although this fixes the issue itself, the logs would show that dependencies are installed into the comfy-cli environment, which is not the intended behavior.

Expected Behavior

comfy-cli should install dependencies into the virtual environment associated with ComfyUI, or at least respect the currently activated environment.

Nice to Have

• [ ] Terminal output
• [ ] Screenshots

Additional Context

In comfy_cli/command/install.py, sys.executable is used to determine the Python interpreter for pip install. However, this always resolves to the environment in which comfy-cli itself is running—not necessarily the one ComfyUI is intended to use.

A more robust approach might be to resolve python or pip via:

python_path = shutil.which("python", path=os.environ.get("PATH", ""))
pip_path = shutil.which("pip", path=os.environ.get("PATH", ""))

This would respect the user's shell environment and active virtualenv (or other environments like conda), aligning the install target more accurately.

[dosubot[bot]]

Hello @INFCode! 👋 I'm Dosu, your friendly bot here to help you solve bugs, answer questions, and guide you on your journey to becoming a contributor. I'm here while you wait for a human maintainer!

To address the issue of comfy-cli installing dependencies into the wrong environment, you can modify the installation process to target the virtual environment associated with ComfyUI. Here's a suggested approach using the DependencyCompiler class from the comfy_cli.uv module:

1. Identify the ComfyUI Workspace: Use the WorkspaceManager to get the path of the ComfyUI workspace.

2. Install Dependencies in the Correct Environment: Use the DependencyCompiler to compile and install dependencies within the ComfyUI environment.

Here's a code snippet to guide you:

from comfy_cli.workspace_manager import WorkspaceManager
from comfy_cli.uv import DependencyCompiler

def install_dependencies_in_comfyui_env():
    # Get the ComfyUI workspace path
    workspace_manager = WorkspaceManager()
    comfy_path = workspace_manager.workspace_path

    if not comfy_path:
        print("ComfyUI path is not resolved.")
        return

    # Compile and install dependencies in the ComfyUI environment
    dep_compiler = DependencyCompiler(cwd=comfy_path)
    dep_compiler.compile_deps()
    dep_compiler.install_deps()

install_dependencies_in_comfyui_env()

This approach ensures that dependencies are installed in the virtual environment associated with ComfyUI, rather than the environment in which comfy-cli is running. The DependencyCompiler class provides methods like compile_deps and install_deps to manage dependencies effectively ^[1][2][3][4].

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}

[Interpause]

I can confirm same issue with pipx as mentioned by author. I'll test the suggested fix in a fork. @INFCode you mind if I make a PR using your fix if it works?

EDIT: Not sure about the implications of changing sys.executable everywhere (except in the standalone functionality files). Going to just try the standalone method so I might not be trying to fix this.

EDIT 2: Standalone is also broken. Ideally, it should create and use a venv within the comfyui install location itself. I think I will try that approach. Unfortunately, there is no easy way to tell if a pipx or uv environment is active. So I will take the following approach:

• Conda environment is active (CONDA_PREFIX exists): Install into conda environment
• Virtual environment is active: Don't use active virtual environment, look for .venv or venv inside ComfyUI install location instead.
• No active environment: Look for .venv or venv inside install location.

If virtual environment can't be found, it will try and find the system Python, and use that to create a venv.

EDIT 3: Finding the system Python reliably is also hard, so I will create the venv using the --copies option instead, which would copy the active Python.

[Interpause]

The venv & conda approaches seem to work. I haven't tested the impact on other commands besides comfy install and comfy launch, and whether comfy standalone is affected (tho it was broken for me to begin with).

EDIT: forgot to mention comfy launch doesnt activate the conda environment; so some features of conda environments like installing nvcc with it dont work

[geroldmeisinger]

I have a similar issue. Debian wants me to use pipx to install tools in user environment. In order to install packages I have to use quirks like pipx inject comfy-cli mypackage or source ~/.local/pipx/venvs/comfy-cli/bin/activate. But this doesn't really make sense either because the environments should be managed by each installation not comfy-cli itself.