pypa/pip · error · InstallationError

Editable requirements are not allowed as constraints

Error message

Editable requirements are not allowed as constraints

What it means

pip raises this when an editable requirement (-e) is combined with the constraint flag. Constraint files are meant to restrict versions without installing; editable installs are development installs that are always installed. The two concepts are mutually exclusive, so pip refuses the combination at the top of install_req_from_editable().

Solutions

Remove any -e lines from your constraint file; constraint files should only contain version specifiers like 'package>=1.0,<2.0'
If you need an editable install, put it in a requirements file (-r) or on the command line, not in a constraint file (-c)
Separate editable dev dependencies into their own requirements file and only use plain name==version pins in constraint files

Example fix

# before — constraints.txt contains:
#   -e ./myproject

# after — constraints.txt contains:
#   myproject

Defensive patterns

Strategy: validation

Validate before calling

# Before passing an editable requirement, ensure it is not marked as a constraint
if constraint and editable_req.startswith("-e") or is_editable_line:
    raise ValueError("Editable requirements cannot be used as constraints")

# Or simply: never call install_req_from_editable(..., constraint=True)

Type guard

def is_safe_constraint_line(line: str) -> bool:
    """Returns False if the line would trigger the editable-as-constraint error."""
    stripped = line.strip()
    return not (stripped.startswith("-e ") or stripped.startswith("--editable"))

Try / catch

from pip._internal.exceptions import InstallationError

try:
    ireq = install_req_from_editable(req, constraint=False)
except InstallationError as e:
    if "not allowed as constraints" in str(e):
        # retry without constraint flag, or move to a requirements file
        ireq = install_req_from_editable(req, constraint=False)
    else:
        raise

Prevention

Never put -e lines in a constraint file (-c); use them only in requirements files (-r)
When refactoring a requirements file into a constraint file, strip all -e lines first
Validate constraint files with a script that checks no line starts with -e or --editable

When it happens

Trigger: Calling install_req_from_editable(editable_req, constraint=True), or running pip with a constraint file (-c constraints.txt) that contains a line starting with -e (editable). Also triggered when install_req_from_parsed_requirement forwards parsed_req.constraint=True into the editable path.

Common situations: A constraints.txt file mistakenly contains '-e ./myproject' lines instead of plain version pins. Mixing editable development installs with a constraint file in CI. Refactoring a requirements file into a constraint file without removing -e lines.

Related errors

AI-assisted analysis of pypa/pip@f399c37189 (2026-08-08). Data as JSON: /api/errors/14335efc1ae48df2. Report an issue: GitHub.

Appendix: source

Thrown at src/pip/_internal/req/constructors.py:265

    return RequirementParts(req, link, None, extras_override)


# ---- The actual constructors follow ----


def install_req_from_editable(
    editable_req: str,
    comes_from: InstallRequirement | str | None = None,
    *,
    isolated: bool = False,
    hash_options: dict[str, list[str]] | None = None,
    constraint: bool = False,
    user_supplied: bool = False,
    config_settings: dict[str, str | list[str]] | None = None,
) -> InstallRequirement:
    if constraint:
        raise InstallationError("Editable requirements are not allowed as constraints")

    parts = parse_req_from_editable(editable_req)
    return InstallRequirement(
        parts.requirement,
        comes_from=comes_from,
        user_supplied=user_supplied,
        editable=True,
        link=parts.link,
        constraint=constraint,
        isolated=isolated,
        hash_options=hash_options,
        config_settings=config_settings,
        extras=parts.extras,
    )


def _looks_like_path(name: str) -> bool:
    """Checks whether the string "looks like" a path on the filesystem.

View on GitHub (pinned to f399c37189)