build fails to build the wheel for the archspec project

Question

build fails to build the wheel for the archspec project

yurivict opened this issue a year ago · comments

We use the tarball https://pypi.org/packages/source/a/archspec/archspec-0.2.1.tar.gz from PYPI.

This command builds the wheel file:

cd /usr/ports/devel/py-archspec/work-py39/archspec-0.2.1 && /usr/bin/env XDG_DATA_HOME=/usr/ports/devel/py-archspec/work-py39 XDG_CONFIG_HOME=/usr/ports/devel/py-archspec/work-py39 XDG_CACHE_HOME=/usr/ports/devel/py-archspec/work-py39/.cache HOME=/usr/ports/devel/py-archspec/work-py39 PATH=/usr/local/libexec/ccache:/usr/ports/devel/py-archspec/work-py39/.bin:/home/yuri/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin PKG_CONFIG_LIBDIR=/usr/ports/devel/py-archspec/work-py39/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/local/share/pkgconfig:/usr/libdata/pkgconfig MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local CC="cc" CFLAGS="-O2 -pipe -fstack-protector-strong -fno-strict-aliasing " CPP="cpp" CPPFLAGS="" LDFLAGS=" -fstack-protector-strong " LIBS="" CXX="c++" CXXFLAGS="-O2 -pipe -fstack-protector-strong -fno-strict-aliasing " MANPREFIX="/usr/local" CCACHE_DIR="/tmp/.ccache" BSD_INSTALL_PROGRAM="install -s -m 555" BSD_INSTALL_LIB="install -s -m 0644" BSD_INSTALL_SCRIPT="install -m 555" BSD_INSTALL_DATA="install -m 0644" BSD_INSTALL_MAN="install -m 444" /usr/local/bin/python3.9 -m build --no-isolation --wheel

The resulting wheel file doesn't contain any project files:

[yuri@yv /usr/ports/devel/py-archspec]$ tar tzf ./work-py39/archspec-0.2.1/dist/archspec-0.2.1-py3-none-any.whl
archspec/json/.git
archspec-0.2.1.dist-info/METADATA
archspec-0.2.1.dist-info/WHEEL
archspec-0.2.1.dist-info/entry_points.txt
archspec-0.2.1.dist-info/RECORD

pip install -U archspec installs all archspec files correctly.

build-0.10.0
Python-3.9
FreeBSD 13.2

layday · Answer 1 · Tue Jun 27 2023 01:17:28 GMT+0800 (China Standard Time)

Same as #570 (comment)?

yuri@FreeBSD · Answer 2 · Tue Jun 27 2023 01:33:04 GMT+0800 (China Standard Time)

The .gitignore file in the root of the repository has:

/*/*/work
/*/*/work-*

This is supposed to only affect x/y/work and x/y/work-xx.
Why does it matter for deeper work* files in the build directories? .gitignore doesn't prescribe to ignore these.

yuri@FreeBSD · Answer 3 · Tue Jun 27 2023 01:37:45 GMT+0800 (China Standard Time)

The core reason is a bug in Poetry that they didn't fix for a long time: python-poetry/poetry#5547

layday · Answer 4 · Tue Jun 27 2023 01:45:08 GMT+0800 (China Standard Time)

Why does it matter for deeper work* files in the build directories?

What do you mean? If you are ignoring /x/y/work then by extension you are ignoring /x/y/work/**.

yuri@FreeBSD · Answer 5 · Tue Jun 27 2023 01:56:53 GMT+0800 (China Standard Time)

I agree.

Then Poetry shouldn't parse any .gitignore files because the project isn't built from the git repository, and the .gitignore files up in the hierarchy are irrelevant.

Henry Schreiner · Answer 6 · Tue Jun 27 2023 02:55:44 GMT+0800 (China Standard Time)

Parsing the .gitignore isn't wrong, it's a great and stable default - but looking up the tree and parsing .gitignores above the project is (at least by default!).

James Hilliard · Answer 7 · Sat Jul 01 2023 04:15:11 GMT+0800 (China Standard Time)

looking up the tree and parsing .gitignores above the project is (at least by default!)

Yeah, so searching up the tree until a .git directory is found is how git was designed to work, what poetry forgot to add is a sanity check to determine if the build directory is actually tracked by git or not. Adding a simple sanity check like python-poetry/poetry-core#611 should prevent poetry from matching a bogus parent .git directory path.