python - ejemplos - django

Preguntas sobre herramientas de configuración y alternativas

Question

He visto un buen montón de herramientas de configuración atacando últimamente en los internets. Más recientemente, leí en la publicación sobre envases de James Bennett por qué nadie debería estar usando las herramientas de configuración. Desde mi tiempo en #python en Freenode, sé que hay algunas almas que lo detestan. Me contaría entre ellos, pero en realidad lo uso.

He utilizado herramientas de configuración para proyectos suficientes para estar al tanto de sus deficiencias, y preferiría algo mejor. No me gusta especialmente el formato de huevo y cómo se implementa. Con todos los problemas de las herramientas de configuración, no he encontrado una mejor alternativa.

Mi comprensión de herramientas como pip es que pretende ser un reemplazo de easy_install (no setuptools). De hecho, pip usa algunos componentes de herramientas de configuración, ¿verdad?

La mayoría de mis paquetes hacen uso de setuptools-aware setup.py, que declara todas las dependencias. Cuando estén listos, construiré un sdist, bdist y bdist_egg y los subiré a pypi.

Si quisiera cambiar a usar pip, ¿qué tipo de cambios necesitaría hacer para deshacerme de las dependencias easy_install? ¿Dónde están declaradas las dependencias? Supongo que tendré que alejarme de usar el formato de huevo y proporcionar solo distribuciones de origen. Si es así, ¿cómo puedo generar los directorios egg-info? ¿o incluso necesito hacerlo?

¿Cómo cambiaría esto mi uso de Virtualenv? ¿Virtualenv no usa easy_install para administrar los entornos?

¿Cómo cambiaría esto mi uso de las herramientas de configuración con el comando "desarrollar"? ¿No debería usar eso? ¿Cuál es la alternativa?

Básicamente estoy tratando de obtener una idea de cómo se verá mi flujo de trabajo de desarrollo.

Antes de que nadie lo sugiera, no estoy buscando una solución dependiente del sistema operativo. Estoy principalmente preocupado con Debian Linux, pero los paquetes Deb no son una opción, por las razones que describe Ian Bicking aquí .

Answer 1

Para empezar, pip es realmente nuevo. Nuevo, incompleto y sin pruebas en el mundo real.

Muestra una gran promesa, pero hasta el momento en que pueda hacer todo lo que easy_install / setuptools puede hacer, no es probable que se desarrolle a lo grande, ciertamente no en la corporación.

Easy_install / setuptools es grande y compleja, y eso ofende a mucha gente. Desafortunadamente, hay una buena razón para esa complejidad, que es que atiende una gran cantidad de casos de uso diferentes. El mío es compatible con un gran grupo de usuarios de escritorio (> 300), más una cuadrícula de tamaño similar con una aplicación que se actualiza con frecuencia. La idea de que pudiéramos hacer esto al permitir que cada usuario instale desde la fuente es ridícula: los huevos han demostrado ser una manera confiable de distribuir mi proyecto.

Mi consejo: aprenda a usar herramientas de configuración, es realmente algo maravilloso. La mayoría de las personas que lo odian no lo entienden, o simplemente no tienen el caso de uso como sistema de distribución completo.

:-)

Answer 2

pip usa Setuptools, y no requiere ningún cambio en los paquetes. En realidad, instala paquetes con Setuptools, usando:

python -c ''import setuptools; __file__="setup.py"; execfile(__file__)'' /
    install /
    --single-version-externally-managed

Debido a que usa esa opción ( --single-version-externally-managed ) nunca instala huevos como archivos zip, no admite múltiples versiones de software instaladas simultáneamente, y los paquetes se instalan planos (como python setup.py install funciona si solo usas distutils). Los metadatos de huevo todavía están instalados. pip también, como easy_install, descarga e instala todos los requisitos de un paquete.

Además , también puede usar un archivo de requisitos para agregar otros paquetes que deben instalarse en un lote y para hacer los requisitos de la versión más exactos (sin poner esos requisitos exactos en sus archivos setup.py ). Pero si no hace los archivos de requisitos, entonces los usaría como easy_install.

Para sus install_requires , no recomiendo ningún cambio, a menos que haya intentado crear allí requisitos muy precisos que se sabe que son buenos. Creo que hay un límite respecto de cuán exacto puede ser útil en los archivos setup.py sobre versiones, porque no se puede saber realmente cómo será la compatibilidad futura de las nuevas bibliotecas, y no recomiendo que intente predecir esto. Los archivos de requisitos son un lugar alternativo para diseñar los requisitos conservadores de la versión.

Todavía puedes usar python setup.py develop , y de hecho si haces pip install -e svn+http://mysite/svn/Project/trunk#egg=Project lo comprobará (en src/project ) y lo ejecutará setup.py develop en él. Entonces ese flujo de trabajo no es realmente diferente.

Si ejecuta pip en detalle (como pip install -vv ) verá muchos de los comandos que se ejecutan, y probablemente reconocerá la mayoría de ellos.

Answer 3

Escribo esto en abril de 2014. Tenga en cuenta la fecha de todo lo escrito sobre el empaquetado, la distribución o la instalación de Python. Parece que ha habido una cierta disminución de la facción, la mejora en las implementaciones, la estandarización de PEP y la unificación de frentes en los últimos, por ejemplo, tres años.

Por ejemplo, Python Packaging Authority es "un grupo de trabajo que mantiene muchos de los proyectos relevantes en el empaque de Python".

python.org Python Packaging User Guide contiene las Recomendaciones de herramientas y las secciones de El futuro de Python Packaging .

distribute fue una rama de las setuptools de setuptools que se reinició en junio de 2013. La guía dice: "Use setuptools de setuptools para definir proyectos y crear distribuciones de fuente".

A partir de PEP 453 y Python 3.4, la guía recomienda: "Use pip para instalar paquetes de Python desde PyPI", y pip se incluye con Python 3.4 y se instala en virtualenvs mediante pyvenv , que también está incluido. Puede encontrar interesante la sección "justificación" PEP 453 .

También hay herramientas nuevas y novedosas que se mencionan en la guía, como wheel y buildout .

Me alegro de haber leído las siguientes historias técnicas / semipolíticas.

Por Martijn Faassen en 2009: Una historia de empaquetado de Python .

Y por Armin Ronacher en junio de 2013 (el título no es serio): Empaquetado Python: Odio, odio, odio en todas partes .