Autojump: Error de módulo no encontrado con nueva versión del paquete

lo mismo aquí en manjaro :(
SO: Manjaro 18.1.3 Juhraya
Núcleo: x86_64 Linux 5.3.11-1-MANJARO

Encontré lo mismo en Manjaro:

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

Se corrigió el comportamiento al eliminar autojump usando yay y reinstalar con una compilación limpia usando lo mismo.

Esto resolvió el comportamiento después de volver a obtener mi archivo de configuración por zsh .

También Manjaro 18.1.3 aquí. Eliminar y reinstalar el paquete autojump no funcionó para mí. La reinstalación falló con

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

Mi versión de Python es de hecho 3.7.4.

El paquete autojump-git parece funcionar por ahora.

Mantengo el paquete autojump para Arch Linux a través de AUR.

• 22.5.3-5 incluye una dependencia de Python versionada e incorpora la solución sugerida por hefteg en FS # 60929
• 22.5.3-1 no tiene este movimiento a paquetes de sitio

Quiero saber si la causa del error de módulo no encontrado se debe a la implementación de la solución de hefteg.

Uso zsh en Arch y no experimento esto, así que @ tmarti2 -

1. ¿Creó con makepkg o algún ayudante AUR (no use un ayudante AUR)?
2. ¿Tiene algo en su ~/.zshrc o algún archivo zsh que haga referencia u obtenga algo para autojump?

Usuarios de Manjaro: Sepa que Manjaro! = Arch ... basado en el comentario de @Syphdias , su versión de Python está detrás de la de Arch, por lo que no puede instalarla.

Puede cambiar depends= y _python= en PKGBUILD a python3.7 y reconstruir y debería funcionar para usted.

si estoy bajo Manjaro, mi mal.
Estoy usando Yay, y estoy bastante seguro de que tengo una línea que menciona el salto automático en .zshrc, pero no recuerdo qué.
Lo intentaré mañana.

Supongo que yay es un ayudante de AUR. Causan más problemas de los que resuelven. Modifique PKGBUILD como mencioné y compile con makepkg y creo que estará bien ... probablemente cierre este problema ya que no está relacionado con el flujo ascendente.

También Manjaro 18.1.3 aquí. Eliminar y reinstalar el paquete autojump no funcionó para mí. La reinstalación falló con

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

Mi versión de Python es de hecho 3.7.4.

El paquete autojump-git parece funcionar por ahora.

Autojump-git ahora también está roto en Manjaro. NO actualice ni instale.

@pwoehrer -

Usuarios de Manjaro: ¡Sepa que Manjaro! = Arch ... basado en el comentario de @Syphdias , su versión de Python está detrás de la de Arch, por lo que no puede instalarla. Puede cambiar el depende = y el _python = en el PKGBUILD a python3.7 y reconstruir y debería funcionar para usted.

La instalación del paquete AUR es simplemente incorrecta. Los módulos necesarios se instalaron en la carpeta usr / lib / site-packages fuera de ../lib/python3.8/site-packages.

@noelar - /usr/lib/python3.8/site-packages/ es el lugar correcto para estos. Ver: https://bugs.archlinux.org/task/60929

No dude en corregirme si me equivoco.

Graysky2 tiene razón: el lugar para instalar las bibliotecas es de hecho el directorio site-packages. Pero...

Autojump como tal solo necesita python> = 2.6. ¿Existe una razón de peso para forzar> = 3.8?

De lo contrario, sugeriría obtener la versión correcta de Python del sistema haciendo algo como esto:

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

Esto eliminaría la necesidad de meterse con el paquete en la sección de preparación, así como utilizar las rutas correctas para el sistema.

Forzar la versión 3.8 de Python rompe el paquete para todos los sistemas (tanto Arch como derivados) que no pueden o no pueden, por alguna razón, usar la última versión de Python. Además, el paquete se romperá una vez que la versión enviada con Arch cambie nuevamente.

Descargo de responsabilidad: no soy programador ni mantenedor de paquetes, por lo que parte o todo lo que he dicho puede ser una tontería total o puede haber formas más concisas o elegantes de lograr el mismo objetivo.

Me gusta la idea, pero si eso solo funcionaría si la máquina de compilación tuviera la misma versión de Python que la máquina cliente. En otras palabras, uno podría construir en una máquina con 3.8 (Arch) pero luego instalarlo en el Manjaro actual (3.7). Suponiendo que no hay diferencias 3.7 vs 3.8, solo tendría un directorio adicional ...

¿Alguien sabe con certeza si de hecho hay diferencias, es decir, el autojump construido contra python3.8 funcionará en un sistema con python3.7?

¿Es aceptable un /usr/lib/python/site-packages/ versión o está versionado por la razón por la que estoy preguntando arriba?

De ninguna manera soy un experto en Python, así que tal vez no entiendo el problema exacto.

Al mirar autojump, es python puro (bueno y algunos sabores de shell, pero ese no debería ser el punto). Las declaraciones de compilación en PKGBUILD producen un código de bytes intermedio (* .pyc) para las bibliotecas (por lo que sé, son dependientes de la versión, pero se descartan de todos modos en tiempo de ejecución si las versiones no coinciden). Por lo general, el código de bytes se genera de antemano para permitir que los usuarios que no tienen permisos de escritura también se beneficien de la aceleración.
Teniendo en cuenta que los permisos de escritura son necesarios para instalar de todos modos, tendría sentido para mí generar el código de bytes para las bibliotecas en el momento de la instalación, no en el momento de la compilación.

La fuente de Python de autojump está escrita de tal manera que no le importa qué versión del intérprete de Python esté disponible, siempre que sea> = 2.6.

Pero de nuevo: no soy un experto, solo me gusta el salto automático y me gusta Python.

Manjaro aqui tambien,

como dijo @ graysky2 ,

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

Creo que estaría bien.

@pwoehrer : el problema es que uno necesita reconstruir esto contra una versión principal de Python (es decir, 3.6 a 3.7 o 3.7 a 3.8). Si estuviera en los repositorios oficiales, el mantenedor simplemente golpearía el pkgver y cambiaría la variable _python pero como es el AUR, tengo que forzarlo con la versión de python3 dep.

Si existe una forma más inteligente de mantener la coherencia, compártala conmigo.

Por ejemplo, si construye autojump contra python v3.7.x, obtendrá:

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

Me temo que mientras el * .pyc compilado esté incluido en el paquete, no hay forma de que esto suceda. Pero como dije antes, no es necesario incluirlos en el paquete. Sería mejor generarlos en el momento de la instalación, ya que usarían la versión Python del sistema y son independientes de la plataforma. * .pc están destinados a crearse cuando se ejecuta una biblioteca por primera vez.

Además, no son estrictamente necesarios para que funcione autojump, solo están ahí para proporcionar un poco de velocidad en sistemas donde el usuario no tiene permiso de escritura en el directorio del paquete del sitio.

Entonces: No, no creo que haya una mejor manera si es necesario incluir * .pyc en el paquete. :-(

El problema de no hacerlo de esta manera se describe en FS # 60929

Si implementamos autojump en un lenguaje compilado, no tenemos que preocuparnos por este tipo de problemas. Lo he reescrito en Go y lo he estado usando durante mucho tiempo, tal vez quieras probarlo. (https://github.com/suzaku/shonenjump)

Me encuentro con este problema cuando actualizo python3.8 a python3.9, así que simplemente copio un paquete de salto automático en python3.8 a python3.9, y resolví este problema.

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

Me encuentro con este problema cuando actualizo python3.8 a python3.9, así que simplemente copio un paquete de salto automático en python3.8 a python3.9, y resolví este problema.

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

Puede probar mi herramienta, se puede instalar fácilmente con brew .

@heppen : tienes que reconstruir como cualquier script de Python en un