That error means pip downloaded the CLIP source archive from GitHub and then failed while preparing its build dependencies: it could not build a wheel from that sdist. It surfaces during the "getting requirements to build wheel" phase, before CLIP's own code is compiled. The direct cause is almost always the archived commit's broken packaging metadata combined with modern pip's isolated build environment. The practical fix is to install a patched, prebuilt replacement (open_clip_torch or clip-anytorch) instead of the archive, not to debug the ZIP itself.
How pip turns a GitHub archive into a failing build
When you run pip install against a URL, pip treats the served file as a source distribution. A GitHub archive endpoint delivers a raw ZIP of the repository at one commit, not a published sdist. GitHub names the download "clip-d50d76d" with no .zip or .tar.gz suffix, and that filename is the first fracture point. pip infers the archive type from content, but the missing extension and the missing static directory confuse some tooling paths.
The harder failure comes later. Modern pip (since v19, and stricter after v23) builds packages in isolation. It creates a temporary virtual environment, installs only the build-system requirements declared in pyproject.toml, and then runs the backend's get_requires_for_build_wheel hook. That hook executes setup.py's setup() call far enough to declare extra build requirements. OpenAI's archived CLIP repository predates PEP 517/518 hygiene. Its setup.py imports packages at module load, can reach for local paths and bundled assets, and calls into dependencies that are absent from the clean build environment. pip therefore fails before compilation, which is why the message names requirements and wheel preparation rather than gcc.
Underneath sits a runtime problem that surfaces immediately afterward for anyone who gets past metadata. CLIP's requirements pin torch and torchvision loosely, and its source calls into C++/CUDA kernels (clip.cpp, the custom torch extension) that must match the installed torch ABI. The commit d50d76d was cut against torch 1.x-era APIs. On current torch and CUDA, the compiled extension either fails to load or crashes on first use. The metadata failure is the messenger; the version skew is the message.
One plain-language summary: pip cannot run the old setup script in its clean sandbox, and even a successful compile would produce an extension incompatible with today's PyTorch.
What changed since that commit was cut
The commit d50d76daa670286dd6cacf3bcd80b5e4823fc8e1 is a fixed point in time, not a maintained release. OpenAI archived the repository, so no commit after it changes packaging. Meanwhile the installation stack moved underneath it. pip defaults to build isolation, wheel strings changed, setuptools tightened its handling of implicit imports, and Python 3.11 and 3.12 removed distutils assumptions older setup scripts relied on.
PyTorch also moved. Wheels for current CUDA versions ship new C++ ABI expectations, and torch removed or renamed APIs the old CLIP extension used. The combination means the archive is a historical artifact with two independent incompatibilities: packaging metadata for the build phase and compiled-kernel ABI for the runtime phase.
The community response is the practical signal. open_clip_torch repackages the same model family with modern pyproject metadata, maintained wheels, and torch-version matrix testing. clip-anytorch strips the hard torch pin so the package installs alongside whatever torch you already have. Both are published on PyPI as sdists and wheels, so pip never has to build from a GitHub archive. The counterintuitive detail: the error you are chasing is easier to fix than to understand, because the replacement libraries are better-maintained than the original.
| Approach | Package source | Build isolation behavior | Torch compatibility | Maintenance status | Best fit |
|---|---|---|---|---|---|
| GitHub archive of d50d76d | Raw ZIP from GitHub | Fails in get_requires_for_build_wheel | Pinned to old torch ABI | Archived, no fixes | Historical reproduction only |
| OpenAI CLIP via PyPI sdist | Published sdist | Depends on current setuptools support | Same old ABI risk on compile | Published but stale | Rarely worth it over alternatives |
| open_clip_torch | PyPI wheel/sdist | Clean metadata, no script imports | Tested across recent torch releases | Actively maintained | Default replacement |
| clip-anytorch | PyPI wheel | Clean, no torch pin | Installs with existing torch | Maintained fork | Existing environments with fixed torch |
| Manual clone plus patch | Editable local tree | You control the environment | Whatever you compile against | You maintain it | Debugging, custom forks |
| Docker image with pinned torch | Prebuilt image | Pre-solved inside image | Locked pair of torch and CLIP | Image maintainer | Reproducible production |
Edge cases that reproduce this failure
A handful of conditions predict the error with high reliability. Recognizing them saves hours.
No C++ compiler or CUDA toolkit: even fixed metadata fails at extension build, usually with a different but adjacent message. Python 3.12 environment: older setuptools and distutils expectations in the archived setup script break metadata collection outright. Corporate proxy or offline mirror: pip cannot reach the isolated build environment's package index, so the requirements hook fails with network errors that mask as metadata errors. pip older than 21: build isolation behaves inconsistently, and you may see the error under a different label. Conda-installed torch with unusual ABI or a CPU-only build: metadata might pass, but the compiled extension refuses to load. Windows with MSVC missing the right toolset: the archive's extension build cannot find a compatible compiler.
A less obvious edge case is pip's cache. A partially downloaded archive or a cached failed build can replay the same error after you have fixed the environment. Adding --no-cache-dir to the command forces a clean fetch and build attempt.
Misconceptions worth retiring
The first misconception is that the ZIP is corrupt. It is not; the same bytes download consistently and the SHA-1 in the URL fragment is version metadata, not a checksum you must verify. The failure is behavioral, produced by running an old setup script inside a clean modern environment.
The second is that the message points at your code. It does not name your project, because it has not reached your project. It names the URL and the wheel phase, meaning the failure belongs entirely to the archive and pip's build isolation.
The third is that pip install with --no-build-isolation is the universal escape hatch. It does bypass isolation, but it also lets the old setup script import whatever is lying around in your environment, so results vary by machine. It occasionally works and often fails differently, which makes it a poor recommendation without caveats.
The fourth is that upgrading pip to the newest version makes the error worse. Some users suspect this and downgrade. Newer pip enforces clearer rules, so the error becomes more legible, not more common. The incompatibility was always there.
The professional caveat: when the star count of the original repo leads you to trust it, remember that stars measure past interest, not current installability. Archived repositories do not respond to breaking changes in their dependents.
A practical sequence that resolves it
Work in order, because the cheapest fix is first and the most invasive is last. The reconciliation of paths: if you need the CLIP model family for inference or training, the replacements are the destination with probability above 90%; the archive itself is only worth repairing for exact historical reproduction.
The replacement path. Install open_clip_torch with a direct pip command, optionally passing an index URL that hosts CUDA-matched torch wheels so pip selects a compatible pair in one resolution. If your environment already has a fixed torch, install clip-anytorch so pip will not touch it. Then load the model through the open_clip API and confirm with a single forward pass. This is the path most readers should stop at.
The isolation bypass path, for debugging. If you must attempt the archive, run pip with --no-build-isolation inside an environment that already has setuptools, wheel, torch, torchvision, and a compiler configured. Expect further version-skew errors after metadata passes; treat each as a signal about torch API drift, not as a new bug.
The manual patch path, for forks. Clone the repository at the commit, add a minimal pyproject.toml declaring build-system requirements, replace imports in setup.py with lazy ones, and install in editable mode. This is legitimate engineering work with a measurable time cost, appropriate only if the original code is the object of study.
Thresholds to set expectations: replacement installs typically complete in minutes with no compile step; archive patch attempts usually take an afternoon and may not converge on modern torch; a clean Docker image with a matched torch and open_clip pair eliminates the class of errors permanently.
Red flag: a tutorial that says "just pip install the GitHub URL" without a torch version instruction. Red flag: a script that pins torch below 2.0 to make old CLIP work; you inherit that pin everywhere. Red flag: running --no-build-isolation and then assuming the next error is unrelated. Red flag: copying a requirements.txt entry with the full GitHub URL, which bakes the failure into CI. Red flag: ignoring a wheel-versus-sdist mismatch across your team's machines.
Timeline: from command to fix
| Stage | What pip does | Typical symptom | Where to intervene |
|---|---|---|---|
| Fetch | Downloads the archive from the GitHub URL | Quick or silent | Check network and cache first |
| Isolated env creation | Builds a temporary venv with declared build deps | Seconds pass, little output | Tune pip verbosity to observe |
| get_requires_for_build_wheel | Runs setup.py to declare build requirements | Your exact error appears here | Switch to a prebuilt package |
| Wheel build | Compiles the custom torch extension | Errors about compiler or CUDA if reached | Install matching toolchain |
| Runtime import | Loads the compiled extension into torch | ABI errors or crashes on first call | Align torch version or use open_clip |
| Ongoing use | Every environment rebuild repeats the process | CI failures stack | Replace URL with a PyPI package pin |
The timeline's value is placement: the failure you see sits at the third stage, which means compiler fixes and torch downgrades are premature responses until you decide between replacement and repair.
Limits of what this explains
No single command fixes every instance, because environments differ in compiler, CUDA runtime, Python version, and pip flags. The archive's exact behavior also depends on package index availability at build time, so a build that succeeds today may fail after an upstream dependency deprecation. The safe claim is narrower: a modern prebuilt replacement removes the wheel-build phase from your install entirely.
Replacement libraries are not drop-in identical to the original API. Checkpoints load differently, some layers and preprocessing calls differ, and one or two classes may be renamed. Verify with a forward pass and a feature comparison before committing a dependency change to a pipeline. If downstream code imports reach into the original repository's private modules, the replacement will require a small refactor that the test suite should catch.
The general lesson: raw GitHub archives are not packages. They carry no release discipline and no promise that their metadata will satisfy tomorrow's pip. Pin published packages, record the torch-and-CUDA pair you validated, and prefer maintained packages shipped by PyPI.
If the workflow involves clinical imaging or medical AI, treat this as general engineering education only. This article is not a diagnosis, treatment plan, or safety certification for any medical system. Validate model outputs and software versions with a qualified local professional before clinical use.