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.060964
First Submitted: 2016-11-22 18:39
Last Updated: 2020-12-27 13:10

Latest Comments

1 2 Next › Last »

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 ^^

grandchild commented on 2019-11-19 17:41

ah that slipped through because it's a python package. thanks, fixed!