Module not found error with new package version #593

tmarti2 · 2019-11-22T09:55:13Z

I upgraded autojump to the 22.5.3-3 version, and when using cd or j, I receive this error :

Traceback (most recent call last):                                                                 
  File "/usr/bin/autojump", line 39, in <module>
    from autojump_argparse import ArgumentParser
ModuleNotFoundError: No module named 'autojump_argparse'

I downgraded it to the 22.5.3-1 version, and it works.
I'm using Arch linux.

The text was updated successfully, but these errors were encountered:

brandoncamenisch · 2019-11-22T16:29:15Z

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

anwalsh · 2019-11-22T19:13:00Z

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"

anwalsh · 2019-11-22T19:21:56Z

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.

Syphdias · 2019-11-23T20:27:32Z

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.

graysky2 · 2019-11-24T12:45:02Z

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 -

Did you build with makepkg or some AUR helper (don't use an AUR helper)?
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.

tmarti2 · 2019-11-24T14:49:45Z

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.

graysky2 · 2019-11-24T15:17:54Z

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.

pwoehrer · 2019-11-25T16:51:10Z

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.

graysky2 · 2019-11-25T18:02:32Z

@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.

noelar · 2019-11-26T11:15:18Z

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.

graysky2 · 2019-11-26T18:33:35Z

@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.

pwoehrer · 2019-11-26T19:24:33Z

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.

graysky2 · 2019-11-26T20:01:30Z

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?

pwoehrer · 2019-11-26T21:32:48Z

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.

sduqlsc · 2019-11-27T04:20:11Z

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.

graysky2 · 2019-11-27T20:41:00Z

@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
...

pwoehrer · 2019-11-29T19:33:46Z

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. :-(

graysky2 · 2019-12-02T19:44:42Z

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

suzaku · 2020-11-26T00:43:49Z

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)

heppen · 2020-12-18T05:22:43Z

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/

suzaku · 2020-12-18T10:09:18Z

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.

graysky2 · 2020-12-18T10:40:46Z

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

AlbertCloete · 2022-01-11T10:08:37Z

yay -S autojump solved it for me.

bauxi · 2022-01-17T13:44:28Z

Simply reinstalling did not work for me. I had to choose cleanBuild All, when I was asked during install.

graysky2 mentioned this issue Nov 24, 2019

python>=3.8 (Wanted by: autojump) #594

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Module not found error with new package version #593

Module not found error with new package version #593

tmarti2 commented Nov 22, 2019

brandoncamenisch commented Nov 22, 2019

anwalsh commented Nov 22, 2019

anwalsh commented Nov 22, 2019

Syphdias commented Nov 23, 2019

graysky2 commented Nov 24, 2019 •

edited

tmarti2 commented Nov 24, 2019

graysky2 commented Nov 24, 2019 •

edited

pwoehrer commented Nov 25, 2019 •

edited

graysky2 commented Nov 25, 2019

noelar commented Nov 26, 2019

graysky2 commented Nov 26, 2019

pwoehrer commented Nov 26, 2019 •

edited

graysky2 commented Nov 26, 2019 •

edited

pwoehrer commented Nov 26, 2019

sduqlsc commented Nov 27, 2019

graysky2 commented Nov 27, 2019

pwoehrer commented Nov 29, 2019

graysky2 commented Dec 2, 2019

suzaku commented Nov 26, 2020

heppen commented Dec 18, 2020

suzaku commented Dec 18, 2020

graysky2 commented Dec 18, 2020

AlbertCloete commented Jan 11, 2022

bauxi commented Jan 17, 2022

Module not found error with new package version #593

Module not found error with new package version #593

Comments

tmarti2 commented Nov 22, 2019

brandoncamenisch commented Nov 22, 2019

anwalsh commented Nov 22, 2019

anwalsh commented Nov 22, 2019

Syphdias commented Nov 23, 2019

graysky2 commented Nov 24, 2019 • edited

tmarti2 commented Nov 24, 2019

graysky2 commented Nov 24, 2019 • edited

pwoehrer commented Nov 25, 2019 • edited

graysky2 commented Nov 25, 2019

noelar commented Nov 26, 2019

graysky2 commented Nov 26, 2019

pwoehrer commented Nov 26, 2019 • edited

graysky2 commented Nov 26, 2019 • edited

pwoehrer commented Nov 26, 2019

sduqlsc commented Nov 27, 2019

graysky2 commented Nov 27, 2019

pwoehrer commented Nov 29, 2019

graysky2 commented Dec 2, 2019

suzaku commented Nov 26, 2020

heppen commented Dec 18, 2020

suzaku commented Dec 18, 2020

graysky2 commented Dec 18, 2020

AlbertCloete commented Jan 11, 2022

bauxi commented Jan 17, 2022

graysky2 commented Nov 24, 2019 •

edited

graysky2 commented Nov 24, 2019 •

edited

pwoehrer commented Nov 25, 2019 •

edited

pwoehrer commented Nov 26, 2019 •

edited

graysky2 commented Nov 26, 2019 •

edited