Autojump: Module not found error with new package version

same here on manjaro :(
OS: Manjaro 18.1.3 Juhraya
Kernel: x86_64 Linux 5.3.11-1-MANJARO

Found the same on Manjaro:

Linux version 5.3.11-1-MANJARO
DISTRIB_ID=ManjaroLinux
DISTRIB_RELEASE=18.1.3
DISTRIB_CODENAME=Juhraya
DISTRIB_DESCRIPTION="Manjaro Linux"

Fixed the behavior via removing autojump using yay and reinstalling with a clean build using the same.

This resolved the behavior after re-sourcing my configuration file for zsh.

Also Manjaro 18.1.3 here. Removing and reinstalling the autojump package didn't work for me. Reinstalling failed with

==> Error: Could not find all required packages:
    python>=3.8 (Wanted by: autojump)

My python version is indeed 3.7.4.

The package autojump-git seems to work for now.

I maintain the autojump package for Arch Linux via the AUR.

• 22.5.3-5 includes a versioned python dependency and incorporates the solution suggested by hefteg in FS#60929
• 22.5.3-1 does not have this move to site-packages

I want to know if the cause of the module not found error is due to the implementation of hefteg's fix.

I use zsh on Arch and do not experience this, so @tmarti2 -

1. Did you build with makepkg or some AUR helper (don't use an AUR helper)?
2. Do you have anything in your ~/.zshrc or any zsh file referencing or sourcing anything for autojump?

Manjaro users: Know that Manjaro != Arch ... based on @Syphdias comment, your python version is behind Arch's which is why you cannot install.

You can change the depends= and the _python= in the PKGBUILD to python3.7 and rebuild and it should work for you.

yeah I'm under Manjaro, my bad.
I'm using Yay, and I'm pretty sure I have a line mentioning autojump in .zshrc, but I can't remember what.
I'll try tomorrow.

I assume yay is an AUR helper. They cause more problems than they solve. Modify the PKGBUILD as I mentioned and build with makepkg and I think you'll be fine... probably close this issue since it's not upstream related.

Also Manjaro 18.1.3 here. Removing and reinstalling the autojump package didn't work for me. Reinstalling failed with

==> Error: Could not find all required packages:
    python>=3.8 (Wanted by: autojump)

My python version is indeed 3.7.4.

The package autojump-git seems to work for now.

Autojump-git is now broken on Manjaro as well. Do NOT upgrade or install.

@pwoehrer -

Manjaro users: Know that Manjaro != Arch ... based on @Syphdias comment, your python version is behind Arch's which is why you cannot install. You can change the depends= and the _python= in the PKGBUILD to python3.7 and rebuild and it should work for you.

The AUR pkg install is just all wrong. The required modules were installed in usr/lib/site-packages folder outside of ../lib/python3.8/site-packages.

@noelar - /usr/lib/python3.8/site-packages/ is the correct place for these. See: https://bugs.archlinux.org/task/60929

Feel free to correct me if I am mistaken.

Graysky2 is correct: The place to install the libraries is indeed the site-packages directory. But...

Autojump as such only needs python >= 2.6. Is there a compelling reason to force >= 3.8?

If not, I'd suggest getting the correct python version of the system by doing something like this:

depends=('python>=2.6`)
_python=python${/usr/bin/env python -V | grep -Po '\d+\.\d+'}

This would eliminate the need to mess with the package in the prepare section as well as use the correct paths for the system.

Forcing the python version to 3.8 breaks the package for every system (Arch as well as derivatives) that does not or can not for whatever reason use the latest version of python. Additionally the package will be broken once the version shipped with Arch changes again.

Disclaimer: I am neither a programmer nor a package maintainer, so parts or all of what I have said may be utter nonsense or there may be more concise or elegant ways to achieve the same goal.

I like the idea but if I that would only work if the build machine had the same version of python as the client machine. In other words, one could build on a machine with 3.8 (Arch) but then install on current Manjaro (3.7). Assuming there are no differences 3.7 vs 3.8 it would just have an extra directory....

Does anyone know for sure if there are in fact differences, ie will autojump built against python3.8 work on a system with python3.7?

Is a non-versioned /usr/lib/python/site-packages/ acceptable or is it versioned for the reason I am asking about above?

I am by no means a python expert, so maybe I do not understand the exact problem.

From looking at autojump it is pure python (well and some shell flavours, but that should not be the point). The compile statements in PKGBUILD produce intermediate byte code (*.pyc) for the libraries (as much as I know those are version dependent, but discarded anyway at run time if the versions do not match). Usually the byte code is generated beforehand to enable users who do not have write permissions to benefit from the speed up as well.
Considering that write permissions are necessary to install anyway, it would make sense to me to generate the byte code for the libraries at install time, not at build time.

The python source of autojump is written in a way so it does not care which version of python interpreter is available, as long as it is >= 2.6.

But again: Not an expert, just liking autojump and dabbling in python.

Manjaro here too,

like @graysky2 said,

1. wget https://aur.archlinux.org/cgit/aur.git/snapshot/autojump.tar.gz
2. tar -xzvf autojump.tar.gz
3. cd autojump && vim PKGBUILD

# depends=('python>=3.7')
# _python=python3.7
4. replace all the 3.8 to 3.7
5. makepkg
6. sudo pacman -U autojump-22.5.3-5-any.pkg.tar.xz

I think that would be ok.

@pwoehrer - The problem is that one needs to rebuild this against a major python version release (ie 3.6 to 3.7 or 3.7 to 3.8). If it were in the official repos, the maintainer would just bump the pkgver and change the _python variable but since it's the AUR, I have to force it with the versioned python3 dep.

If there is a smarter way to maintain consistency please share it with me.

For example, if you you build autojump against python v3.7.x, you will get:

% pacman -Ql autojump                                                                                       
...
autojump /usr/lib/python3/site-packages/__pycache__/autojump_argparse.cpython-37.opt-1.pyc
autojump /usr/lib/python3/site-packages/__pycache__/autojump_argparse.cpython-37.pyc
autojump /usr/lib/python3/site-packages/__pycache__/autojump_data.cpython-37.opt-1.pyc
autojump /usr/lib/python3/site-packages/__pycache__/autojump_data.cpython-37.pyc
autojump /usr/lib/python3/site-packages/__pycache__/autojump_match.cpython-37.opt-1.pyc
autojump /usr/lib/python3/site-packages/__pycache__/autojump_match.cpython-37.pyc
autojump /usr/lib/python3/site-packages/__pycache__/autojump_utils.cpython-37.opt-1.pyc
autojump /usr/lib/python3/site-packages/__pycache__/autojump_utils.cpython-37.pyc
...

I am afraid as long as the compiled *.pyc are included in the package, there is no way to make this happen. But as I said before, there is no actual need to include them in the package. It would be better to generate them at installation time, as they would use the python version of the system and they are platform independent. *.pc are meant to be created when a library is run the first time.

Also they are not strictly necessary for autojump to function, they are just there to provide a bit of a speed up on systems where the user has no write permission to the site-package directory.

So: No I don't think there is a better way if they *.pyc need to be included in the package. :-(

The problem with no doing it this way is outlined in FS#60929

If we implement autojump in a compiled language, we don't have to worry about this kind of issues. I've rewritten it in Go and have been using it for a long time, maybe you want to give it a try. (https://github.com/suzaku/shonenjump)

I meet this problem when I upgrade python3.8 to python3.9, so I just copy some autojump package in python3.8 to python3.9, and I solved this problem.

cp /usr/lib/python3.8/site-packages/autojump* /usr/lib/python3.9/site-packages/

I meet this problem when I upgrade python3.8 to python3.9, so I just copy some autojump package in python3.8 to python3.9, and I solved this problem.

cp /usr/lib/python3.8/site-packages/autojump* /usr/lib/python3.9/site-packages/

You can give my tool a try, it can be easily installed with brew.

@heppen - You have to rebuild like any python script on a major version bump.