gpep517

[m-kuhn]

Is this the right tool to use, compared to build?

I guess vcpkg qualifies as "distribution" and so far I had good results... https://fosstodon.org/@orsinium/110956868463721979

[Neumann-A]

Still need to figure out cross builds

https://peps.python.org/pep-0720/

[Neumann-A]

I see consistent errors with
2024-05-13 08:11:22,326 gpep517 INFO Building wheel via backend setuptools.build_meta:__legacy__
leading to:

2024-05-13 08:11:22,508 gpep517 INFO The backend produced E:\all\vcpkg\packages\py-fsspec_x64-windows-release\wheels\fsspec-2024.3.1-py3-none-any.whl
Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='cp1252'>
OSError: [Errno 9] Bad file descriptor

This did not happen with the original scripts. Observed in py-fsspec and py-toolz

[m-kuhn]

@mgorny, do you have an idea what might be the cause for this?

[Neumann-A]

Hmm how do I pass -C options via gpep ?

vcpkg_python_build_and_install_wheel(
  SOURCE_PATH "${SOURCE_PATH}" 
  OPTIONS 
    -C raqm=disable # linkage issues. Without pc file missing linakge to harfbuzz fribidi
)

This worked with the build approach. I assume there is something similar with gpep

[Neumann-A]

@m-kuhn As it seems you forgot to add ${build_ops} to the build command. Currently there is no way to pass through additional options:
https://github.com/open-vcpkg/python-registry/blob/main/ports/vcpkg-python-scripts/vcpkg_python_functions.cmake#L64

[Neumann-A]

Hmm how do I pass -C options via gpep ?

This works after fixing the scripts: --config-json "{\"raqm\": \"disable\"}"

However seeing this again:

2024-05-13 10:34:15,130 gpep517 INFO Building wheel via backend backend
....
 2024-05-13 10:34:24,825 gpep517 INFO The backend produced E:\all\vcpkg\packages\py-pillow_x64-windows-release\wheels\pillow-10.3.0-cp311-cp311-win_amd64.whl
Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='cp1252'>
OSError: [Errno 9] Bad file descriptor

[mgorny]

@mgorny, do you have an idea what might be the cause for this?

How are you invoking it? I don't have a Windows system, and to be honest I've never considered portability to one, but I can try figuring something out if I know more.

[m-kuhn]

I can see that from gentoo to windows is a far way :-)

See the link in #10 (comment)

"${PYTHON3}" -m gpep517 build-wheel --wheel-dir "${z_vcpkg_wheeldir}" --output-fd 1

does that help?

[mgorny]

I wonder why it isn't giving you a proper backtrace. My guess is that writing to a fd doesn't work for some reason.

Perhaps CMake doesn't open a fd for you. Maybe try with OUTPUT_VARIABLE? By the way, you can use the path put into that variable then, instead of globbing for the result.

[m-kuhn]

I remember playing with the fd and not receiving bith, stderr and stdout at the same time.

@Neumann-A do you have steps to reproduce this issue?

[Neumann-A]

@m-kuhn: I just updated my-vcpkg-port. You can use https://github.com/Neumann-A/my-vcpkg-ports/tree/master/py-toolz , just remove USE_BUILD from the portfile and "py-build" and "py-pyproject-hooks" from the manifest. I can check the whole tree for USE_BUILD since that are the ports where I observed the issue.

[Neumann-A]

So I am currently debugging a python build and added a random print() statement resulting into that issue. changing to --output-fd 0 removed the error and showed the printed statement.

[Neumann-A]

Got a backtrace with output-fd 0:

Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "E:\all\vcpkg\installed\x64-win-rel\tools\python3\Lib\site-packages\gpep517\__main__.py", line 429, in <module>
    sys.exit(main())
             ^^^^^^
  File "E:\all\vcpkg\installed\x64-win-rel\tools\python3\Lib\site-packages\gpep517\__main__.py", line 425, in main
    return func(args)
           ^^^^^^^^^^
  File "E:\all\vcpkg\installed\x64-win-rel\tools\python3\Lib\site-packages\gpep517\__main__.py", line 214, in build_wheel
    with os.fdopen(args.output_fd, "w") as out:
OSError: [Errno 9] Bad file descriptor

[mgorny]

Thanks. I can reproduce the problem using IPython. So apparently standard fds aren't supposed to be opened like that. I'll investigate more.

[mgorny]

Could you try the patch from projg2/gpep517#15?

[Neumann-A]

Could you try the patch from projg2/gpep517#15?

Seems to work.

[mgorny]

Thanks for the confirmation. I've just pushed and uploaded v16 with the fix.