¿Cómo hago para que Vim pueda ejecutar python y python3 en un sistema Linux en la misma sesión?

En los sistemas Linux, Vim empaquetado generalmente solo tiene uno de los dos pythono está python3habilitado. Es posible que ambos estén habilitados (usando python/dyny python3/dyn), pero durante una sesión, solo se puede usar uno. Esta discusión de la lista de correo decía :

Depende de cómo se construyan las bibliotecas de Python. En los sistemas basados en Debian (por razones que no recuerdo de antemano), están construidos de tal manera que RTLD_GLOBAL debe usarse para obtener acceso a los símbolos. Esto evita cargar libpython2.xy libpython3.x en el mismo proceso.

¿Qué se puede hacer para habilitar la carga de ambos en la misma sesión?

Opciones que puedo ver:

Reconstruya los paquetes Python {2,3} para que RTLD_GLOBAL(sea lo que sea) no sea necesario.
De alguna manera, carga la biblioteca antes para que Vim la descargue (?!). (¿Es eso posible?)

Para cualquier detalle de la distribución, asuma, en orden creciente de especificidad:

Basado en Debian
Ubuntu
Ubuntu 14.04
O, Arch Linux, si un sistema basado en Debian es demasiado complejo.

Tenga en cuenta que tengo que construir Vim con soporte de carga dinámica para ambos, por lo que construir Vim no es un problema.

linux vimscript-python

— muru
fuente

Respuestas:

Soy el actual mantenedor de Vim para Debian y la persona citada en la discusión de la lista de correo referenciada.

Como dijiste, esta no es una pregunta sobre Vim. Se trata de construir el software con el que Vim se vincula de una manera que satisfaga sus necesidades. Hay una discusión más exhaustiva (al menos para el aspecto de Debian) del problema en un error que solicita que Python3 se habilite en el paquete Vim de Debian.

Esto se reduce a

El paquete Python de Debian no vincula las extensiones de Python con la biblioteca compartida libpython relevante. Esto es lo que hace que el paquete Vim de Debian requiera el uso RTLD_GLOBALcuando se usa dlopen()para cargar dinámicamente los enlaces del lenguaje Python.
No hay buenas maneras de expresar la relación entre los paquetes de Vim y las bibliotecas cargadas dinámicamente para garantizar que se actualicen juntas cuando sea apropiado. Incluso si se resolviera el primer punto, este problema aún me impediría habilitar la carga dinámica del soporte de Python.

El punto principal de cargar dinámicamente el soporte de idiomas en Vim es no requerir que los usuarios instalen bibliotecas que no usarán. Esto significa que el paquete Vim no puede especificar una dependencia rígida en una versión mínima de una biblioteca.

Por lo tanto, si Vim se compila contra una versión más nueva de una biblioteca que no es compatible con la versión anterior y el usuario no las actualiza juntas, Vim se bloqueará. Esto no es algo que quiero que encuentren los usuarios de los paquetes.

Me encantaría volver a habilitar la carga dinámica de soporte de idiomas (estuvo disponible por un corto tiempo en 2010-2011), pero los problemas anteriores deben resolverse primero.

A partir de la versión 2: 7.4.2330-1 , el paquete de Debian ha cambiado a usar Python3 en lugar de Python2 para los enlaces de Python.

Como alternativa, el paquete neovim admite el uso de Python2 y Python3 desde el mismo proceso nvim, ya que el soporte de Python es proporcionado por módulos externos (los paquetes python-neovim y python3-neovim ). La externalización del código Python, en lugar de incrustarlo como lo hace Vim, evita el problema de tratar cómo se construye libpython.

— jamessan
fuente

"Esto significa que el paquete Vim no puede especificar una dependencia dura en una versión mínima de una biblioteca". Supongo que es por eso que Debian no tiene paquetes separados para Vim + Python2 y Vim + Python3 como Arch Linux.

— muru

@muru Python es solo uno de los enlaces de idiomas disponibles. Proporcionar combinaciones de paquetes para los diferentes idiomas y kits de herramientas GUI es una gran cantidad de paquetes. La decisión fue habilitar tantos enlaces de idiomas como fuera razonable y dejar que la elección estuviera entre los kits de herramientas de la GUI (o no). Un usuario no debería tener que elegir los complementos de Vim en función del idioma en el que está escrito.

— jamessan

Ese no es un argumento real, ya que solo Python y Python3 entran en conflicto entre sí. Sinceramente, creo que deberías tomar prestada una hoja del libro de desarrolladores de Arch. Aparte de un común vim-runtimepaquete, que tienen vim, gvim, vim-python3y gvim-python3. La única diferencia entre el -python3y los paquetes normales es la versión de Python habilitada. Claro, duplica la cantidad de paquetes frontend, pero esa es toda la falla que veo en ese empaque.

— muru

Eso es para Arch. En Debian, hay vim-nox, vim-gtk, vim-gnome, y vim-athena. Duplicarlos solo para que los usuarios aún no puedan usar los complementos Python y Python3 no parece valer la pena.

— jamessan

Tengo curiosidad por saber por qué no elegiste la opción dinámica para los paquetes normales.

— muru

Ubuntu 16.04 ahora tiene vim-*-py2paquetes incluidos en el repositorio. Esto significa que todos los usuarios de Debian Vim pueden migrar a Ubuntu si es necesario.

Los vim-*paquetes anteriores ahora proporcionan +python3, y los binarios se nombran de manera diferente para evitar conflictos:

vim.noxpara vim-noxy+python3
vim.nox-py2para vim-nox-py2y+python

Y así.

— dfggdfgdfgdfgdfgdfgdfgdfg
fuente

Entonces, el 16.04, ¿puedo cargar python2 y python3 en la misma sesión de Vim?

— Muru

@muru no, puedes elegir cuál obtienes en una sesión determinada más fácilmente;)

— hobbs

@hobbs Estoy bastante seguro de que los paquetes entran en conflicto con los de python3.

— muru

@muru no lo hacen, de hecho. Puede instalar y ejecutar el que elija, así como elegir uno para que sea su vim predeterminado. No es genial, pero es una mejora.

— hobbs

Y ahora con 17.04, se ha eliminado el soporte de Python 2 y los paquetes Vim relevantes

— Muru