This package still uses the legacy eclass code paths. These paths are deprecated and pose a significant maintenance cost. Please update the package to use PEP517 build mode. For more information, please see the Python Guide, particularly; https://projects.gentoo.org/python/guide/migration.html#migrating-to-pep-517-builds
[Adding this comment en-masse, sorry for the noise, but it's important.) 1. Please take particular care to check file diffs before/after, possibly using `iwdevtools`. Keep a particular eye out for e.g. config files now missing from /etc and instead being in /usr/lib/python*/site-packages, etc. 2. Please make sure to do the migration in a new revision in ~arch, partly because of 1.
It seems that the setup.py modifies some of the paths, which causes the script file to be installed. Similar issue by others: https://lists.gnu.org/archive/html/guix-commits/2022-01/msg00207.html I need to go through the setup file and most likely patch it to make it work with PEP517.
Created attachment 877436 [details] legacy mode build log
Created attachment 877437 [details] pep517 build log
Created attachment 877438 [details, diff] debugging patch for setup.py
It seems to me that setup.py is defining custom commands, which get executed differently under PEP517. I've patched setup.py to print some additional debug information and as far as I can tell. Here are the execution orders: In legacy mode: ---- setup.py invocation ---- - Build - BuildScripts ---- setup.py invocation ---- - Install - BuildScripts - Install Data In PEP517 mode: ---- setup.py invocation ---- - Build - BuildScripts - Install - Install Data In PEP517 mode, since Install has not been executed yet, it means install.install_data is None instead of being a path and the BuildScripts object just bails on creating dblatex main script due to the empty path. I'm not familiar with the internal details of the legacy and PEP517 installation modes and only took a peek at distutils-r1.eclass so far. I'll prolly need to read the documentation[1][2] back to back before I can proceed fixing this, unless someone more experienced can help me out here. Further pointers are also welcome. [1]https://projects.gentoo.org/python/guide/migration.html#migrating-to-pep-517-builds [2]https://peps.python.org/pep-0517/
Final ping. Please note that we will not hesitate to last rite low profile packages over this.
I've tried contacting upstream without success so far. I'll try once more, but if it fails I'll probably have to rewrite the setup.py myself.
It needs to be ported to a non-python build system, such as autotools or meson. Wheels are logically and semantically invalid for an application installing files outside of site-packages and /usr/bin -- it's a bad idea to deprecate `setup.py install` for software that genuinely needs it as a "Makefile but python".
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=35a1ef8369dfc368ed9ca408bcc117ae76a6e3a3 commit 35a1ef8369dfc368ed9ca408bcc117ae76a6e3a3 Author: Zoltan Puskas <zoltan@sinustrom.info> AuthorDate: 2024-06-10 05:51:42 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2024-06-13 10:36:49 +0000 app-text/dblatex: Fix Python issues Migrate to PEP517 while also adding compatibility for 3.12 Closes: https://bugs.gentoo.org/909897 Closes: https://bugs.gentoo.org/929361 Closes: https://bugs.gentoo.org/922530 Signed-off-by: Zoltan Puskas <zoltan@sinustrom.info> Closes: https://github.com/gentoo/gentoo/pull/37102 Signed-off-by: Michał Górny <mgorny@gentoo.org> app-text/dblatex/dblatex-0.3.12-r3.ebuild | 95 +++++++++++++++++ .../dblatex-0.3.12-adjust-submodule-imports.patch | 62 +++++++++++ .../dblatex-0.3.12-replace-imp-by-importlib.patch | 113 +++++++++++++++++++++ 3 files changed, 270 insertions(+)
