[BUG] Setuptools/wheel PEP517 Build requirements compliance

[jameshilliard]

Description

The PEP517 build requirements state:

Project build requirements will define a directed graph of requirements (project A needs B to build, B needs C and D, etc.) This graph MUST NOT contain cycles. If (due to lack of co-ordination between projects, for example) a cycle is present, front ends MAY refuse to build the project.

However front ends MAY have modes where they do not consider wheels when locating build requirements, and so projects MUST NOT assume that publishing wheels is sufficient to break a requirement cycle.

Currently wheel is not able to use setuptools for its PEP517 build due to a dependency cycle violation with wheel. Setuptools can also thus not use a PEP517 based wheel dependency as that would also violate the PEP517 build requirements.

It appears setuptools probably needs to vendor wheel as recommended in PEP517:

Note in particular that the requirement for no requirement cycles means that backends wishing to self-host (i.e., building a wheel for a backend uses that backend for the build) need to make special provision to avoid causing cycles. Typically this will involve specifying themselves as an in-tree backend, and avoiding external build dependencies (usually by vendoring them).

Expected behavior

Setuptools should not have a dependency cycle with wheel.

How to Reproduce

I have been writing a dependency cycle checker that can catch the wheel violation.

Output

ERROR Failed to validate `build-system` in pyproject.toml, dependency cycle detected: `wheel` -> `setuptools.build_meta` -> `wheel`

Code of Conduct

• I agree to follow the PSF Code of Conduct

[mgorny]

@jaraco, can this be solved by using the existing setuptools.extern mechanism to vendor wheel, or does "help wanted" mean you're looking for some other solution?

[mgorny]

Hmm, another interesting solution would be to switch wheel (and other vendored dependencies) to flit_core. It has much fewer dependencies and can be bootstrapped easily, so it would pave a clean way to bootstrapping setuptools without the necessity to bundle anything.

[abravalheri]

@mgorny, I think the long term plan is described in #1386.

[abravalheri]

The egg_info command has a lot of cruft and deprecated functionality... and the contract between egg_info and dist_info is largely implicit.
Originally posted by @jaraco in #1386 (comment)

Getting rid of this seems to be the desired outcome. (In this context pypa/packaging#498 might be relevant).

[mgorny]

I'm all for long term solutions but I think we need an immediate solution too, if only temporary.

[abravalheri]

Sorry @mgorny, I completely misunderstood your first comment in this thread, I thought you were interested in giving an alternative implementation a try 😅, so I went around collecting some links that could help...

I'm all for long term solutions but I think we need an immediate solution too, if only temporary.

I completely understand that, would you or @jameshilliard like to help implementing this temporary solution and helping to maintain it until we migrate to the long term vision?

[mgorny]

Sure, I just wanted to know if the _vendor approach is seen as a acceptable temporary solution.

That said, I'm currently a bit busy but I can give it a try once I manage some free time. No promises, though.