We use thoth-solver which was introduced in another topic. The tool can extract package metadata that are complete with respect to dependencies in the given point in time. Another component (we call it revsolver) then makes sure data are in sync and up to date. thoth-solver runs in specific restricted container environments to aggregate information about packages (containers are subsequently thrown away). The dependency information is then specific to container environment in which thoth-solver was run in.
package-extract is another component in Thoth; its focus is on analyzing the content of container images, not related to the dependency case discussed.
We check the already existing lock file in the project that the user uses (if any) and recommend a better one only if a better one is found.
Not yet, but we plan to release a limited dump to the community (even the limited dump has few Gi) :
This is an example of an issue we can tell the resolver to avoid by adjusting prescriptions stated earlier. This way, the knowledge about the mentioned package is not lost and the Python community could benefit from such aggregated package issue database.