[Buildroot] [git commit] package/python-setuptools: add missing dependency on host-python-wheel

[Yann E. MORIN]

Arnout, All,

On 2023-07-04 22:28 +0200, Arnout Vandecappelle spake thusly:
> On 03/07/2023 20:56, Thomas Petazzoni wrote:
> >On Mon, 3 Jul 2023 20:20:31 +0200
> >Arnout Vandecappelle via buildroot <buildroot at buildroot.org> wrote:
> >Hu, this was not in the patch from Romain I believe.
> >>+	select BR2_PACKAGE_PYTHON_WHEEL # runtime
> >This is not correct, there is no such symbol in Buildroot, and it
> >causes a check-symbol error:
> >https://gitlab.com/buildroot.org/buildroot/-/jobs/4586144848
> >What was the motivation behind this additional select?
> 
>  Because setuptools has a runtime dependency on wheel. The pep517
> infrastructure does a build-time check of this runtime dependency, but due
> to the way we run python, the build-time check looks at what is installed
> for the host, not what is installed for the target. Therefore, we have a
> dependency on host-python-wheel instead of target python-wheel.
> 
>  Since setuptools clearly defines that it has a dependency on wheel, I
> thought it logical that we would reflect that dependency in Buildroot as
> well. It is really a runtime dependency, not a build-time dependency, so I
> added this select like we do for runtime dependencies.
> 
>  Of course, I didn't notice that we don't have a target python-wheel
> package, so it doesn't actually work.
> 
>  So, dropping this select I'm pretty sure is going to break something, at

Dropping the select can not break anything: there is no package to
select to begin with. So it can't be more broken than it was before the
select was introduced.

Of course, if we really need wheel as a target package, then it should
be made such a package before we can select it.

Although having sheel on the target jsut because some (most?) packages
have a spurious dependency on it, would be seriously a shame...

> some point. I've looked a bit closer now, and it turns out that wheel is
> actually only imported in one specific function, in the "editable_wheel"
> command. So it's quite unlikely anyone will ever see this breakage.
> 
>  However, now I look a bit more in detail at it, it looks like this commit
> is in fact bogus, and Yann's original comment that the wheel dependency
> should be added to the infrastructure is in fact correct. From the
> documentation:
> 
>    Historically this documentation has unnecessarily listed ``wheel``
>    in the ``requires`` list, and many projects still do that. This is
>    not recommended. The backend automatically adds ``wheel`` dependency
>    when it is required, and listing it explicitly causes it to be
>    unnecessarily required for source distribution builds.
> 
> And it's pretty clear what is adding this dependency: the pep517 infra calls
> the build with
> 
>    python -m build -n -w
> 
> The "-w" stands for "build a wheel" and I guess it's obvious that that
> implies a dependency on host-python-wheel? And I guess that the relatively
> few pep517 packages we have already have a setuptools-based package (and
> therefore host-python-setuptools and host-python-wheel) somewhere in their
> dependency chain.
> 
>  So, I do think this dependency should move the the pkg-python infra _for
> pep517 packages_, as Yann originally commented.

I'd defer to James to find a better solution, because I don't grasp even
partially all this pep517-introduced pain...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'