Python resolution read one thing at a time: the solver named one missing
index page or one version's metadata, pnpm fetched it, and the solver
ran again. Each version's metadata came out of the whole wheel, which
was downloaded and handed to the interpreter.
Resolution now reads the PEP 658 metadata file an index publishes
beside a wheel, checked against the SHA-256 the page published and
cached under `python-metadata-v1` for offline resolutions. Indexes that
publish none or no SHA-256 for it, and offline resolutions without a
cached file, still read the wheel. Installing still reads each wheel's
own metadata and re-solves the lockfile against it. Wheels are downloaded only for the selected releases, several
at a time. A build environment, which installs straight from a
resolution, fetches its selected wheels the same way.
The resolve loop also reads ahead: the index pages of everything a
requirement or a read metadata file names, and the metadata of the
version the solver will most likely pick. Reads run through `Fetcher`,
which borrows only the client, the index, and the config, so they stay
in flight while the registry is busy with a git clone, an sdist build,
or a wheel download. A distribution any requirement takes from a direct
URL is never read from the index, and a backtrack forgets what the
restored state lacks. What the solver asks for is checked as before; a
wrong guess costs a read.
The PEP 658 helpers pnpr already had move into `pnpm-python-resolver`,
which both now use.
On a 10-dependency project against PyPI, `install --lockfile-only` went
from 39-56 s to 4-5 s and a cold `install` from 25 s to 15 s.
Zoltan Kochan
0a286e7088