Design a Version-Aware Package Download Service That Fetches Missing Dependencies

Design a download service for versioned software packages. A user asks for a specific version of a package, for example Python 2.7. Some of the packages that this version depends on are missing from the user's machine, and the service must find and download those as well, so that the requested version can be installed and run. The part that is hardest to explain well, and the one to make most precise, is the dependency lookup: how the service decides which version of each dependency is needed. ```hint Metadata versus bytes Deciding what to fetch needs only small descriptions of packages and their dependencies, while the packages themselves can be large. Consider storing and serving the two differently. ``` ```hint Ranges, not names A dependency usually names a range of acceptable versions rather than one version. Walk through a case where the version already on the machine does not satisfy what the new package needs. ``` ### Constraints and Clarifications - Not given: the number of packages and versions, package sizes, the number of client machines, how dependencies declare versions, and whether two versions of one package can be installed side by side. Ask, or state your assumptions. ### Clarifying Questions - Do dependencies name exact versions, or ranges such as "at least 1.2 and below 2.0"? - Can two versions of the same package be installed on one machine at the same time? - Does the client tell the service what is already installed, or does the client do the resolution itself using metadata from the service? - Are packages platform-specific (operating system, CPU architecture), so that one version has several builds? - Can a published version ever be changed or withdrawn? - How many machines download, how large are packages, and do many machines in one location fetch the same package at once? ### What a Strong Answer Covers - A data model for packages, versions, builds and dependency constraints, with immutable published versions and content hashes - A precise resolution algorithm: transitive dependencies, a version choice that satisfies every constraint, reuse of what is installed, detection of conflicts and cycles, and a deterministic result - How the plan follows from the machine's current state, and how downloads and installs are ordered, verified and made atomic - Where resolution runs (client or server) and the trade-offs of each, plus caching and distribution of large artifacts - Failure handling and observability: interrupted downloads, checksum mismatches, unresolvable requests, withdrawn versions ### Follow-up Questions - Two packages the user wants need incompatible versions of the same library. What does the service do? - A published version turns out to be broken. How do you withdraw it without breaking machines that already depend on it? - Thousands of machines in one data center request the same large package within a minute. How do you protect the origin? - How do you guarantee that a machine set up months from now gets exactly the same versions as one set up today?