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
We might need a more robust way of redirecting all of stdout:
https://eli.thegreenplace.net/2015/redirecting-all-kinds-of-stdout-in-pyt...
As a temporary workaround, you might need to sed/patch the prints away or
convince upstream to print status information to stderr.
Thanks, Miro, I managed to get past the build stage and opened a PR
upstream.
-- Sandro