pypa/pip · error · MetadataInconsistent

Requested {ireq} has inconsistent Name: expected {f_val!r},

Error message

Requested {ireq} has inconsistent Name: expected {f_val!r}, but metadata has {m_val!r}

What it means

Raised as MetadataInconsistent for the Name field when the canonicalized project name read from a PEP 658 .metadata file does not match the name of the InstallRequirement. At prepare.py:546-549, _fetch_metadata_using_link_data_attr compares canonicalize_name(metadata_dist.raw_name) to canonicalize_name(req.req.name); a mismatch aborts before the metadata is used for resolution. raw_name falls back to the requirement name only if the Name field is absent, which the code notes should never happen.

Source

Thrown at src/pip/_internal/operations/prepare.py:547

            self._download,
            hashes=metadata_link.as_hashes(),
        )
        with open(metadata_file.path, "rb") as f:
            metadata_contents = f.read()
        # (3) Generate a dist just from those file contents.
        metadata_dist = get_metadata_distribution(
            metadata_contents,
            req.link.filename,
            req.req.name,
        )
        # (4) Ensure the Name: field from the METADATA file matches the name from the
        #     install requirement.
        #
        #     NB: raw_name will fall back to the name from the install requirement if
        #     the Name: field is not present, but it's noted in the raw_name docstring
        #     that that should NEVER happen anyway.
        if canonicalize_name(metadata_dist.raw_name) != canonicalize_name(req.req.name):
            raise MetadataInconsistent(
                req, "Name", req.req.name, metadata_dist.raw_name
            )
        return metadata_dist

    def _fetch_metadata_using_lazy_wheel(
        self,
        link: Link,
    ) -> BaseDistribution | None:
        """Fetch metadata using lazy wheel, if possible."""
        # --use-feature=fast-deps must be provided.
        if not self.use_lazy_wheel:
            return None
        if link.is_file or not link.is_wheel:
            logger.debug(
                "Lazy wheel is not used as %r does not point to a remote wheel",
                link,
            )
            return None

View on GitHub (pinned to d7d0d0a394)

Solutions

Clear caches: pip cache purge and any HTTP cache, then retry.
Reinstall from the official index: pip install --index-url https://pypi.org/simple/ <pkg>.
Verify the package name spelling and any aliasing in your requirements file.
Pin the exact version and, if possible, a direct wheel URL with a hash to bypass sidecar metadata.

Example fix

# before: requirement name mismatches the served metadata Name
pip install mypkg  # index serves metadata Name 'otherpkg'

# after: correct name / official index
pip install --index-url https://pypi.org/simple/ otherpkg

Defensive patterns

Strategy: validation

Validate before calling

from pip._vendor.packaging.utils import canonicalize_name

def validate_metadata_name(metadata_name, requirement_name):
    if canonicalize_name(metadata_name) != canonicalize_name(requirement_name):
        raise ValueError(
            f"metadata Name {metadata_name!r} != requirement name {requirement_name!r}"
        )

Type guard

from pip._vendor.packaging.utils import canonicalize_name
def names_canonical_equal(a: str, b: str) -> bool:
    return canonicalize_name(a) == canonicalize_name(b)

Prevention

Use the canonical package name in requirements files.
Pin exact versions from a trusted index to avoid metadata-name mismatches.
Purge caches on first occurrence to rule out client-side staleness.

When it happens

Trigger: The index's .metadata file for a link declares a Name that canonicalizes differently from the requirement name pip is resolving. E.g. requirement is 'MyPkg' but the .metadata Name is 'otherpkg'. Distinct from the sidecar-vs-wheel check (109); this compares sidecar Name against the requirement itself.

Common situations: A misconfigured index mapping a requirement to the wrong .metadata file, a renamed package, or a CDN cache key collision serving the wrong metadata. Also a typo or alias mismatch in a private index.

Related errors

AI-assisted analysis of pypa/pip@d7d0d0a394 (2026-08-04). Data as JSON: /data/errors/de68125deb486f04.json. Report an issue: GitHub.