Package Details: pyls-mypy 0.1.8-2

Git Clone URL: https://aur.archlinux.org/pyls-mypy.git (read-only, click to copy)
Package Base: pyls-mypy
Description: A Mypy plugin for the python language server
Upstream URL: https://github.com/tomv564/pyls-mypy
Licenses: MIT
Submitter: languitar
Maintainer: None
Last Packager: languitar
Votes: 5
Popularity: 0.001980
First Submitted: 2018-05-28 09:20
Last Updated: 2020-12-03 09:08

Latest Comments

Hi-Angel commented on 2020-12-07 21:39

Most people use something like yay which will automatically check AUR dependencies after updating the official packages. In these cases the update works more or less out of the box.

Oh, I see. This is funny, I am probably very out of date on this. Last I remember is that using AUR-helpers was frowned upon, so I was feeling kinda rebellious for using yaourt. Times changed, it seems.

languitar commented on 2020-12-07 19:56

Most people use something like yay which will automatically check AUR dependencies after updating the official packages. In these cases the update works more or less out of the box.

Hi-Angel commented on 2020-12-07 18:30

Python itself handles the installation directory

Ah, I see.

I added a new revision to this package 4 days ago to trigger a rebuild on Python 3.9 which should have fixed the package

Thanks, although I don't think it can help in this situation, since updating the system won't update AUR packages. If a user noticed their AUR package requires a rebuild, they'd just do it, disregarding current package revision.

languitar commented on 2020-12-07 12:59

This happened, because you last built the package when 3.8 was your installed Python version. Python itself handles the installation directory. I added a new revision to this package 4 days ago to trigger a rebuild on Python 3.9 which should have fixed the package because it was recreated with Python 3.9 then (assuming that your system was updated at that time and not only the AUR package)

Hi-Angel commented on 2020-12-07 11:46

I'm not sure if it's possible with ABS, but I think the PKGBUILD should detect the current python version in build-time, and make a hard dependency on it.

It would work around the following problem: package may get installed into /usr/lib/python3.8/site-packages/pyls_mypy directory. Then, python gets a version bump, and its working dir becomes /usr/lib/python3.9/…. The …/python3.8/… is now ignored, and the plugin won't load. This is what happened to me right now.

languitar commented on 2020-12-03 18:36

Basically every Python package is built this way and may fail with virtualenv, pyenv and other similar tools. So, if I patch this one, you will stumble across the next package that has the same "problem".

Just for the reference, some official package examples:

Also, the python packaging guide doesn't use absolute paths: https://wiki.archlinux.org/index.php/Python_package_guidelines

ojford commented on 2020-12-03 18:31

I've been tearing my hair out with this not working - turns out I had a venv activated when I installed it (finally figured it out with -Ql pyls-mypy).

I'd suggest changing python setup.py install to /usr/bin/python setup.py install. It'd be a funny thing to want to do deliberately, and if you did you wouldn't blindly expect that the PKGBUILD was written in such a way that it would work, so I think it's reasonable.