Arch Linux User Repository

@E3LDDfrK it already is, maintainer doesnt push .SRCINFO changes...

As bossi said, shouldn't python-flit-core be added as dependency?

python-future has been removed from the official repos because it fails with Python 3.13+. After checking, I don't think that python-pyglet requires it anyway, so it can be removed.

Hi there,

I just ran into a build conflict attempting to install 2.0.18: python-flit-core was quoted as an unmet dependency. Installing the package manually and then setting it to "implicitly installed" to treat it as a package installed as a dependency with pacman -D --asdeps python-flit-core and retrying installation of python-pyglet did the trick. Is this on your radar? It might make sense to add it as a dependency to the manifest as long as there's nothing preventing it from being. Thanks!

P.S.: I didn't dig into it but this might be a build dependency only, throwing a glimpse at the posts below, so it might be worth uninstalling again afterwards. Would be good to get clarification on.

@micwoj92 @dreieck Thank you for pointing this out, fixed in 2.0.18-2

@konez2k This is not what dreieck meant, you don't need to touch setup.py, just adjust build commands for the package.

diff --git a/PKGBUILD b/PKGBUILD
index 8d8265f..91f4496 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -14,7 +14,7 @@ arch=('any')
 url="https://github.com/pyglet/pyglet"
 license=('BSD')
 depends=('python' 'glu' 'python-future')
-makedepends=('python-setuptools')
+makedepends=('python-build' 'python-flit-core' 'python-installer')
 optdepends=('ffmpeg: provides audio&video support'
     'openal: live audio')
 source=("$pkgbase-$pkgver.zip::https://github.com/pyglet/pyglet/archive/refs/tags/v$pkgver.zip")
@@ -26,12 +26,11 @@ prepare() {

 build() {
     cd "$srcdir/$pkgbase-$pkgver"
-    python3 setup.py build
+    python -m build --wheel --no-isolation
 }

 package_python-pyglet() {
-    depends=('python' 'glu' 'python-future')
     cd "$srcdir/$pkgbase-$pkgver"
-    python3 setup.py install --root="$pkgdir" --optimize=1
+    python -m installer --destdir="$pkgdir" dist/*.whl
     install -D -m644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
 }

Thanks for the suggestions, @dreieck. I've now prepended the $pkgbase-$pkgver. Unfortunately, I can't modify the setup.py as it depends on the origin.

Please move away from calling setup.py directly and instead use python -m build and python -m installer (together with the appropriate makedepends), as documented in the Arch Linux wiki for python packages:

==> Starting package_python-pyglet()...
running install
/usr/lib/python3.12/site-packages/setuptools/_distutils/cmd.py:66: SetuptoolsDeprecationWarning: setup.py install is deprecated.
!!

        ********************************************************************************
        Please avoid running ``setup.py`` directly.
        Instead, use pypa/build, pypa/installer or other
        standards-based tools.

        See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html for details.
        ********************************************************************************

!!
  self.initialize_options()

Regards and thanks for maintaining!

Ahoj,

can you please prepend $pkgbase-$pkgver.zip:: to the source entry:

source=("$pkgbase-$pkgver.zip::https://github.com/pyglet/pyglet/archive/refs/tags/v$pkgver.zip")

Reason: When $SRCDEST is set (e.g. in /etc/makepkg.conf), all files will be downloaded into a single directory.
A generic filename like v$pkgver.zip is prone to conflicts (with other packages that also use a generic filename).

Regards and thanks for maintaining!

@MarsSeed Thanks. Updating with yay worked fine and has solved the pamac update loop.