Package Details: python-booleanoperations 0.9.0-4

Git Clone URL: https://aur.archlinux.org/python-booleanoperations.git (read-only, click to copy)
Package Base: python-booleanoperations
Description: Boolean operations on paths
Upstream URL: https://github.com/typemytype/booleanOperations
Licenses: MIT
Submitter: wiill
Maintainer: alerque (thrasibule)
Last Packager: alerque
Votes: 4
Popularity: 0.37
First Submitted: 2017-01-05 01:18 (UTC)
Last Updated: 2021-12-15 09:57 (UTC)

Pinned Comments

alerque commented on 2021-08-03 11:50 (UTC)

PSA: Like most of the PKGBUILDs that I (co-)maintain, I host prebuilt packages for this in my user repository and all its dependencies for those who wish to install it using pacman without messing around with building from the AUR. Issues or contributions are welcome either in comments below or via this GitHub repository.

Latest Comments

TsumiHokiro commented on 2021-08-23 23:18 (UTC)

@alerque Thank you very much.

alerque commented on 2021-08-23 22:39 (UTC)

@TsumiHokiro Thank for the log. The issue appears to be that yay is grouping installs into batches but not taking into account the test dependencies when coming up with an order. You could deal with this by not using yay or by telling yay to skip the checks, but also this is exacerbated by a bad choice of upstream to use libraries in their test suite that in turn rely on themselves. I've filed this upstream bug report about that and temporarily disabled checks in this package. I tested with yay on an otherwise blank system (base-devel + git) and was able to directly install this package.

TsumiHokiro commented on 2021-08-23 21:48 (UTC)

@alerque Here you go the install post build. https://gist.github.com/TsumiHokiro/d64b1179a30f5c73bd502ce9a3db061b

alerque commented on 2021-08-23 21:31 (UTC)

@TsumiHokiro The -2 segment is the Arch Linux pkgrel number (that shows packaging iterations of the same underlying software version). Python doesn't know anything about these and will not request them. It is also plain from this package that the Arch AUR packaging is not asking for any specific version at all, just that it exist.

I'd love to help you solve this, but I'm going to need to see a more specific problem. Can you post the actual build log or terminal output where you are trying to install this?

TsumiHokiro commented on 2021-08-23 21:21 (UTC) (edited on 2021-08-23 21:24 (UTC) by TsumiHokiro)

@alerque: In case you're wondering what is wrong, python-booleanoperations is asking for python-fontpens-0.2.4-2 while the one it is providing is saying it is the 0.2.4.

alerque commented on 2021-08-20 13:47 (UTC)

@Haagentis As I mentioned on the other package I'm going to need a little more detail from you about how you are trying to build and what error you are getting. I spent a long time fixing these up and testing them so that I know they each built cleanly using only the advertised dependencies. Because this set of packages previously had a set of circular dependencies that was the wrong direction you may have old versions that have incorrect dependencies that are blocking you. If you give me more details about your error I can probably suggest a solution.

Haagentis commented on 2021-08-20 11:50 (UTC)

Can't update it, something is wrong and it's the second broken package I get from this maintainer. You're doing something wrong, man/woman.

alerque commented on 2021-08-03 11:50 (UTC)

PSA: Like most of the PKGBUILDs that I (co-)maintain, I host prebuilt packages for this in my user repository and all its dependencies for those who wish to install it using pacman without messing around with building from the AUR. Issues or contributions are welcome either in comments below or via this GitHub repository.

alerque commented on 2021-07-23 13:19 (UTC) (edited on 2021-07-23 13:25 (UTC) by alerque)

You keep on calling these packages broken, they build fine for the majority of users, if they use makepkg or the various AUR helpers.

Packages that are missing things from makedepends=() and only happen to build if people already have the correct build tooling (such as python-setuptools-scm tools) installed on their system or because they let the build process run pip to install dependencies that are missing from depends=() in the background are broken. Yes I call that "broken", and as far as Arch packaging standards go I think that definition of broken is pretty generally accepted.

