modules python pip python-wheel

python - modules - upgrade pip windows



¿Cómo agregas archivos adicionales a una rueda? (5)

"Una rueda es un archivo en formato ZIP ..." ( http://wheel.readthedocs.org/en/latest )

Por lo tanto, trate el archivo .whl como un archivo .zip. Agrega un archivo con:

  • Objeto ZipFile Python
  • cualquier utilidad de archivo / archivo zip, como 7-zip, Winzip, Ark, file-roller, etc.

¿Cómo controlan qué archivos están incluidos en una rueda? Parece que MANIFEST.in no es utilizado por python setup.py bdist_wheel .

ACTUALIZAR :

Estaba equivocado sobre la diferencia entre instalar desde un tarball de fuente a una rueda. La distribución de origen incluye archivos especificados en MANIFEST.in , pero el paquete instalado solo tiene archivos de Python. Se necesitan pasos para identificar archivos adicionales que deben instalarse, ya sea que la instalación se realice a través de la distribución de origen, el huevo o la rueda. A saber, package_data es necesario para archivos de paquete adicionales y data_files para archivos fuera de su paquete como scripts de línea de comandos o archivos de configuración del sistema.

Pregunta original

Tengo un proyecto en el que he estado usando python setup.py sdist para compilar mi paquete, MANIFEST.in para controlar los archivos incluidos y excluidos, y pyroma y check-manifest para confirmar mi configuración.

Hace poco lo convertí al código dual Python 2/3, y agregué un setup.cfg con

[bdist_wheel] universal = 1

Puedo construir una rueda con python setup.py bdist_wheel , y parece ser una rueda universal según lo deseado. Sin embargo, no incluye todos los archivos especificados en MANIFEST.in .

¿Qué se instala?

Cavé más profundo y ahora sé más sobre empaque y rueda. Esto es lo que aprendí:

Subo dos archivos de paquete al proyecto multigtfs en PyPi :

  • multigtfs-0.4.2.tar.gz : bola de alquitrán de origen, que incluye todos los archivos en MANIFEST.in .
  • multigtfs-0.4.2-py2.py3-none-any.whl - La distribución binaria en cuestión.

pip install multigtfs-0.4.2.tar.gz dos nuevos entornos virtuales, ambos con Python 2.7.5, e instalé cada paquete ( pip install multigtfs-0.4.2.tar.gz ). Los dos ambientes son casi idénticos. Tienen diferentes archivos .pyc , que son los archivos "compilados" de Python. Hay archivos de registro que registran las diferentes rutas en el disco. La instalación de la bola de alquitrán de origen incluye una carpeta multigtfs-0.4.2-py27.egg-info , que detalla la instalación, y la instalación de la rueda tiene una multigtfs-0.4.2.dist-info , con los detalles de ese proceso. Sin embargo, desde el punto de vista del código que usa el proyecto multigtfs, no hay diferencia entre los dos métodos de instalación.

Explícitamente, ninguno de los archivos .zip utilizados por mi prueba, por lo que el paquete de prueba fallará:

$ django-admin startproject demo $ cd demo $ pip install psycopg2 # DB driver for PostGIS project $ createdb demo # Create PostgreSQL database $ psql -d demo -c "CREATE EXTENSION postgis" # Make it a PostGIS database $ vi demo/settings.py # Add multigtfs to INSTALLED_APPS, # Update DATABASE to set ENGINE to django.contrib.gis.db.backends.postgis # Update DATABASE to set NAME to test $ ./manage.py test multigtfs.tests # Run the tests ... IOError: [Errno 2] No such file or directory: u''/Users/john/.virtualenvs/test/lib/python2.7/site-packages/multigtfs/tests/fixtures/test3.zip''

Especificando archivos adicionales

Usando las sugerencias de las respuestas, agregué algunas directivas adicionales a setup.py :

from __future__ import unicode_literals # setup.py now requires some funky binary strings ... setup( name=''multigtfs'', packages=find_packages(), package_data={b''multigtfs'': [''test/fixtures/*.zip'']}, include_package_data=True, ... )

Esto instala los archivos zip (así como el archivo README) en la carpeta, y las pruebas ahora se ejecutan correctamente. Gracias por las sugerencias!


¿Has intentado usar package_data en tu setup.py ? MANIFEST.in parece destinado a las versiones de Python <= 2.6, no estoy seguro si las versiones más altas lo miran.

Después de explorar https://github.com/pypa/sampleproject , su MANIFEST.in dice:

# If using Python 2.6 or less, then have to include package data, even though # it''s already declared in setup.py include sample/*.dat

lo que parece implicar que este método está desactualizado. Mientras tanto, en setup.py declaran:

setup( name=''sample'', ... # If there are data files included in your packages that need to be # installed, specify them here. If using Python 2.6 or less, then these # have to be included in MANIFEST.in as well. package_data={ ''sample'': [''package_data.dat''], }, ... )

(No estoy seguro de por qué eligieron un comodín en MANIFEST.in y un nombre de archivo en setup.py . Se refieren al mismo archivo)

Lo cual, junto con ser más simple, de nuevo parece implicar que la ruta package_data es superior al método MANIFEST.in . Bueno, a menos que tengas que apoyar 2.6 eso es, en cuyo caso mis oraciones se dirigen a ti.


Puede especificar archivos adicionales para instalar utilizando la directiva data_files . ¿Es eso lo que estás buscando? Aquí hay un pequeño ejemplo:

from setuptools import setup from glob import glob setup( name=''extra'', version=''0.0.1'', py_modules=[''extra''], data_files=[ (''images'', glob(''assets/*.png'')), ], )


Puede usar data_files y data_files en setup.py para especificar archivos adicionales, pero son ridículamente difíciles de corregir (y errores) .

Una alternativa es usar MANIFEST.in y agregar include_package_data=True en setup() de su setup.py como se indica aquí .

Con esta directiva, MANIFEST.in se usará para especificar los archivos que se incluirán no solo en la fuente tarball / zip, sino también en el instalador wheel y win32. Esto también funciona con cualquier versión de Python (probé en un proyecto de py2.6 a py3.6).


Antes de realizar cambios en MANIFEST.in o setup.py , debe eliminar los directorios de salida anteriores. Setuptools está almacenando en caché algunos de los datos y esto puede conducir a resultados inesperados.

rm -rf build *.egg-info

Si no lo hace, no espere que nada funcione correctamente.

Ahora eso está fuera del camino.

  1. Si está creando una distribución fuente ( sdist ), puede usar cualquier método a continuación.

  2. Si está construyendo una rueda ( bdist_wheel ), entonces include_package_data y MANIFEST.in se ignoran y debe usar data_files y data_files .

INCLUDE_PACKAGE_DATA

Esta es una buena opción, pero bdist_wheel no la bdist_wheel .

setup( ... include_package_data=True ) # MANIFEST.in include package/data.json

DATA_FILES para datos no incluidos en el paquete

Esta es la opción más flexible porque puede agregar cualquier archivo de su repositorio a un sdist o bdist_wheel

setup( .... data_files=[ (''output_dir'':[''conf/data.json'']), ] # For sdist, output_dir is ignored! # # For bdist_wheel, data.json from conf dir in root of your repo # and stored at `output_dir/` inside of the sdist package. )

PACKAGE_DATA para archivos que no sean python dentro del paquete

Al igual que en el bdist_wheel anterior, pero para un bdist_wheel permite poner sus archivos de datos dentro del paquete. Es idéntico para sdist pero tiene más limitaciones que data_files porque los archivos solo pueden fuente de su paquete subdir.

setup( ... package_data={''package'':''data.json''}, # data.json must be inside of your actual package )