Resolve sdists and pep517

[techalchemy]

• Adds fallback resolution using sdists when building wheels is not possible (which it is not always possible to do -- see apache-airflow for example)
• Adds pep517 builder backend support to the wheel builder process to try to build wheels using their specified backends
• Now fully functional (?)

[uranusjr]

The problem is this wouldn’t help the case of apache-airflow unless you set PASSA_IGNORE_JSON_API. If the JSON API is available, it would report requires_dist as empty, and the sdist code would never be reached.

It seems that the design is intentional (pypa/pipenv#1646, pypa/warehouse#3206, pypa/warehouse#3213), but I am not sure what is the solution here. Should Passa always discard null from the JSON API? This would cause overhead if the package really does not have any dependencies. Should Warehouse provide a way for clients to distinguish between an empty requirement list, or the list cannot be retrieved?

[uranusjr]

I gotta say, apache-airflow is abusing setup.py so badly I won’t even feel sorry if I can choose to not support it at all. It is terrible.

[techalchemy]

Yes we should discard nulls. That isn’t an abuse. Null values means they were probably not parseable.

[uranusjr]

I think the sdist format can be handled cleanly with distlib. I’ll experiement tomorrow. Hopefully the end result would be

• Try cache.
• Try JSON.
• Download the best file…
• … if it’s a wheel, great, read the metadata.
• … if it’s sdist, extract it. Read its *.egg-info with EggIngoDistribution
• … if that failed, use the extracted source to build a wheel, and read its metadata
• … if that failed, 🤷‍♂️

I’m wondering if it’s a good idea to swap the last two steps.

[techalchemy]

• … if that failed, use the extracted source to build a wheel, and read its metadata
• … if that failed, man_shrugging

I’m wondering if it’s a good idea to swap the last two steps.

No :)

But we should swap the sdist/wheel building step -- we should always try to build a wheel first IMO