This is done by catching InstallationError from the underlying
distribution preparation logic. There are three cases to catch:
1. Candidates from indexes. These are simply ignored since we can
potentially satisfy the requirement with other candidates.
2. Candidates from URLs with a dist name (PEP 508 or #egg=). A new
UnsatisfiableRequirement class is introduced to represent this; it is
like an ExplicitRequirement without an underlying candidate. As the
name suggests, an instance of this can never be satisfied, and will
cause eventual backtracking.
3. Candidates from URLs without a dist name. This is only possible for
top-level user requirements, and no recourse is possible for them. So
we error out eagerly.
The InstallationError raised during distribution preparation is cached
in the factory, like successfully prepared candidates, since we don't
want to repeatedly try to build a candidate if we already know it'd
fail. Plus pip's preparation logic also does not allow packages to be
built multiple times anyway.
Pradyun Gedam
Tzu-ping Chung
Nitesh Sharma
Pradyun Gedam