I'm sorry if you think I'm not being civil. I really mean that, if I haven't been civil I apologize and would be happy to correct it.

On the other hand I realize and am not apologetic for the more aggressive push to get these 10 or so packages that I depend on for other packages fixed properly. I have been sending patches since Jan 2020 and dozens comments on a regular basis since. A year and a half later I am still maintaining my own forks of 8 out of 12 or so packages that I care about — in spite of all the patches and comments most of them are still broken. You say you want gentle reminders, but gentle reminders in comments have not been getting action and sit for months.

I don't see my push as "my way or the highway", the "highway" option is only coming up because several lesser options are not going well and have been rough for years. I've been pushing for one of

  1. Properly fixed packages, fixed however you like as long as they are actually fixed
  2. Apply patches
  3. Let me co-maintain
  4. Orphan

You keep refusing №3 and №4 — which is totally your prerogative to do if you consistently do №1. However in spite of both specific comments and even some patches for reference your own fixes haven't even been fixing these except in response to repeated complaints and when there are outstanding orphan requests. Hence my frustration and starting to push for option №4.

thrasibule commented on 2021-07-23 12:35 (UTC)

Thanks for your constructive comments as always. For your information I did patch the right file, but just not enough. I think this should build cleanly now.

You keep on calling these packages broken, they build fine for the majority of users, if they use makepkg or the various AUR helpers. I agree it's a great goal to have packages build in a clean chroot, but you can be more civil about it. My way or the highway is not a nice way to contribute.

alerque commented on 2021-07-23 11:47 (UTC) (edited on 2021-07-23 11:48 (UTC) by alerque)

This packages is even more broken than my previous comment suggests. Your so called "fix" for removing the scm dependency doesn't even patch the right file! This completely fails to build in a clean chroot because it can't find scm tools, tries to use pip to install it, and of course crashes and burns. It is evident that you aren't actually testing these commits against a clean system as the patches I sent have been.

I understand Python packaging can be obnoxious, but can we please stop trying to avoid obvious fixes like using the dependencies as specified upstream (especially when those dependencies are in [community])? Even if you were going to patch it out, bogus fixes like this one that don't even operate on the right files and leave the package still broken are clearly worse than just using the right dependencies. I already sent patches which actually fix this properly and build cleanly against Arch's default repositories and following packaging guidelines. If you can't be bothered to test using makechrootpkg or some other clean build method at least apply my patches or allow me to do so.

alerque commented on 2021-07-21 10:03 (UTC)

This one is still broken. You missed the --optimize=1 argument (see Python guidelines here) that is required to get prebuilt bytecode managed by the package manage instead of untracked files being created on each system.

It's still quite frustrating that you are ignoring my patches. Even if you wanted to change something and do it differently afterwards, starting by applying my patches would save you some of this trouble, I had this correct in my patch to setup the split build/package.

alerque commented on 2021-07-19 21:02 (UTC)

Per previous discussion, here are two incremental packages needed to bring this up to even minimal Arch packaging requirements. This package does not build before these patches, and it does with them. There are more things mentioned in the Arch Python package guidelines that are not correct yet, but this is an essential start to even get a working build.

Please apply each with git am < file.patch:

From 751a6f8094e47d98707c85111610226237ab7d4a Mon Sep 17 00:00:00 2001
From: Caleb Maclennan <caleb@alerque.com>
Date: Mon, 19 Jul 2021 23:53:40 +0300
Subject: [PATCH 1/2] Split build/package functions

See https://wiki.archlinux.org/title/Python_package_guidelines#distutils

Signed-off-by: Caleb Maclennan <caleb@alerque.com>
---
 PKGBUILD | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/PKGBUILD b/PKGBUILD
index 895b4ec..f01d330 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -1,4 +1,5 @@
 # Maintainer: Guillaume Horel <guillaume.horel@gmail.com>
