Autojump: Erreur de module introuvable avec la nouvelle version du package

idem ici sur manjaro :(
Système d'exploitation : Manjaro 18.1.3 Juhraya
Noyau : x86_64 Linux 5.3.11-1-MANJARO

Trouvé le même sur Manjaro :

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

Correction du comportement en supprimant autojump utilisant yay et en réinstallant avec une version propre en utilisant le même.

Cela a résolu le problème après avoir re-sourcer mon fichier de configuration pour zsh .

Aussi Manjaro 18.1.3 ici. La suppression et la réinstallation du package autojump n'ont pas fonctionné pour moi. Échec de la réinstallation avec

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

Ma version python est bien la 3.7.4.

Le package autojump-git semble fonctionner pour le moment.

Je maintiens le package autojump pour Arch Linux via l'AUR.

• 22.5.3-5 inclut une dépendance python versionnée et intègre la solution suggérée par hefteg dans FS#60929
• 22.5.3-1 n'a pas ce déplacement vers les packages de site

Je veux savoir si la cause de l'erreur module non trouvé est due à la mise en œuvre du correctif de hefteg.

J'utilise zsh sur Arch et je n'en ai pas l'expérience, donc @tmarti2 -

1. Avez-vous construit avec makepkg ou un assistant AUR (n'utilisez pas d'assistant AUR) ?
2. Avez-vous quelque chose dans votre ~/.zshrc ou un fichier zsh référençant ou source quelque chose pour autojump ?

Utilisateurs de Manjaro : Sachez que Manjaro != Arch ... basé sur le commentaire de @Syphdias , votre version python est derrière celle d'Arch, c'est pourquoi vous ne pouvez pas l'installer.

Vous pouvez changer le depends= et le _python= dans le PKGBUILD en python3.7 et reconstruire et cela devrait fonctionner pour vous.

ouais je suis sous Manjaro, mon mauvais.
J'utilise Yay et je suis presque sûr d'avoir une ligne mentionnant autojump dans .zshrc, mais je ne me souviens plus quoi.
J'essaierai demain.

Je suppose que yay est un assistant AUR. Ils causent plus de problèmes qu'ils n'en résolvent. Modifiez le PKGBUILD comme je l'ai mentionné et construisez avec makepkg et je pense que tout ira bien... fermez probablement ce problème car il n'est pas lié en amont.

Aussi Manjaro 18.1.3 ici. La suppression et la réinstallation du package autojump n'ont pas fonctionné pour moi. Échec de la réinstallation avec

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

Ma version python est bien la 3.7.4.

Le package autojump-git semble fonctionner pour le moment.

L'autojump-git est maintenant également cassé sur Manjaro. NE PAS mettre à niveau ou installer.

@pwoehrer -

Utilisateurs de Manjaro : Sachez que Manjaro != Arch ... basé sur le commentaire de @Syphdias , votre version python est derrière celle d'Arch, c'est pourquoi vous ne pouvez pas l'installer. Vous pouvez changer le depend= et le _python= dans le PKGBUILD en python3.7 et reconstruire et cela devrait fonctionner pour vous.

L'installation du paquet AUR est tout simplement fausse. Les modules requis ont été installés dans le dossier usr/lib/site-packages en dehors de ../lib/python3.8/site-packages.

@noelar - /usr/lib/python3.8/site-packages/ est le bon endroit pour ceux-ci. Voir : https://bugs.archlinux.org/task/60929

N'hésitez pas à me corriger si je me trompe.

Graysky2 a raison : l'endroit où installer les bibliothèques est bien le répertoire site-packages. Mais...

Autojump en tant que tel n'a besoin que de python >= 2.6. Existe-t-il une raison impérieuse de forcer >= 3,8 ?

Sinon, je suggérerais d'obtenir la bonne version python du système en faisant quelque chose comme ceci :

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

Cela éliminerait le besoin de jouer avec le package dans la section de préparation et d'utiliser les chemins corrects pour le système.

Forcer la version python à 3.8 casse le package pour chaque système (Arch ainsi que les dérivés) qui n'utilise pas ou ne peut pas pour une raison quelconque utiliser la dernière version de python. De plus, le package sera cassé une fois que la version livrée avec Arch changera à nouveau.

Avis de non-responsabilité : je ne suis ni un programmeur ni un responsable de paquet, donc tout ou partie de ce que j'ai dit peut être complètement absurde ou il peut y avoir des moyens plus concis ou plus élégants pour atteindre le même objectif.

J'aime l'idée mais si cela ne fonctionnerait que si la machine de construction avait la même version de python que la machine cliente. En d'autres termes, on pourrait construire sur une machine avec 3.8 (Arch) mais ensuite installer sur le Manjaro actuel (3.7). En supposant qu'il n'y ait pas de différences entre 3.7 et 3.8, il y aurait juste un répertoire supplémentaire....

Est-ce que quelqu'un sait avec certitude s'il existe en fait des différences, c'est-à-dire que l'autojump construit contre python3.8 fonctionnera sur un système avec python3.7?

Un /usr/lib/python/site-packages/ non versionné est-il acceptable ou est-il versionné pour la raison que je demande ci-dessus ?

Je ne suis en aucun cas un expert en python, alors peut-être que je ne comprends pas le problème exact.

En regardant autojump, il s'agit de python pur (enfin et de quelques saveurs de coquille, mais cela ne devrait pas être le problème). Les instructions de compilation dans PKGBUILD produisent du code d'octet intermédiaire (*.pyc) pour les bibliothèques (pour autant que je sache, celles-ci dépendent de la version, mais sont de toute façon supprimées au moment de l'exécution si les versions ne correspondent pas). Généralement, le byte code est généré au préalable pour permettre aux utilisateurs qui n'ont pas d'autorisations d'écriture de bénéficier également de l'accélération.
Étant donné que les autorisations d'écriture sont de toute façon nécessaires pour l'installation, il serait logique pour moi de générer le code d'octet pour les bibliothèques au moment de l'installation, et non au moment de la construction.

La source python d'autojump est écrite de manière à ce qu'elle ne se soucie pas de la version de l'interpréteur python disponible, tant qu'elle est >= 2.6.

Mais encore une fois : pas un expert, j'aime juste le saut automatique et le python.

Manjaro ici aussi,

comme @graysky2 l'a dit,

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

Je pense que ce serait bien.

@pwoehrer - Le problème est qu'il faut le reconstruire par rapport à une version majeure de python (c'est-à-dire 3.6 à 3.7 ou 3.7 à 3.8). S'il se trouvait dans les dépôts officiels, le mainteneur remplacerait simplement le pkgver et modifierait la variable _python mais comme il s'agit de l'AUR, je dois le forcer avec le dep python3 versionné.

S'il existe un moyen plus intelligent de maintenir la cohérence, veuillez le partager avec moi.

Par exemple, si vous construisez autojump contre python v3.7.x, vous obtiendrez :

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

Je crains que tant que les fichiers *.pyc compilés soient inclus dans le package, il n'y a aucun moyen d'y parvenir. Mais comme je l'ai déjà dit, il n'est pas vraiment nécessaire de les inclure dans le package. Il serait préférable de les générer au moment de l'installation, car ils utiliseraient la version python du système et ils sont indépendants de la plate-forme. *.pc sont destinés à être créés lors de la première exécution d'une bibliothèque.

De plus, ils ne sont pas strictement nécessaires au fonctionnement de l'autojump, ils sont juste là pour accélérer un peu les systèmes où l'utilisateur n'a pas d'autorisation d'écriture sur le répertoire site-package.

Donc : Non, je ne pense pas qu'il y ait de meilleur moyen s'ils *.pyc doivent être inclus dans le package. :-(

Le problème de ne pas procéder de cette manière est décrit dans FS # 60929

Si nous implémentons autojump dans un langage compilé, nous n'avons pas à nous soucier de ce genre de problèmes. Je l'ai réécrit en Go et je l'utilise depuis longtemps, peut-être que vous voulez l'essayer. (https://github.com/suzaku/shonenjump)

Je rencontre ce problème lorsque je mets à niveau python3.8 vers python3.9, donc je viens de copier un package autojump de python3.8 vers python3.9, et j'ai résolu ce problème.

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

Je rencontre ce problème lorsque je mets à niveau python3.8 vers python3.9, donc je viens de copier un package autojump de python3.8 vers python3.9, et j'ai résolu ce problème.

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

Vous pouvez essayer mon outil, il peut être facilement installé avec brew .

@heppen - Vous devez reconstruire comme n'importe quel script python sur une version majeure.