On 27. 09. 22 19:41, Miro Hrončok wrote:
On 27. 09. 22 17:55, Sandro wrote:
> On 27-09-2022 08:17, Lumír Balhar wrote:
>> Make sure that the build does not use the pyx file from upstream. It
>> seems to me that the file generated by Cython is in the source tarball
>> (skmisc/loess/src/_loess.pyx) and I did not find any mention of use of
>> Cython in the build log. The file is probably generated by an older
>> version of Cython and that is causing you the problem.
>
> Thank you, Lumír, for pointing me in the right direction.
>
> The offending pregenerated C file was indeed in the source tarball along with
> a precompiled library for good measure.
>
> I was looking at the source on GitHub, which does not have
> skmisc/loess/src/_loess.c. I'm sure that's what you meant. It's generated
> from skmisc/loess/src/_loess.pyx
>
> I have switched to the GitHub source tarball, which seems to be aimed at
> developers, who like to build everything from scratch, and comes without
> pregenerated files nor binaries.
>
> However, I haven't been able to build the package, yet. It looks like the
> tools/cythonize.py script, which is called from setup.py, generates output,
> that throws off %pyproject_buildrequires:
>
> No matching package to install: 'Processing'
> No matching package to install: 'changed'
>
> Is there a standard way of handling noisy scripts? Or am I just out of luck
> using pyproject macros? Or, my bet, am I missing something?
>
>
https://copr.fedorainfracloud.org/coprs/gui1ty/neuro-sig/build/4875750/
Looking at the code, this happens because:
1) their setup.py uses subprocess
https://github.com/has2k1/scikit-misc/blob/v0.1.4/setup.py#L92
2) the script executed via subprocess prints to stdout:
https://github.com/has2k1/scikit-misc/blob/v0.1.4/tools/cythonize.py#L177
3) %pyproject_buildrequires uses contextlib.redirect_stdout:
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/a3e31c/f/pyp...
4) contextlib.redirect_stdout does not support stdout of subprocesses
https://docs.python.org/3/library/contextlib.html#contextlib.redirect_stdout
We might need a more robust way of redirecting all of stdout...