Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.maint.python > #14680
| From | Scott Kitterman <debian@kitterman.com> |
|---|---|
| Newsgroups | linux.debian.maint.python |
| Subject | Re: Different behavior of package with pyproject.toml |
| Date | 2022-12-04 03:00 +0100 |
| Message-ID | <FyMsp-8bYr-5@gated-at.bofh.it> (permalink) |
| References | <FyDS9-86GP-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
On Saturday, December 3, 2022 11:19:06 AM EST Ole Streicher wrote: > Hi, > > I need some help with a package that switched to using pyproject.toml > only. The package is asdf-astropy, and the problem I have that it does > not package all Python files recursively: for example astropy_asdf.io > files are missing (as seen in unstable now). > > https://tracker.debian.org/pkg/asdf-astropy > https://salsa.debian.org/debian-astro-team/asdf-astropy > > What I do not understand is that this happens "sometimes": > > * when I build the package in a clean schroot with "debuild", files in > subpackages are missing (but no error message in the log) > > * when I install git, then a debuild results in a complete package > > * when I cut&paste the command from the build log [1], the copy process > always happens completely, independent of whether git was installed or > not > > * when I use pbuilder, files of subpackages are never package, with our > without git in the build dependencies > > [1] python3.11 -m build --skip-dependency-check --no-isolation --wheel > --outdir .pybuild/cpython3_3.11 > > Since the package "sometimes" is built correctly, I think that upstream > did it right; however I have no idea where the problem could be. Does > anyone have an idea? My first guess is that in some circumstances setuptools is doing the installing and in others it's the dh-python pyproject plugin (using the installer module). Looking at the build log on buildd.d.o, I can see that build is using the plugin/installer. I think it would be useful to stop the build right before the install step starts [1], manually unpack the wheel (it's a zip file) and see if it has all the files in it. If it does, then plugin/build is doing the right thing and it's an issue with either the plugin or the installer module. Since the build stage uses setuptools as part of it's build process, I thing it's most likely an installer issue. I recently found the installer module doesn't correctly handle flit data files, but I was able to work around that with appropriate .install files. Scott K [1] pybuild plugin_pyproject:118: Unpacking wheel built for python3.10 with "installer" module
Back to linux.debian.maint.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Different behavior of package with pyproject.toml Ole Streicher <olebole@debian.org> - 2022-12-03 17:50 +0100
Re: Different behavior of package with pyproject.toml Scott Kitterman <debian@kitterman.com> - 2022-12-04 03:00 +0100
Re: Different behavior of package with pyproject.toml Ole Streicher <olebole@debian.org> - 2022-12-04 17:10 +0100
Re: Different behavior of package with pyproject.toml Scott Kitterman <debian@kitterman.com> - 2022-12-04 17:10 +0100
Re: Different behavior of package with pyproject.toml Ole Streicher <olebole@debian.org> - 2022-12-04 18:10 +0100
csiph-web