+# Contributor: Caleb Maclennan <caleb@alerque.com>
 # Ex-Maintainer: William Turner <willtur.will@gmail.com>
 pkgname='python-booleanoperations'
 _pkgname=booleanOperations
@@ -15,9 +16,14 @@ options=(!emptydirs)
 source=("https://pypi.org/packages/source/${_pkgname:0:1}/${_pkgname}/${_pkgname}-${pkgver}.zip")
 sha256sums=('8cfa821c32ad374fa120d6b2e0b444ebeac57c91e6631528645fa19ac2a281b8')

+build() {
+  cd "${srcdir}/$_pkgname-$pkgver"
+  python setup.py build
+}
+
 package() {
   cd "${srcdir}/$_pkgname-$pkgver"
-  python setup.py install --root=$pkgdir ||return 1
+  python setup.py install --root="$pkgdir" --optimize=1 --skip-build
   install -D -m644  LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
 }

-- 
2.32.0

From 7ed46f9e91a6d8a4a8c98538d125418990c16369 Mon Sep 17 00:00:00 2001
From: Caleb Maclennan <caleb@alerque.com>
Date: Mon, 19 Jul 2021 23:58:47 +0300
Subject: [PATCH 2/2] Fix broken dependencies

Signed-off-by: Caleb Maclennan <caleb@alerque.com>
---
 .SRCINFO |  6 +++---
 PKGBUILD | 11 ++++++++---
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/.SRCINFO b/.SRCINFO
index f2bee56..48d070c 100644
--- a/.SRCINFO
+++ b/.SRCINFO
@@ -1,19 +1,19 @@
 pkgbase = python-booleanoperations
    pkgdesc = Boolean operations on paths.
    pkgver = 0.9.0
-   pkgrel = 1
+   pkgrel = 2
    url = https://github.com/typemytype/booleanOperations
    arch = any
    license = MIT
    checkdepends = python-pytest
    checkdepends = python-defcon
    checkdepends = python-fontpens
-   makedepends = python-setuptools
+   makedepends = python-setuptools-scm
    depends = python-pyclipper
    depends = python-fonttools
+   depends = python-fs
    options = !emptydirs
    source = https://pypi.org/packages/source/b/booleanOperations/booleanOperations-0.9.0.zip
    sha256sums = 8cfa821c32ad374fa120d6b2e0b444ebeac57c91e6631528645fa19ac2a281b8

 pkgname = python-booleanoperations
-
diff --git a/PKGBUILD b/PKGBUILD
index f01d330..6e2fab2 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -4,18 +4,23 @@
 pkgname='python-booleanoperations'
 _pkgname=booleanOperations
 pkgver=0.9.0
-pkgrel=1
+pkgrel=2
 pkgdesc='Boolean operations on paths.'
 arch=('any')
 url='https://github.com/typemytype/booleanOperations'
 license=('MIT')
 checkdepends=('python-pytest' 'python-defcon' 'python-fontpens')
-depends=('python-pyclipper' 'python-fonttools')
-makedepends=('python-setuptools')
+depends=('python-pyclipper' 'python-fonttools' 'python-fs')
+makedepends=('python-setuptools-scm')
 options=(!emptydirs)
 source=("https://pypi.org/packages/source/${_pkgname:0:1}/${_pkgname}/${_pkgname}-${pkgver}.zip")
 sha256sums=('8cfa821c32ad374fa120d6b2e0b444ebeac57c91e6631528645fa19ac2a281b8')

