Personally, I would prefer if the package was better integrated in the rest of the Arch repositories, so I'd avoid a virtualenv. Managing venvs seems like something one would want to do by hand anyways.

Builtin tests can be run by adding the following to the PKGBUILD:

check() {
cd "$srcdir/$_pkgname"
python setup.py test
}

You're also right about the package version. It's just a matter of adding the following, then:

Yes, just I used to have it this way. I would think that the packages would eventually break compatibility with newer versions.

I have had it in my todo to update it to follow some package guidelines.

I was thinking either someone has the binaries run a virtual environment so that we can manage with pip, or figure out how to run tests (which would fail when packages become incompatible). Please tell me what you would prefer.

(sidenote, this package is also several major commits behind in terms of actually commits and I sussing the wrong naming scheme)

Hello @Modelmat! Your PKGBUILD is set up to install all requirements through pip. On my machine this was creating some conflicts (in fact, it is generally discouraged in packaging guidelines), so I rewrote it to use Arch and AUR packages instead.

The two main drawbacks of this are that

The maintainer must keep track of all upstream requirements manually;

Requirements in the Python package have == on versions, which are very inconvenient to satisfy system-wide. My workaround has been a sed -i 's/==/>=/' requirements.txt, which works for now but eventually won't in the future.