Autojump: Modul nicht gefunden Fehler mit neuer Paketversion

Erstellt am 22. Nov. 2019  ·  22Kommentare  ·  Quelle: wting/autojump

Ich habe Autojump auf die Version 22.5.3-3 aktualisiert und bei Verwendung von cd oder j erhalte ich diese Fehlermeldung:

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

Ich habe es auf die Version 22.5.3-1 heruntergestuft und es funktioniert.
Ich verwende Arch-Linux.

Hilfreichster Kommentar

Ich treffe dieses Problem, wenn ich python3.8 auf python3.9 aktualisiere, also kopiere ich einfach ein Autojump-Paket in python3.8 auf python3.9, und ich habe dieses Problem gelöst.

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

Alle 22 Kommentare

das gleiche hier auf manjaro :(
Betriebssystem: Manjaro 18.1.3 Juhraya
Kernel: x86_64 Linux 5.3.11-1-MANJARO

Habe das gleiche bei Manjaro gefunden:

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

Das Verhalten wurde behoben, indem autojump mit yay und mit einem sauberen Build neu installiert wurde.

Dadurch wurde das Verhalten behoben, nachdem meine Konfigurationsdatei für zsh .

Auch Manjaro 18.1.3 hier. Das Entfernen und Neuinstallieren des autojump Pakets hat bei mir nicht funktioniert. Neuinstallation fehlgeschlagen mit

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

Meine Python-Version ist tatsächlich 3.7.4.

Das Paket autojump-git scheint vorerst zu funktionieren.

Ich pflege das Autojump-Paket für Arch Linux über die AUR.

  • 22.5.3-5 enthält eine versionierte Python-Abhängigkeit und enthält die von hefteg vorgeschlagene Lösung in FS#60929
  • 22.5.3-1 hat diese Verschiebung nicht zu Site-Paketen

Ich möchte wissen, ob die Ursache für den Fehler "Modul nicht gefunden" auf die Implementierung von heftegs Fix zurückzuführen ist.

Ich verwende zsh auf Arch und erlebe dies nicht, also @tmarti2 -

  1. Hast du mit makepkg oder einem AUR-Helfer gebaut (kein AUR-Helfer verwenden)?
  2. Haben Sie etwas in Ihrer ~/.zshrc oder einer ZSH-Datei, die auf etwas für Autojump verweist oder es bezieht?

Manjaro-Benutzer: Wissen Sie, dass Manjaro != Arch ... basierend auf @Syphdias Kommentar ist Ihre Python-Version hinter der von Arch, weshalb Sie sie nicht installieren können.

Sie können depends= und _python= im PKGBUILD in python3.7 ändern und neu erstellen und es sollte für Sie funktionieren.

Ja, ich bin unter Manjaro, mein Böser.
Ich benutze Yay, und ich bin mir ziemlich sicher, dass ich in .zshrc eine Zeile habe, die Autojump erwähnt, aber ich kann mich nicht erinnern, was.
Ich werde es morgen versuchen.

Ich gehe davon aus, dass yay ein AUR-Helfer ist. Sie verursachen mehr Probleme als sie lösen. Ändern Sie das PKGBUILD wie ich erwähnt habe und bauen Sie mit makepkg und ich denke, es wird Ihnen gut gehen ... wahrscheinlich schließen Sie dieses Problem, da es nicht mit dem Upstream zu tun hat.

Auch Manjaro 18.1.3 hier. Das Entfernen und Neuinstallieren des autojump Pakets hat bei mir nicht funktioniert. Neuinstallation fehlgeschlagen mit

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

Meine Python-Version ist tatsächlich 3.7.4.

Das Paket autojump-git scheint vorerst zu funktionieren.

Autojump-git ist jetzt auch auf Manjaro kaputt. NICHT aktualisieren oder installieren.

@pwöhrer -

Manjaro-Benutzer: Wissen Sie, dass Manjaro != Arch ... basierend auf @Syphdias Kommentar ist Ihre Python-Version hinter der von Arch, weshalb Sie sie nicht installieren können. Sie können den abhängig= und den _python= im PKGBUILD in python3.7 ändern und neu erstellen und es sollte für Sie funktionieren.

Die Installation des AUR-Pakets ist einfach falsch. Die erforderlichen Module wurden im Ordner usr/lib/site-packages außerhalb von ../lib/python3.8/site-packages installiert.

@noelar - /usr/lib/python3.8/site-packages/ ist der richtige Ort dafür. Siehe: https://bugs.archlinux.org/task/60929

Korrigieren Sie mich gerne, wenn ich mich irre.

Graysky2 ist richtig: Der Ort, um die Bibliotheken zu installieren, ist tatsächlich das Verzeichnis site-packages. Aber...

Autojump als solches benötigt nur Python >= 2.6. Gibt es einen zwingenden Grund, >= 3.8 zu erzwingen?

Wenn nicht, würde ich vorschlagen, die richtige Python-Version des Systems zu erhalten, indem Sie Folgendes tun:

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

Dadurch entfällt die Notwendigkeit, mit dem Paket im Abschnitt "Vorbereiten" herumzuspielen und die richtigen Pfade für das System zu verwenden.

Das Erzwingen der Python-Version auf 3.8 bricht das Paket für jedes System (Arch sowie Derivate), das die neueste Version von Python nicht oder aus irgendeinem Grund nicht verwenden kann. Außerdem wird das Paket beschädigt, sobald sich die mit Arch ausgelieferte Version erneut ändert.

Haftungsausschluss: Ich bin weder Programmierer noch Paketbetreuer, daher können Teile oder alles, was ich gesagt habe, völliger Unsinn sein oder es mag prägnantere oder elegantere Wege geben, das gleiche Ziel zu erreichen.

Ich mag die Idee, aber wenn ich das würde, würde das nur funktionieren, wenn der Build-Computer die gleiche Python-Version wie der Client-Computer hätte. Mit anderen Worten, man könnte auf einer Maschine mit 3.8 (Arch) bauen, dann aber auf aktuellem Manjaro (3.7) installieren. Angenommen, es gibt keine Unterschiede zwischen 3.7 und 3.8, es hätte nur ein zusätzliches Verzeichnis ....

Weiß jemand mit Sicherheit, ob es tatsächlich Unterschiede gibt, dh wird Autojump, das gegen Python3.8 erstellt wurde, auf einem System mit Python3.7 funktionieren?

Ist ein nicht versioniertes /usr/lib/python/site-packages/ akzeptabel oder ist es aus dem Grund, nach dem ich oben frage, versioniert?

Ich bin kein Python-Experte, daher verstehe ich vielleicht das genaue Problem nicht.

Wenn man sich Autojump ansieht, ist es reine Python (naja und einige Muschelaromen, aber das sollte nicht der Punkt sein). Die Kompilierungsanweisungen in PKGBUILD erzeugen einen Zwischenbytecode (*.pyc) für die Bibliotheken (soweit ich weiß, sind diese versionsabhängig, werden aber zur Laufzeit trotzdem verworfen, wenn die Versionen nicht übereinstimmen). Üblicherweise wird der Bytecode vorher generiert, damit auch Benutzer ohne Schreibrechte von der Beschleunigung profitieren können.
In Anbetracht dessen, dass für die Installation ohnehin Schreibrechte erforderlich sind, wäre es für mich sinnvoll, den Bytecode für die Bibliotheken zur Installationszeit zu generieren, nicht zur Buildzeit.

Die Python-Quelle von Autojump ist so geschrieben, dass es egal ist, welche Version des Python-Interpreters verfügbar ist, solange sie >= 2.6 ist.

Aber nochmal: Kein Experte, mag nur Autojump und probiert Python aus.

Manjaro auch hier,

wie @graysky2 sagte,

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

Ich denke, das wäre in Ordnung.

@pwoehrer - Das Problem ist, dass man dies gegen eine größere Python-Version (dh 3.6 bis 3.7 oder 3.7 bis 3.8) neu pkgver stoßen und die Variable _python ändern, aber da es die AUR ist, muss ich es mit der versionierten Python3-Dep erzwingen.

Wenn es einen klügeren Weg gibt, die Konsistenz zu wahren, teilen Sie ihn mir bitte mit.

Wenn Sie beispielsweise Autojump gegen Python v3.7.x erstellen, erhalten Sie:

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

Ich fürchte, solange die kompilierten *.pyc im Paket enthalten sind, gibt es keine Möglichkeit, dies zu erreichen. Aber wie ich schon sagte, es ist nicht notwendig, sie in das Paket aufzunehmen. Es wäre besser, sie zum Zeitpunkt der Installation zu generieren, da sie die Python-Version des Systems verwenden und plattformunabhängig sind. *.pc sollen erstellt werden, wenn eine Bibliothek zum ersten Mal ausgeführt wird.

Außerdem sind sie nicht unbedingt erforderlich, damit Autojump funktioniert, sie dienen nur dazu, auf Systemen, auf denen der Benutzer keine Schreibberechtigung für das Site-Paket-Verzeichnis hat, etwas zu beschleunigen.

Also: Nein, ich denke, es gibt keinen besseren Weg, wenn sie *.pyc im Paket enthalten müssen. :-(

Das Problem, dies nicht auf diese Weise zu tun, wird in FS#60929 beschrieben

Wenn wir Autojump in einer kompilierten Sprache implementieren, müssen wir uns um diese Art von Problemen nicht kümmern. Ich habe es in Go umgeschrieben und benutze es schon lange, vielleicht möchtest du es ausprobieren. (https://github.com/suzaku/shonenjump)

Ich treffe dieses Problem, wenn ich python3.8 auf python3.9 aktualisiere, also kopiere ich einfach ein Autojump-Paket in python3.8 auf python3.9, und ich habe dieses Problem gelöst.

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

Ich treffe dieses Problem, wenn ich python3.8 auf python3.9 aktualisiere, also kopiere ich einfach ein Autojump-Paket in python3.8 auf python3.9, und ich habe dieses Problem gelöst.

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

Sie können mein Tool ausprobieren, es lässt sich einfach mit brew installieren.

@heppen - Sie müssen wie jedes Python-Skript auf einem Hauptversions-Bump neu

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen