Autojump: Módulo não encontrado erro com nova versão do pacote

Criado em 22 nov. 2019  ·  22Comentários  ·  Fonte: wting/autojump

Atualizei o autojump para a versão 22.5.3-3 e, ao usar cd ou j, recebo este erro:

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

Fiz o downgrade para a versão 22.5.3-1 e funciona.
Estou usando o Arch linux.

Comentários muito úteis

Encontro esse problema quando atualizo python3.8 para python3.9, então apenas copio algum pacote autojump em python3.8 para python3.9 e resolvo esse problema.

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

Todos 22 comentários

o mesmo aqui no Manjaro :(
OS: Manjaro 18.1.3 Juhraya
Kernel: x86_64 Linux 5.3.11-1-MANJARO

Encontrado o mesmo em Manjaro:

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

Corrigido o comportamento removendo autojump usando yay e reinstalando com uma compilação limpa usando o mesmo.

Isso resolveu o comportamento após recompor meu arquivo de configuração para zsh .

Também Manjaro 18.1.3 aqui. Remover e reinstalar o pacote autojump não funcionou para mim. A reinstalação falhou com

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

Minha versão python é de fato 3.7.4.

O pacote autojump-git parece funcionar por enquanto.

Eu mantenho o pacote autojump para Arch Linux através do AUR.

  • 22.5.3-5 inclui uma dependência python com versão e incorpora a solução sugerida por hefteg no FS # 60929
  • 22.5.3-1 não tem essa mudança para pacotes de sites

Quero saber se a causa do erro do módulo não encontrado é devido à implementação da correção do hefteg.

Eu uso zsh no Arch e não experimento isso, então @ tmarti2 -

  1. Você construiu com makepkg ou algum auxiliar AUR (não use um auxiliar AUR)?
  2. Você tem algo em seu ~/.zshrc ou qualquer arquivo zsh referenciando ou fornecendo algo para autojump?

Usuários do Manjaro: Saiba que Manjaro! = Arch ... baseado no comentário de @Syphdias , sua versão do python está atrás da do Arch, por isso você não pode instalar.

Você pode alterar depends= e _python= no PKGBUILD para python3.7 e reconstruir e deve funcionar para você.

sim, estou sob Manjaro, meu mal.
Estou usando Yay e tenho quase certeza de que tenho uma linha mencionando autojump em .zshrc, mas não consigo me lembrar o quê.
Vou tentar amanhã.

Presumo que yay seja um ajudante AUR. Eles causam mais problemas do que resolvem. Modifique o PKGBUILD como mencionei e construa com makepkg e acho que você ficará bem ... provavelmente feche este problema, pois não está relacionado ao upstream.

Também Manjaro 18.1.3 aqui. Remover e reinstalar o pacote autojump não funcionou para mim. A reinstalação falhou com

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

Minha versão python é de fato 3.7.4.

O pacote autojump-git parece funcionar por enquanto.

O Autojump-git também está quebrado no Manjaro. NÃO atualize ou instale.

@pwoehrer -

Usuários do Manjaro: Saiba que Manjaro! = Arch ... baseado no comentário de @Syphdias , sua versão do python está atrás da do Arch, por isso você não pode instalar. Você pode alterar o depends = e o _python = no PKGBUILD para python3.7 e reconstruir e deve funcionar para você.

A instalação do pacote AUR está totalmente errada. Os módulos necessários foram instalados na pasta usr / lib / site-packages fora de ../lib/python3.8/site-packages.

@noelar - /usr/lib/python3.8/site-packages/ é o lugar correto para eles. Veja: https://bugs.archlinux.org/task/60929

Sinta-se à vontade para me corrigir se eu estiver enganado.

Graysky2 está correto: o local para instalar as bibliotecas é de fato o diretório de pacotes do site. Mas...

O Autojump como tal só precisa de python> = 2.6. Existe uma razão convincente para forçar> = 3,8?

Caso contrário, sugiro obter a versão correta do sistema em Python fazendo algo assim:

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

Isso eliminaria a necessidade de bagunçar o pacote na seção de preparação, bem como usar os caminhos corretos para o sistema.

Forçar a versão python para 3.8 quebra o pacote para todos os sistemas (Arch e também derivados) que não usam ou não podem, por qualquer motivo, usar a versão mais recente de python. Além disso, o pacote será quebrado assim que a versão enviada com o Arch mudar novamente.

Isenção de responsabilidade: eu não sou um programador nem um mantenedor de pacote, então partes ou tudo o que eu disse pode ser um total absurdo ou pode haver maneiras mais concisas ou elegantes de atingir o mesmo objetivo.

Eu gosto da ideia, mas isso só funcionaria se a máquina de construção tivesse a mesma versão de python da máquina cliente. Em outras palavras, pode-se construir em uma máquina com 3.8 (Arch), mas depois instalar no Manjaro atual (3.7). Supondo que não haja diferenças 3,7 vs 3,8, ele teria apenas um diretório extra ....

Alguém sabe com certeza se existem diferenças de fato, ou seja, o autojump construído contra python3.8 funcionará em um sistema com python3.7?

Um /usr/lib/python/site-packages/ sem versão é aceitável ou ele tem versão pelo motivo que estou perguntando acima?

Não sou um especialista em python, então talvez eu não entenda o problema exato.

Olhando para autojump, é puro python (bem e alguns sabores de shell, mas esse não deve ser o ponto). As instruções de compilação em PKGBUILD produzem código de byte intermediário (* .pyc) para as bibliotecas (tanto quanto eu sei, elas dependem da versão, mas descartadas de qualquer maneira em tempo de execução se as versões não corresponderem). Normalmente, o código de byte é gerado de antemão para permitir que os usuários que não têm permissão de gravação também se beneficiem da aceleração.
Considerando que as permissões de gravação são necessárias para instalar de qualquer maneira, faria sentido para mim gerar o código de bytes para as bibliotecas no momento da instalação, não no momento da compilação.

O código-fonte python do autojump é escrito de uma forma que não importa qual versão do interpretador python está disponível, contanto que seja> = 2.6.

Mas, novamente: não é um especialista, apenas gosta de autojump e de brincar com python.

Manjaro aqui também,

como @ greysky2 disse,

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

Eu acho que estaria tudo bem.

@pwoehrer - O problema é que é necessário reconstruir isso em relação a uma versão principal do python (ou seja, 3.6 a 3.7 ou 3.7 a 3.8). Se fosse nos repositórios oficiais, o mantenedor apenas colidiria com pkgver e mudaria a variável _python , mas como é o AUR, tenho que forçá-lo com o python3 dep.

Se houver uma maneira mais inteligente de manter a consistência, compartilhe-a comigo.

Por exemplo, se você construir autojump em python v3.7.x, você obterá:

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

Infelizmente, enquanto os * .pyc compilados estiverem incluídos no pacote, não haverá como fazer isso acontecer. Mas, como eu disse antes, não há necessidade real de incluí-los no pacote. Seria melhor gerá-los no momento da instalação, pois usariam a versão python do sistema e são independentes de plataforma. * .pc devem ser criados quando uma biblioteca é executada pela primeira vez.

Além disso, eles não são estritamente necessários para que o autojump funcione, eles estão lá apenas para fornecer um pouco de velocidade em sistemas onde o usuário não tem permissão de gravação no diretório do pacote do site.

Portanto: Não, não acho que haja melhor maneira se eles * .pyc precisarem ser incluídos no pacote. :-(

O problema de não fazer dessa maneira é descrito no FS # 60929

Se implementarmos autojump em uma linguagem compilada, não precisamos nos preocupar com esse tipo de problema. Eu o reescrevi em Go e já o uso há muito tempo, talvez você queira tentar. (https://github.com/suzaku/shonenjump)

Encontro esse problema quando atualizo python3.8 para python3.9, então apenas copio algum pacote autojump em python3.8 para python3.9 e resolvo esse problema.

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

Encontro esse problema quando atualizo python3.8 para python3.9, então apenas copio algum pacote autojump em python3.8 para python3.9 e resolvo esse problema.

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

Você pode experimentar minha ferramenta, ela pode ser facilmente instalada com brew .

@heppen - você tem que reconstruir como qualquer script python em um

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

grota picture grota  ·  16Comentários

pgrm picture pgrm  ·  4Comentários

qazip picture qazip  ·  3Comentários

shepherdwind picture shepherdwind  ·  11Comentários

mbigras picture mbigras  ·  3Comentários