Psutil: [linux] publica muchas versiones de linux en pypi

Creado en 10 jul. 2019  ·  9Comentarios  ·  Fuente: giampaolo/psutil

Actualmente psutil solo se puede instalar en linux compilándolo, lo cual es bastante inconveniente para muchos casos de uso, ya que aumenta mucho la instalación para imprimir (python-devel, gcc, ...).

psutil debería publicar muchos binarios de Linux en pypi, ya que esto eliminaría la necesidad de compilarlos en Linux. Este enfoque ya es popular entre otros paquetes.

bug linux

Comentario más útil

Así que una pequeña actualización sobre esto. Tengo un parche de trabajo en el que convertí el código prlimit() C a ctypes que nos dará soporte para python 2.x:
https://github.com/giampaolo/psutil/compare/prlimit
Aparte de eso, tendré que:
1) actualiza la documentación
2) configure un flujo de trabajo automatizado (a través de makefile / scripts) para "firmar" las ruedas antes de cargarlas en PyPI para que los hashes MD5 se mantengan bajo control de revisión de alguna manera.

Haré esto para el próximo lanzamiento.

Todos 9 comentarios

@giampaolo ¿ Alguna posibilidad de que esto suceda?

@giampaolo ¿ no planeas tener binarios manylinux? si psutil proporciona varios binarios de Linux, sería muy conveniente para los usuarios de Linux.

Ha habido avances en ese frente, @Czaki y https://github.com/giampaolo/psutil/pull/1758 , https://github.com/giampaolo/psutil/pull/1762 y otros RP intermedios (# 1761, # 1764, # 1767) pero desafortunadamente todavía hay 2 bloqueadores:

  • en Linux Process.rlimit() API no está disponible porque la rueda está compilada en CentOS 6 (que es antigua), por lo que la rueda resultante no tiene esa funcionalidad (pero el tarball sí)
  • en Windows de 32 bits obtenemos segfaults / crashes ocasionales y difíciles de depurar debido a la versión VS utilizada por github, que es más reciente que la de AppVeyor, donde el problema no ocurre. Así que tendré que instalar esa versión más nueva de VS localmente e intentar depurar el segfault en Windows.

Ambas cosas requieren un tiempo que actualmente no tengo, lamentablemente. En realidad, estaba pensando en hacer algún tipo de kickstarter / financiación, porque el desarrollo de psutil se está volviendo demasiado exigente para mí.

Desde mi punto de vista, la gran ventaja es que se pueden producir ruedas macos. También existe la posibilidad de construir la rueda manylinux2014 (Centos 7) para Linux. Entonces, parte de la persona podría instalarlo desde la rueda (los que tienen un sistema / pip más antiguo aún se instalarán desde alquitrán sin problemas). Pero estoy de acuerdo en que estos dos problemas deben resolverse

También existe la posibilidad de construir la rueda Manylinux2014 (Centos 7) para Linux.

Pero eso no es compatible con Python 2.7 si no me equivoco, ¿verdad?

También existe la posibilidad de construir la rueda Manylinux2014 (Centos 7) para Linux.

Pero eso no es compatible con Python 2.7 si no me equivoco, ¿verdad?

Si. Pero si no hay una rueda para python, 2.7 pip instalará psutil desde la fuente, como se hace ahora.

¿Alguna actualización sobre esto?

@giampaolo Sigo pensando que la rueda manylinux2014 es una buena solución.

Así que una pequeña actualización sobre esto. Tengo un parche de trabajo en el que convertí el código prlimit() C a ctypes que nos dará soporte para python 2.x:
https://github.com/giampaolo/psutil/compare/prlimit
Aparte de eso, tendré que:
1) actualiza la documentación
2) configure un flujo de trabajo automatizado (a través de makefile / scripts) para "firmar" las ruedas antes de cargarlas en PyPI para que los hashes MD5 se mantengan bajo control de revisión de alguna manera.

Haré esto para el próximo lanzamiento.

¿Fue útil esta página
0 / 5 - 0 calificaciones