+prepare() {
+  cd "${srcdir}/$_pkgname-$pkgver"
+  sed -i -e '/wheel$/d' setup.cfg
+}
+
 build() {
   cd "${srcdir}/$_pkgname-$pkgver"
   python setup.py build
-- 
2.32.0

alerque commented on 2021-06-02 16:39 (UTC)

@randomguy343 You can build by using --nocheck somewhere in the dependency loop to get one package started.

@thrasibule This is an ongoing problem for people trying to break into the loop. I realize this is bad dev practice in the upstream projects that depends on consumer libraries for testing, but that's what we have to work with. Disabling the check() functions by default using options=(!check) would be appropriate. The testing isn't really even testing that the package works right, only that the upstream regression suite passes in the build environment.

randomguy343 commented on 2021-06-02 09:38 (UTC) (edited on 2021-06-02 09:42 (UTC) by randomguy343)

@SolarAquarion +1
I experience the same thing, python-fontpens, python-booleanoperations and python-fontparts can't be installed individually nor together.

SolarAquarion commented on 2021-05-05 23:47 (UTC)

==> Using [custom] repository -> python-booleanoperations: (none) -> 0.9.0-1 -> python-defcon: (none) -> 0.8.1-2 -> python-fontmath: (none) -> 0.6.0-1 -> python-fontparts: (none) -> 0.9.10-1 -> python-fontpens: (none) -> 0.2.4-1 -> python-pyclipper: (none) -> 1.2.1-1 python-pyclipper transitive dependency of python-booleanoperations python-defcon transitive dependency of python-booleanoperations python-fontpens transitive dependency of python-booleanoperations python-booleanoperations transitive dependency of python-fontparts python-defcon transitive dependency of python-fontparts python-fontmath transitive dependency of python-fontparts python-fontpens transitive dependency of python-fontparts python-fontmath transitive dependency of python-fontpens python-fontparts transitive dependency of python-fontpens tsort: -: input contains a loop: tsort: python-fontpens tsort: python-fontparts tsort: python-booleanoperations tsort: -: input contains a loop: tsort: python-fontpens tsort: python-fontparts ==> ERROR: sync: invalid argument

SolarAquarion commented on 2021-05-05 23:46 (UTC)

this package in the checkdepends is causing a circular dependency operation

alerque commented on 2021-01-07 19:11 (UTC)

@djmattyg007 As much as I disagree with the policy of treating AUR pkgrel's different than ones in [community] in this regard, it is against current AUR guidelines to bump release just because they need rebuilding due to library updates in official repos. Sadly makepkg -fi or yay --rebuild is your friend here.

djmattyg007 commented on 2021-01-03 02:57 (UTC)

Could you please bump the pkgrel to force a rebuild for python3.9?

PedroHLC commented on 2020-11-01 17:02 (UTC)

ModuleNotFoundError: No module named 'pytest'

Missing python-pytest to build in a clean chroot.

abouvier commented on 2020-06-18 04:42 (UTC)

python-setuptools is missing in makedepends.

alerque commented on 2020-04-23 21:31 (UTC)

@raxod502 that circular issue is actually in the upstream packages I believe. You have to break intro the look by compiling something with makepkg --nocheck. You can pass that through using yay --mflags --nocheck.

Alternatively you can install all these packages using pacman from this repository.

raxod502 commented on 2020-04-23 19:54 (UTC)

This has a circular dependency on python-fontpens -> python-fontparts -> python-booleanoperations, so the installation using Yay fails.

tjbp commented on 2020-01-14 19:05 (UTC)

@thrasibule Yup, tests depend on python-defcon so it needs to go into makedepends or the build fails.

thrasibule commented on 2020-01-14 02:46 (UTC)

@tjbp only tests depend on defcon I think. Where do you see that it depends on defcon?

tjbp commented on 2020-01-13 23:49 (UTC)

Please add python-defcon as a dependency - thanks.

alerque commented on 2019-12-27 05:43 (UTC)

Building fails:

ModuleNotFoundError: No module named 'fontPens'

Unfortunately installing python-fontpens does not seem to resolve this directly. I'm not sure what the proper resolution is.

Iglu47 commented on 2019-12-21 13:34 (UTC)

without python-defcon - fail test: "ModuleNotFoundError: No module named 'defcon'"

alerque commented on 2019-08-23 11:56 (UTC)

This fails because python-unicodedata2 is required by two of it's child dependencies and not listed by either of them. I'm guessing you @wiill have it on your system, but it needs to be listed in the two other packages I just commented on.