Test cases that require a single module should use this URL, and test cases
that require a feed should use PUPPET_MODULE_URL_2. Doing so shifts
load away from the Puppet Forge.

Why do both URLs exist? Because simulating the Puppet Forge’s behaviour is
unreasonably hard.

Pulp Fixtures is designed to create data that can be hosted by a simple HTTP
server, such as python3-mhttp.server. A dynamic API, such as the Puppet
Forge API, cannot be simulated. We could create a static tree of files, where
that tree of files is the same as what the Puppet Forge would provide in
response to a certain HTTP GET request. However:

The Puppet Forge API will inevitably change over time as bugs are fixed
and features are added. This will make a static facsimile of the Puppet Forge
API outdated. This is more than a mere inconvenience: outdated information is
also confusing!

Without an in-depth understanding of each and every file the Puppet Forge
yields, it is probable that static fixtures will be wrong from the get-go.

Though the Puppet Forge API supports a variety of search types, Pulp
only supports the ability to search for modules. As a result, it is
impossible to create a Puppet repository and sync only an exact module or
set of modules. This query intentionally returns a small number of Puppet
modules. A query which selected a large number of modules would produce
tests that took a long time and abused the free Puppet Forge service.

Beware that the Pulp API takes given Puppet queries and uses them to construct
URL queries verbatim. Thus, if the user gives a query of “foo bar”, the
following URL is constructed: