Package Details: python-pyclipper 1.2.1-1

Git Clone URL: (read-only, click to copy)
Package Base: python-pyclipper
Description: Cython wrapper for the C++ translation of the Angus Johnson’s Clipper library
Upstream URL:
Licenses: MIT
Submitter: xantares
Maintainer: grandchild (caleb)
Last Packager: caleb
Votes: 3
Popularity: 0.022679
First Submitted: 2016-11-22 18:39
Last Updated: 2020-12-27 13:10

Latest Comments

1 2 Next › Last »

And1G commented on 2021-03-16 16:31

Edit: Was able to build after adding python-pip to makedepends.

Building in a clean chroot with devtools leads to the following error. Any idea on that one?

==> Extracting sources...
  -> Extracting with bsdtar
==> Entering fakeroot environment...
==> Starting package_python-pyclipper()...
/usr/lib/python3.9/site-packages/setuptools/ UserWarning: Usage of dash-separated 'description-file' will not be supported in future versions. Please use the underscore name 'description_file' instead
WARNING: The wheel package is not available.
/usr/bin/python: No module named pip
Distribution mode: Compiling Cython generated .cpp sources.
Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/setuptools/", line 75, in fetch_build_egg
  File "/usr/lib/python3.9/", line 373, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/python', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmp6rje0d52', '--quiet', 'setuptools_scm>=1.11.1']' returned non-zero exit status 1.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/build/python-pyclipper/src/pyclipper-1.2.1/", line 64, in <module>
  File "/usr/lib/python3.9/site-packages/setuptools/", line 152, in setup
  File "/usr/lib/python3.9/site-packages/setuptools/", line 147, in _install_setup_requires
  File "/usr/lib/python3.9/site-packages/setuptools/", line 721, in fetch_build_eggs
    resolved_dists = pkg_resources.working_set.resolve(
  File "/usr/lib/python3.9/site-packages/pkg_resources/", line 766, in resolve
    dist = best[req.key] = env.best_match(
  File "/usr/lib/python3.9/site-packages/pkg_resources/", line 1051, in best_match
    return self.obtain(req, installer)
  File "/usr/lib/python3.9/site-packages/pkg_resources/", line 1063, in obtain
    return installer(requirement)
  File "/usr/lib/python3.9/site-packages/setuptools/", line 780, in fetch_build_egg
    return fetch_build_egg(self, req)
  File "/usr/lib/python3.9/site-packages/setuptools/", line 77, in fetch_build_egg
    raise DistutilsError(str(e)) from e
distutils.errors.DistutilsError: Command '['/usr/bin/python', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmp6rje0d52', '--quiet', 'setuptools_scm>=1.11.1']' returned non-zero exit status 1.
==> ERROR: A failure occurred in package_python-pyclipper().
==> ERROR: Build failed, check /var/lib/archbuild/staging-x86_64/andi/build

grandchild commented on 2020-06-05 10:40

@caleb: Sounds fair. It's not the most popular python package ever. Let's see when extra/python2 vanishes :)

(Also I hadn't considered the fact that people have python2-free systems already. I get the point of it helping to debug latent bugs and unnecessary dependencies.)

caleb commented on 2020-06-05 10:29

@grandchild You are right it isn't a lot of work to keep at this point, but that is fast changing because keeping a working Python 2 install to build it with is about to get harder. Right not it's just a nuisance. I'm on a clean new machine I built about a week ago and building this package is the first time I needed to install Python 2 for anything. Not having it on my system also help sort out a number of things that were incorrectly using it when they actually supported Python 3 just fine. Of course I should be building things like this in a chroot so it wouldn't matter that much. I'd say I currently lean towards about -20%, so we'll call it a dead heat and leave it for now until something else changes to tip the scales. Sound fair?

grandchild commented on 2020-06-04 22:55

I am not the biggest fan of keeping it either though. On a scale of -100% to +100% for keeping it, I'm at about +20%, for the reasons given. If you feel like there's value in the greater scheme of things for deprecating python2 more aggressively I'd be on board.

grandchild commented on 2020-06-04 22:48

It's so little overhead to do maintain it in this case, that I feel like I want to. It's comparable to maintaining i686 builds in the AUR, because other projects (in that example archlinux32) might want to continue using it.

As soon as it becomes work, I'd consider removing it. But as it stands I/we don't really have to do anything for it. The worst it does right now is duplicate the package() function, but that's about it.

caleb commented on 2020-06-04 21:07

Is there a compelling current reason to keep the Python 2 packaging? Python 2 is totally EOL, unpatched, unmaintained, and being ripped out of Arch core packages as fast as they can. Nothing in the AUR depends on it except one old package that is broken for half a dozen other reasons anyway.

caleb commented on 2020-06-04 14:13

Please do.

grandchild commented on 2020-06-04 12:52

Sorry for taking so long to get to this. If you still want to co-maintain, caleb I will add you.

caleb commented on 2020-04-15 06:57

If you use the PyPi hosted source you don't need the .git directory or any of this build shenanigans. Also, use python-setuptools-scm as the make dependency. The source should be:


J5lx commented on 2020-04-15 02:02

Btw, you can simply put #tag=${pkgver} at the end of the source URL, that way makepkg will do the checkout for you automatically. Also, please put git into makedepends since you’re using it to retrieve sources ^^