Tenemos más de 100 paquetes privados y hasta ahora hemos estado usando s3pypi para configurar un pypi privado en un depósito s3. Nuestros paquetes privados tienen dependencias entre sí (y en los paquetes públicos), y es (por supuesto) importante que nuestras canalizaciones de GitLab encuentren la última versión funcional de los paquetes en los que se basa. Es decir, no estamos interesados en el último código registrado. Creamos nuevas ruedas solo después de las pruebas y qa se ha ejecutado contra un empuje para dominar (que es una forma larga de explicar que los requisitos -e <vcs> no funcionarán).
Nuestra configuración funciona muy bien hasta que alguien crea un nuevo paquete público en el pypi oficial que oculta uno de los nombres de nuestros paquetes. Podemos forzar la elección de nuestro paquete privado aumentando el número de versión para que sea más alto que el nuevo paquete en pypi.org, o cambiando el nombre de nuestro paquete a algo que aún no se haya tomado en pypi.org.
Obviamente, esta es una solución pirateada y frágil, pero aparentemente la funcionalidad es así por diseño .
Después de la configuración inicial del depósito, s3pypi no ha requerido mantenimiento ni administración. El ticket anterior sugiere usar devpi, pero parece una solución muy complicada que requiere administración/supervisión/etc.
La solución pypi de GitLab parece estar a nivel de paquete individual (lo que significa que tendríamos que enumerar hasta más de 100 direcciones URL, una para cada paquete). Esto no parece práctico, pero tal vez no estoy entendiendo algo (también puedo ver el menú de registro del paquete en nuestro grupo, pero los documentos apuntan a los documentos "paquete-pypi").
¿No podemos ser la primera pequeña empresa que se ha enfrentado a este problema? ¿Existe una mejor manera que registrar versiones ficticias de todos nuestros paquetes en pypi.org (con version=0.0.1, por lo que se preferirá la versión s3pypi)?
Puede que no sea la solución para ti, pero te cuento lo que hacemos.
company.product.tool ).requirements.txt que incluye nuestra URL de PyPI. Ejecutamos todo en contenedores e instalamos todas las dependencias públicas en ellos cuando construimos las imágenes.Su empresa podría redirigir todas las solicitudes a pypi a un servicio que controle primero (quizás solo en los archivos de hosts de sus servidores de compilación)
Esto potencialmente le permitiría
Usamos VCS para esto. Veo que lo ha descartado explícitamente, pero ¿ha considerado usar sucursales para marcar sus últimas compilaciones estables en VCS?
Si no está interesado en la última versión de master o la rama de desarrollo, pero está ejecutando prueba/control de calidad contra confirmaciones, entonces configuraría su suite de prueba/control de calidad para fusionarse en una rama llamada algo así como "estable" o "pypi -stable" y luego sus archivos de requisitos se ven así:
pip install git+https://gitlab.com/yourorg/yourpackage.git@pypi-stableLa misma configuración funcionará para los bloques de requisitos setup.py (que permite dependencias internas encadenadas).
¿Me estoy perdiendo de algo?
Quizás podría obtener el comportamiento que está buscando de un requirements.txt y dos llamadas pip :
cat requirements.txt | xargs -n 1 pip install -i <your-s3pipy> pip install -r requirements.txtEl primero intenta instalar lo que puede desde su repositorio local e ignora un paquete si falla. La segunda llamada intenta instalar todo lo que falló antes de pipy.
Esto funciona porque --upgrade-strategy only-if-needed es el valor predeterminado (a partir de pip 10.X, creo, no me cites al respecto). Si está utilizando un pip antiguo, es posible que deba especificarlo manualmente.
Una limitación de este enfoque es si espera/solicita un paquete local, pero no existe y existe un paquete con el mismo nombre en pipy. En este caso, obtendrá ese paquete en su lugar. No estoy seguro si eso es una preocupación.