Instalación de Módulos de Python (versión antigua)¶
- Autor
Greg Ward
Nota
Todo el paquete distutils
ha quedado obsoleto y se eliminará en Python 3.12. Esta documentación se conserva solo como referencia y se eliminará con el paquete. Consulte la entrada Qué hay de nuevo para obtener más información.
Ver también
- Instalando módulos de Python
La documentación actualizada de instalación de módulos. Para el uso regular de Python, es casi seguro que desee ese documento en lugar de este.
Nota
Este documento se conserva únicamente hasta que la documentación de setuptools
en https://setuptools.readthedocs.io/en/latest/setuptools.html cubra de forma independiente toda la información relevante que se incluye actualmente aquí.
Nota
Esta guía solamente cubre las herramientas básicas para construir y distribuir extensiones que se proporcionan como parte de esta versión de Python. Herramientas de terceros ofrecen alternativas más sencillas y seguras . Consulte la sección de recomendaciones en la Guía de Usuario de Empaquetamiento de Python para mayor detalle.
Introducción¶
En Python 2.0, la API distutils
fue el primer módulo en ser agregado a la biblioteca estándar. Esto proporcionó a los mantenedores de distribución de Linux una forma estándar de convertir proyectos de Python en paquetes de distribución de Linux, y a los administradores de sistemas con una forma estándar de instalarlos directamente en los sistemas de destino.
En los muchos años transcurridos desde el lanzamiento de Python 2.0, el acoplamiento estrecho del sistema de compilación y el instalador del paquete al ciclo de lanzamiento del lenguaje ha sido un problema, ahora se recomienda que los proyectos utilicen el instalador del paquete pip
y el sistema de compilación setuptools
, en lugar de utilizar directamente distutils
.
Ver Instalando módulos de Python y Distribuir módulos de Python para mayor detalles.
Esta documentación heredada se conservará hasta que se esté seguro que la documentación de setuptools
cubre todo lo necesario.
Distutils basado la distribuciones de la fuente¶
If you download a module source distribution, you can tell pretty quickly if it
was packaged and distributed in the standard way, i.e. using the Distutils.
First, the distribution’s name and version number will be featured prominently
in the name of the downloaded archive, e.g. foo-1.0.tar.gz
or
widget-0.9.7.zip
. Next, the archive will unpack into a similarly named
directory: foo-1.0
or widget-0.9.7
. Additionally, the
distribution will contain a setup script setup.py
, and a file named
README.txt
or possibly just README
, which should explain that
building and installing the module distribution is a simple matter of running
one command from a terminal:
python setup.py install
Para Windows, este comando debería ejecutarse desde la linea de comandos.(
):setup.py install
Si todo es correcto, entonces ya sabe cómo construir e instalar los módulos que acaba de descargar: ejecute el comando anterior. Al menos que se necesite instalar cosas de una manera no estándar o personalizar el proceso de compilación, no necesitará hacer esto de manera manual. Más bien, el comando anterior es todo lo que necesita obtener de este manual.
Construcción e instalación estándar¶
Como se describe en la sección Distutils basado la distribuciones de la fuente, construir e instalar una distribución de módulos usando Distutils suele ser un comando simple para ejecutar desde un terminal:
python setup.py install
Variaciones de acuerdo a la plataforma¶
Siempre debe ejecutar el comando de configuración desde el directorio raíz de distribución, por ejemplo el subdirectorio de nivel superior en el que se descomprime la distribución fuente del módulo. Por ejemplo, si acaba de descargar una distribución fuente del módulo foo-1.0.tar.gz
en un sistema Unix, lo normal es:
gunzip -c foo-1.0.tar.gz | tar xf - # unpacks into directory foo-1.0
cd foo-1.0
python setup.py install
En Windows, probablemente se descargaría foo-1.0.zip
. Si descargó el archivo en C:Temp
, se descomprimirá en C:Tempfoo-1.0
; puede usar un manipulador de archivo con una interfaz gráfica de usuario (como WinZip) o una herramienta de línea de comandos (como unzip o pkunzip) para descomprimir el archivo. Luego, abra una ventana de símbolo del sistema y ejecute:
cd c:\Temp\foo-1.0
python setup.py install
Dividiendo el trabajo¶
La ejecución de setup.py install
compila e instala todos los módulos en una sola ejecución. Si prefiere trabajar de forma incremental, especialmente útil si desea personalizar el proceso de compilación, o si las cosas van mal, puede usar el script de configuración para hacer una cosa a la vez. Esto es particularmente útil cuando la compilación y la instalación serán realizadas por diferentes usuarios, por ejemplo, es posible que desee compilar una distribución de módulos y entregarla a un administrador del sistema para su instalación (o hágalo usted mismo, con privilegios de superusuario )
Por ejemplo, puede compilar todo en un solo paso y luego instalarlo en un segundo paso, invocando el script de configuración dos veces:
python setup.py build
python setup.py install
Si hace esto, notará que al ejecutar el comando install primero ejecuta el comando build, que — en este caso — rápidamente se da cuenta de que no tiene nada que hacer, ya que todo en la carpeta build
está actualizado.
Es posible que no necesite esta capacidad de desglosar las cosas si todo lo que hace es instalar módulos descargados de la red, pero es muy útil para tareas más avanzadas. Si llega a distribuir sus propios módulos y extensiones de Python, ejecutará muchos comandos Distutils individuales por su cuenta.
Como funciona la construcción¶
Como se indicó anteriormente, el comando build es responsable de colocar los archivos para instalar en un directorio de compilación. Por defecto, esto es build
bajo la raíz de distribución; si está demasiado preocupado por la velocidad, o si desea mantener el árbol de origen prístino, puede cambiar el directorio de compilación con la opción --build-base
. Por ejemplo:
python setup.py build --build-base=/path/to/pybuild/foo-1.0
(O puede hacer esto permanentemente con una directiva en su sistema o archivo de configuración personal de Distutils; ver la sección Archivos de Configuración de Distutils.) Normalmente, esto no es necesario.
El diseño predeterminado para el árbol de compilación es el siguiente:
--- build/ --- lib/
or
--- build/ --- lib.<plat>/
temp.<plat>/
donde <plat>
se expande a una breve descripción de la plataforma actual de SO/hardware y la versión de Python. La primera forma, con solo un directorio lib
, se usa para «distribuciones de módulos puros»— es decir, distribuciones de módulos que incluyen solo módulos puros de Python. Si la distribución de un módulo contiene alguna extensión (módulos escritos en C/C ++), se utiliza la segunda forma, con dos directorios <plat>
. En ese caso, el directorio temp.plat
contiene archivos temporales generados por el proceso de compilación/enlace que en realidad no se instalan. En cualquier caso, el directorio lib
(o lib.plat
) contiene todos los módulos de Python (Python puro y extensiones) que se instalarán.
En el futuro, se agregarán más directorios para manejar scripts de Python, documentación, ejecutables binarios y todo lo que sea necesario para manejar el trabajo de instalación de módulos y aplicaciones de Python.
Como funciona la instalación¶
Después de que se ejecute el comando build (ya sea que lo ejecute explícitamente, o el comando install lo hace por usted), el trabajo del comando install es relativamente simple: todo lo que tiene hacer es copiar todo lo que se encuentra en el directorio build/lib
(o build/lib.plat
) en el directorio de instalación elegido.
Si no se elige un directorio de instalación —es decir, si solo ejecuta setup.py install
-– entonces el comando install se instala en la ubicación estándar para módulos Python de terceros . Esta ubicación varía según la plataforma y la forma en la que se compiló/instaló Python. En Unix (y macOS, que también está basado en Unix), depende de si la distribución del módulo que se está instalando es Python puro o contiene extensiones («no puro»):
Plataforma |
Lugar de instalación estándar |
Valor por defecto |
Notas |
---|---|---|---|
Unix (puro) |
|
|
(1) |
Unix (no puro) |
|
|
(1) |
Windows |
|
|
(2) |
Notas:
La mayoría de las distribuciones de Linux incluyen Python como una parte estándar del sistema, por lo que
prefix
yexec-prefix
generalmente son ambos: file: /usr en Linux. Si construye Python usted mismo en Linux (o en cualquier sistema similar a Unix), el valor predeterminadoprefix
yexec-prefix
son/usr /local
.El directorio de instalación predeterminado en Windows era
C:\ Archivos de programa \Python
en Python 1.6a1, 1.5.2 y versiones anteriores.
prefix
y exec-prefix
representan los directorios en los que está instalado Python y donde encuentra sus bibliotecas en tiempo de ejecución. Siempre son los mismos en Windows, y muy a menudo los mismos en Unix y macOS. Puede averiguar qué utiliza el Python que tiene instalado para prefix
y exec-prefix
ejecutando Python en modo interactivo y escribiendo algunos comandos simples. En Unix, simplemente escriba python
en el indicador de comandos de la shell. En Windows, elija . Una vez que se inicia el intérprete, escriba el código Python en el indicador. Por ejemplo, si en mi sistema Linux, escribo las tres declaraciones de Python que se muestran a continuación, y con ello obtengo el resultado como se muestra a continuación, averiguo mi prefix
y exec-prefix
:
Python 2.4 (#26, Aug 7 2004, 17:19:02)
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.prefix
'/usr'
>>> sys.exec_prefix
'/usr'
En este documento se utilizan algunos otros marcadores de posición: X.Y
representa la versión de Python, por ejemplo, 3.2
; abiflags
será reemplazado por el valor de sys.abiflags
o la cadena vacía para plataformas que no definen flags ABI; distname
será reemplazado por el nombre de la distribución del módulo que se está instalando. Los puntos y las mayúsculas son importantes en los las direcciones; por ejemplo, un valor que usa python3.2
en UNIX generalmente usará Python32
en Windows.
Si no desea instalar módulos en la ubicación estándar, o si no tiene permiso para escribir allí, debe leer acerca de las instalaciones alternativas en la sección Instalación alternativa. Si desea personalizar más sus directorios de instalación, consulte la sección Instalación personalizada en instalaciones personalizadas.
Instalación alternativa¶
A menudo, es necesario o deseable instalar módulos en una ubicación distinta de la ubicación estándar para módulos Python de terceros. Por ejemplo, en un sistema Unix, es posible que no tenga permiso para escribir en el directorio estándar de módulos de terceros. O quizás desee probar un módulo antes de convertirlo en una parte estándar de su instalación local de Python. Esto es especialmente cierto cuando se actualiza una distribución ya presente: desea asegurarse de que su base de scripts existente todavía funcione con la nueva versión antes de actualizar realmente.
El comando Distutils install está diseñado para hacer que la instalación de distribuciones de módulos en una ubicación alternativa sea simple e indolora. La idea básica es que proporcione un directorio base para la instalación, y el comando install selecciona un conjunto de directorios (llamado esquema de instalación) en este directorio base en el que instalar los archivos. Los detalles difieren entre plataformas, por lo tanto, lea la sección que corresponda a usted.
Tenga en cuenta que los diversos esquemas de instalación alternativos son mutuamente excluyentes: se le puede pasar --user
, o --home
, o --prefix
y --exec-prefix
, o --install-base
y --install-platbase
, pero no puede mezclar desde estos grupos.
Instalación alternativa: el esquema de usuario¶
This scheme is designed to be the most convenient solution for users that don’t have write permission to the global site-packages directory or don’t want to install into it. It is enabled with a simple option:
python setup.py install --user
Los archivos se instalarán en subdirectorios de site.USER_BASE
(escrito como userbase
en adelante). Este esquema instala módulos Python puros y módulos de extensión en la misma ubicación (también conocida como site.USER_SITE
). Estos son los valores para UNIX, incluido macOS:
Tipo de archivo |
Directorio de instalación |
---|---|
módulos |
|
scripts |
|
dato |
|
Cabeceras C |
|
Y aquí están los valores usados en Windows:
Tipo de archivo |
Directorio de instalación |
---|---|
módulos |
|
scripts |
|
dato |
|
Cabeceras C |
|
La ventaja de usar este esquema en comparación con los otros descritos a continuación es que el directorio de paquetes de sitio del usuario está en condiciones normales siempre incluido en sys.path
(ver site
para más información), que significa que no hay que realizar ningún paso adicional después de ejecutar el script setup.py
para finalizar la instalación.
El comando build_ext también tiene una opción --user
para agregar userbase/include
a la ruta de búsqueda del compilador para archivos de encabezado y userbase/lib
a la ruta de búsqueda del compilador para bibliotecas, así como a la ruta de búsqueda de tiempo de ejecución para bibliotecas C compartidas (rpath).
Instalación alternativa: el esquema de la casa¶
La idea detrás del «esquema de inicio» es crear y mantener una reserva personal de módulos Python. El nombre de este esquema se deriva de la idea de un directorio «de inicio» en Unix, ya que no es inusual que un usuario de Unix haga que su directorio de inicio tenga un diseño similar a /usr/
o /usr/local/
. Cualquiera puede utilizar este esquema, independientemente del sistema operativo para el que se esté instalando.
Instalar un nuevo módulo de distribución es tan simple como:
python setup.py install --home=<dir>
dónde se puede suministrar cualquier directorio que desee para la opción -inicio
. En Unix, los mecanógrafos perezosos pueden simplemente escribir una tilde (~
); el comando install expandirá esto a su directorio de inicio:
python setup.py install --home=~
Para hacer que Python encuentre las distribuciones instaladas con este esquema, puede que tenga que modificar la ruta de búsqueda de Python o editar sitecustomize
(ver site
) para llamar site.addsitedir()
o edit sys.path
.
La opción -inicio
define el directorio base de instalación. Los archivos se instalan en los siguientes directorios bajo la base de instalación de la siguiente manera:
Tipo de archivo |
Directorio de instalación |
---|---|
módulos |
|
scripts |
|
dato |
|
Cabeceras C |
|
(Reemplace mentalmente las barras diagonales con barras diagonales inversas si está en Windows.)
Instalación alternativa: Unix (el esquema de prefijo)¶
El «esquema de prefijo» es útil cuando desea utilizar una instalación de Python para realizar la compilación / instalación (por ejemplo, para ejecutar el script de configuración), pero instalar módulos en el directorio de módulos de terceros de una instalación de Python diferente (o algo que parece una instalación diferente de Python). Si esto suena un poco inusual, es — es por eso que el usuario y los esquemas de inicio vienen antes. Sin embargo, hay al menos dos casos conocidos en los que el esquema de prefijo será útil.
Primero, considere que muchas distribuciones de Linux ponen Python en /usr
, en lugar del tradicional /usr/local
. Esto es completamente apropiado, ya que en esos casos Python es parte del «sistema» en lugar de un complemento local. Sin embargo, si está instalando módulos de Python desde la fuente, probablemente desee que entren en /usr/local/lib/python2.X
en lugar de /usr/lib/python2.X
. Esto se puede hacer con
/usr/bin/python setup.py install --prefix=/usr/local
Otra posibilidad es un sistema de archivos de red donde el nombre utilizado para escribir en un directorio remoto es diferente del nombre utilizado para leerlo: por ejemplo, el intérprete de Python al que se accede como /usr/local/bin/python
podría buscar módulos en /usr/local/lib/python2.X
, pero esos módulos tendrían que instalarse en, por ejemplo, /mnt/@servidor/export/lib/python2.X
. Esto podría hacerse con
/usr/local/bin/python setup.py install --prefix=/mnt/@server/export
En cualquier caso, la opción --prefix
define la base de instalación, y la opción --exec-prefix
define la base de instalación específica de la plataforma, que se utiliza para archivos específicos de la plataforma . (Actualmente, esto solo significa distribuciones de módulos no puras, pero podría expandirse a bibliotecas C, ejecutables binarios, etc.) Si:option:!–exec-prefix no se proporciona, el valor predeterminado es --prefix
. Los archivos se instalan de la siguiente manera:
Tipo de archivo |
Directorio de instalación |
---|---|
Modules de Python |
|
extensión de módulos |
|
scripts |
|
dato |
|
Cabeceras C |
|
No es necesario que --prefix
o --exec-prefix
realmente apunte a una instalación alternativa de Python; Si los directorios enumerados anteriormente no existen, se crean en el momento de la instalación.
Por cierto, la verdadera razón por la que el esquema de prefijos es importante es simplemente que una instalación estándar de Unix usa el esquema de prefijos, pero con --prefix
y --exec-prefix
suministrado por Python como sys.prefix
y sys.exec_prefix
. Por lo tanto, puede pensar que nunca usará el esquema de prefijo, pero cada vez que ejecuta python setup.py install
sin ninguna otra opción, lo está usando.
Tenga en cuenta que la instalación de extensiones en una instalación alternativa de Python no tiene efecto sobre cómo se construyen esas extensiones: en particular, los archivos de encabezado de Python (Python.h
y amigos) instalados con el intérprete de Python utilizado para ejecutar el script de configuración ser utilizado en la compilación de extensiones. Es su responsabilidad asegurarse de que el intérprete utilizado para ejecutar las extensiones instaladas de esta manera sea compatible con el intérprete utilizado para construirlas. La mejor manera de hacer esto es asegurarse de que los dos intérpretes sean la misma versión de Python (posiblemente compilaciones diferentes, o posiblemente copias de la misma compilación). (Por supuesto, si su --prefix
y -- exec-prefix
ni siquiera apuntan a una instalación alternativa de Python, esto es irrelevante).
Instalación alternativa: Windows (el esquema de prefijo)¶
Windows no tiene el concepto del directorio de inicio de un usuario, y dado que la instalación estándar de Python en Windows es más simple que en Unix, la opción --prefix
se ha usado tradicionalmente para instalar paquetes adicionales en ubicaciones separadas en Windows.
python setup.py install --prefix="\Temp\Python"
instalar los módulos en el directorio \Temp\Python
en el disco actual.
La base de instalación se define mediante la opción --prefix
; la opción --exec-prefix
no es compatible con Windows, lo que significa que los módulos Python puros y los módulos de extensión están instalados en la misma ubicación. Los archivos se instalan de la siguiente manera:
Tipo de archivo |
Directorio de instalación |
---|---|
módulos |
|
scripts |
|
dato |
|
Cabeceras C |
|
Instalación personalizada¶
A veces, los esquemas de instalación alternativos descritos en la sección Instalación alternativa simplemente no hacen lo que quieres. Es posible que desee ajustar solo uno o dos directorios mientras mantiene todo bajo el mismo directorio base, o puede que desee redefinir completamente el esquema de instalación. En cualquier caso, está creando un esquema de instalación personalizado.
Para crear un esquema de instalación personalizado, comience con uno de los esquemas alternativos y anule algunos de los directorios de instalación utilizados para los distintos tipos de archivos, utilizando estas opciones:
Tipo de archivo |
Sobreescribir opciones |
---|---|
Modules de Python |
|
extensión de módulos |
|
todos los módulos |
|
scripts |
|
dato |
|
Cabeceras C |
|
Estas opciones de invalidación pueden ser relativas, absolutas o definidas explícitamente en términos de uno de los directorios base de instalación. (Hay dos directorios base de instalación, y normalmente son los mismos— sólo difieren cuando se utiliza el «esquema de prefijo» de Unix y se proporcionan diferentes opciones de --prefijo
y --exec-prefix
; usando --install-lib
anulará los valores calculados o dados para install-purelib
y --install-platlib
, y se recomienda para esquemas que no hacen diferencia entre Python y extensión.
Por ejemplo, supongamos que se está instalando una distribución de módulos en su directorio de inicio en Unix—pero se desea que los scripts vayan en /scripts
en lugar de /bin
. Como es de esperar, puede invalidar este directorio con la opción --install-scripts
; en este caso, tiene más sentido proporcionar una ruta relativa, que se interpretará en relación con el directorio base de la instalación (su directorio principal, en este caso):
python setup.py install --home=~ --install-scripts=scripts
Otro ejemplo de Unix: supongamos que la instalación de Python se creó e instaló con un prefijo de /usr/local/python
, por lo que bajo una instalación estándar los scripts terminarán en /usr/local/python/bin
. Si los desea en /usr/local/bin
en su lugar, debe proporcionar este directorio absoluto para la opción --install-scripts
:
python setup.py install --install-scripts=/usr/local/bin
(Esto realiza una instalación utilizando el «esquema de prefijo», donde el prefijo es lo que su intérprete de Python se instaló con— /usr/local/python
en este caso.)
Si mantiene Python en Windows, es posible que desee que los módulos de terceros vivan en un subdirectorio de prefijo
, en lugar de hacerlo en prefijo
en sí. Esto es casi tan fácil como personalizar el directorio de instalación de script—sólo hay que recordar que hay dos tipos de módulos de los que preocuparse, Python y módulos de extensión, que pueden ser convenientemente controlados por una opción:
python setup.py install --install-lib=Site
El directorio de instalación especificado es relativo a -prefijo
. Por supuesto, también tiene que asegurarse de que este directorio está en la ruta de búsqueda del módulo de Python, por ejemplo, colocando un archivo .pth
en un directorio de sitio (consulte site
). Consulte la sección Modificando el Camino de Búsqueda de Python para averiguar cómo modificar la ruta de búsqueda de Python.
Si desea definir un esquema de instalación completo, sólo tiene que proporcionar todas las opciones del directorio de instalación. La forma recomendada de hacerlo es proporcionar rutas relativas; por ejemplo, si desea mantener todos los archivos relacionados con el módulo python en python
en su directorio principal y desea un directorio independiente para cada plataforma desde la que utilice el directorio principal, puede definir el siguiente esquema de instalación:
python setup.py install --home=~ \
--install-purelib=python/lib \
--install-platlib=python/lib.$PLAT \
--install-scripts=python/scripts
--install-data=python/data
o, equivalente,
python setup.py install --home=~/python \
--install-purelib=lib \
--install-platlib='lib.$PLAT' \
--install-scripts=scripts
--install-data=data
$PLAT
no es (necesariamente) una variable de entorno—se expandirá el Distutils a medida que analiza las opciones de línea de comandos, tal como lo hace al analizar los archivos de configuración.
Obviamente, especificar el esquema de instalación completo cada vez que instala un nuevo módulo de distribución sería muy tedioso. Por lo tanto, puede poner estas opciones en su archivo de configuración de Distutils (consulte la sección Archivos de Configuración de Distutils):
[install]
install-base=$HOME
install-purelib=python/lib
install-platlib=python/lib.$PLAT
install-scripts=python/scripts
install-data=python/data
o ,equivalente,
[install]
install-base=$HOME/python
install-purelib=lib
install-platlib=lib.$PLAT
install-scripts=scripts
install-data=data
Tenga en cuenta que estos dos son no equivalentes si proporciona un directorio base de instalación diferente cuando ejecuta el script de configuración. Por ejemplo,
python setup.py install --install-base=/tmp
instalaría módulos puros en /tmp/python/lib
en el primer caso, y en /tmp/lib
en el segundo caso. (Para el segundo caso, probablemente desee proporcionar una base de instalación de /tmp/python
.)
Probablemente haya notado el uso de $HOME
y $ PLAT
en la entrada del archivo de configuración de muestra. Estas son las variables de configuración de Distutils, que tienen un gran parecido con las variables de entorno. De hecho, puede usar variables de entorno en archivos de configuración en plataformas que tienen esa noción, pero los Distutils definen adicionalmente algunas variables adicionales que pueden no estar en su entorno, como $PLAT
. (Y, por supuesto, en los sistemas que no tienen variables de entorno, como Mac OS 9, las variables de configuración proporcionadas por Distutils son las únicas que puede usar). Consulte la sección Archivos de Configuración de Distutils para detalles.
Nota
Cuando a entorno virtual está activado, cualquier opción que cambie la ruta de instalación será ignorada de todos los archivos de configuración de distutils para evitar la instalación accidental de proyectos fuera del entorno virtual.
Modificando el Camino de Búsqueda de Python¶
Cuando el intérprete de Python ejecuta una declaración import
, busca tanto el código de Python como los módulos de extensión a lo largo de una ruta de búsqueda. Un valor predeterminado para la ruta se configura en el binario de Python cuando se construye el intérprete. Puede determinar la ruta importando el módulo sys
e imprimiendo el valor de sys.path
.
$ python
Python 2.2 (#11, Oct 3 2002, 13:31:27)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/local/lib/python2.3', '/usr/local/lib/python2.3/plat-linux2',
'/usr/local/lib/python2.3/lib-tk', '/usr/local/lib/python2.3/lib-dynload',
'/usr/local/lib/python2.3/site-packages']
>>>
La cadena nula en sys.path
representa el directorio de trabajo actual.
La convención esperada para los paquetes instalados localmente es ponerlos en el directorio …/site-packages/
, pero es posible que desee instalar módulos de Python en algún directorio arbitrario. Por ejemplo, su sitio puede tener una convención de mantener todo el software relacionado con el servidor web en /www
. Los módulos adicionales de Python pueden pertenecer a /www/python
, y para importarlos, este directorio debe agregarse a sys.path
. Hay varias formas diferentes de agregar el directorio.
La forma más conveniente es agregar un archivo de configuración de ruta a un directorio que ya está en la ruta de Python, generalmente al directorio .../site-packages/
. Los archivos de configuración de ruta tienen una extensión de .pth
, y cada línea debe contener una ruta única que se agregará a sys.path
. (Debido a que las nuevas rutas se agregan a sys.path
, los módulos en los directorios agregados no anularán los módulos estándar. Esto significa que no puede usar este mecanismo para instalar versiones fijas de módulos estándar).
Las rutas pueden ser absolutas o relativas, en cuyo caso son relativas al directorio que contiene el archivo .pth
. Consulte la documentación del módulo site
para obtener más información.
Una forma un poco menos conveniente es editar el archivo site.py
en la biblioteca estándar de Python y modificar sys.path
. site.py
se importa automáticamente cuando se ejecuta el intérprete de Python, a menos que se proporcione el -S
para suprimir este comportamiento. Entonces, simplemente puede editar site.py
y agregarle dos líneas:
import sys
sys.path.append('/www/python/')
Sin embargo, si reinstala la misma versión principal de Python (tal vez al actualizar de 2.2 a 2.2.2, por ejemplo) la versión de archivo sobrescribirá el site.py
. Debería recordar que se modificó y guardar una copia antes de realizar la instalación.
Hay dos variables de entorno que pueden modificar sys.path
. PYTHONHOME
establece un valor alternativo para el prefijo de la instalación de Python. Por ejemplo, si PYTHONHOME
está configurado en /www/python
, la ruta de búsqueda se establecerá en ['', '/www/python/lib/pythonX.Y/', '/www/python/lib/pythonX.Y/plat-linux2', ...]
.
La variable PYTHONPATH
se puede establecer en una lista de rutas que se agregarán al comienzo de sys.path
. Por ejemplo, si PYTHONPATH
está establecido en /www/python:/opt /py
, la ruta de búsqueda comenzará con ['/www/python', '/opt/py'] ``. (Tenga en cuenta que los directorios deben existir para poder agregarlos a ``sys.path
; el módulo site
elimina las rutas que no existen).
Finalmente,``sys.path`` es solo una lista normal de Python, por lo que cualquier aplicación de Python puede modificarla agregando o eliminando entradas.
Archivos de Configuración de Distutils¶
Como se mencionó anteriormente, puede usar los archivos de configuración de Distutils para registrar las preferencias personales o del sitio para cualquier opción de Distutils. Es decir, cualquier opción para cualquier comando puede almacenarse en uno de dos o tres (según su plataforma) archivos de configuración, que se consultarán antes de analizar la línea de comandos. Esto significa que los archivos de configuración anularán los valores predeterminados, y la línea de comandos a su vez anulará los archivos de configuración. Además, si se aplican varios archivos de configuración, los valores de los archivos «anteriores» se anulan por los archivos «posteriores».
Ubicación y nombres de los archivos de configuración¶
Los nombres y las ubicaciones de los archivos de configuración varían ligeramente según las plataformas. En Unix y macOS, los tres archivos de configuración (en el orden en que se procesan) son:
Tipo de archivo |
Ubicación y nombre de archivo |
Notas |
---|---|---|
sistema |
|
(1) |
personal |
|
(2) |
local |
|
(3) |
Y en Windows, los archivos de configuración son:
Tipo de archivo |
Ubicación y nombre de archivo |
Notas |
---|---|---|
sistema |
|
(4) |
personal |
|
(5) |
local |
|
(3) |
On all platforms, the «personal» file can be temporarily disabled by
passing the --no-user-cfg
option.
Notas:
Estrictamente hablando, el archivo de configuración de todo el sistema vive en el directorio donde están instalados los Distutils; bajo Python 1.6 y posterior en Unix, esto es como se muestra. Para Python 1.5.2, Distutils normalmente se instalará en
prefijo/lib/python1.5/site-packages/distutils
, por lo que el archivo de configuración del sistema debe colocarse allí en Python 1.5.2.En Unix, si la variable de entorno
HOME
no está definida, el directorio de inicio del usuario se determinará con la funcióngetpwuid()
del módulo estándarpwd
. Esto se realiza mediante la funciónos.path.expanduser()
utilizada por Distutils.Por ejemplo, en el directorio actual (usualmente la ubicación del script de setup).
(Ver nota (1).) En Python 1.6 y posterior, el «prefijo de instalación» por defecto de Python es
C:\Python
, entonces el archivo de configuración de sistema es normalmenteC:\Python\Lib\distutils\distutils.cfg
. En Python 1.5.2, el prefijo por defecto eraC:\Program Files\Python
, y Distutils no eran parte de la biblioteca estándar—entonces el archivo de configuración de sistema debería serC:\Program Files\Python\distutils\distutils.cfg
en una instalación estándar de Python 1.5.2 en Windows.En Windows, si la variable de entorno
HOME
no está definida, se probaráUSERPROFILE
y luegoHOMEDRIVE
yHOMEPATH
. Esto se realiza mediante la funciónos.path.expanduser()
utilizada por Distutils.
Archivos de configuración de sintaxis¶
Todos los archivos de configuración de Distutils tienen la misma sintaxis. Los archivos de configuración se agrupan en secciones. Hay una sección para cada comando de Distutils, más una sección global
para las opciones globales que afectan a cada comando. Cada sección consta de una opción por línea, especificada como opción=valor
.
Por ejemplo, el siguiente es un archivo de configuración completo que solo obliga a todos los comandos a ejecutarse silenciosamente de manera predeterminada:
[global]
verbose=0
Si se instala como el archivo de configuración del sistema, afectará todo el procesamiento de cualquier distribución del módulo Python por parte de cualquier usuario en el sistema actual. Si se instala como su archivo de configuración personal (en sistemas que los admiten), afectará solo las distribuciones de módulos procesadas por usted. Y si se usa como setup.cfg
para una distribución de módulo en particular, solo afecta a esa distribución.
Puede anular el directorio «base de compilación» predeterminado y hacer que los comandos build* siempre reconstruyan a la fuerza todos los archivos con lo siguiente:
[build]
build-base=blib
force=1
que corresponde a los argumentos de la línea de comandos
python setup.py build --build-base=blib --force
excepto que incluir el comando build en la línea de comandos significa que ese comando se ejecutará. Incluir un comando particular en los archivos de configuración no tiene tal implicación; solo significa que si se ejecuta el comando, se aplicarán las opciones en el archivo de configuración. (O si se ejecutan otros comandos que derivan valores de él, utilizarán los valores en el archivo de configuración).
Puede encontrar la lista completa de opciones para cualquier comando usando la opción --help
, por ejemplo:
python setup.py build --help
y puede encontrar la lista completa de opciones globales usando -help
sin un comando:
python setup.py --help
Ver también la sección «Referencia» del manual de «Distribución de Módulos de Python».
Construyendo Extensiones: Ayudas y trucos¶
Siempre que sea posible, los Distutils intentan utilizar la información de configuración disponible por el intérprete de Python utilizado para ejecutar el script setup.py
. Por ejemplo, los mismos indicadores de compilador y enlazador utilizados para compilar Python también se usarán para compilar extensiones. Por lo general, esto funcionará bien, pero en situaciones complicadas esto puede ser inapropiado. Esta sección discute cómo anular el comportamiento habitual de Distutils.
Ajustar las flags del compilador/enlazador¶
La compilación de una extensión de Python escrita en C o C ++ a veces requerirá especificar marcas personalizadas para el compilador y el enlazador para usar una biblioteca particular o producir un tipo especial de código de objeto. Esto es especialmente cierto si la extensión no ha sido probada en su plataforma, o si está intentando compilar Python de forma cruzada.
En el caso más general, el autor de la extensión podría haber previsto que compilar las extensiones sería complicado, y proporcionó un archivo Setup
para que lo edite. Es probable que esto solo se haga si la distribución del módulo contiene muchos módulos de extensión separados, o si a menudo requieren conjuntos elaborados de indicadores de compilación para funcionar.
Un archivo Setup
, si está presente, es parseado para obtener una lista de extensiones para compilar. Cada línea en un archivo Setup
describe un solo módulo. Las líneas tienen la siguiente estructura
module ... [sourcefile ...] [cpparg ...] [library ...]
Examinemos cada uno de los campos a su vez.
módulo es el nombre del módulo de extensión que se creará, y debe ser un identificador válido de Python. No puede simplemente cambiar esto para cambiar el nombre de un módulo (también serían necesarias ediciones en el código fuente), por lo que esto debería dejarse solo.
archivo fuente es cualquier cosa que probablemente sea un archivo de código fuente, al menos a juzgar por el nombre del archivo. Se supone que los nombres de archivo que terminan en
.c
están escritos en C, los nombres de archivo que terminan en.C
,.cc
, y.c++
son de C ++, y se supone que los nombres de archivo que terminan en.m
o.mm
están en el Objetivo C.cpparg es un argumento para el preprocesador C, y es cualquier cosa que comience con
-I
,-D
,-U
or-C
.biblioteca es todo aquello que termina con
.a
or empieza con-l
o-L
.
Si una plataforma en particular requiere una biblioteca especial en su plataforma, puede agregarla editando el archivo Setup
y ejecutando python setup.py build
. Por ejemplo, si el módulo definido por la línea
foo foomodule.c
debe estar vinculado con la biblioteca matemática libm.a
en su plataforma, simplemente agregue -lm
a la línea
foo foomodule.c -lm
Los conmutadores arbitrarios destinados al compilador o al enlazador se pueden suministrar con -Xcompiler
arg y -Xlinker
arg options:
foo foomodule.c -Xcompiler -o32 -Xlinker -shared -lm
La siguiente opción después de -Xcompiler
y -Xlinker
se agregará a la línea de comando adecuada, por lo que en el ejemplo anterior se pasará al compilador la opción -O32
, y se pasará al enlazador -shared
. Si una opción del compilador requiere un argumento, deberá proporcionar varias opciones -Xcompiler
; por ejemplo, para pasar -x c++
el Setup
debería contener -Xcompiler -x -Xcompiler c++
.
Los indicadores del compilador también se pueden suministrar configurando la variable de entorno CFLAGS
. Si se establece, el contenido de CFLAGS
se agregará a los indicadores del compilador especificados en el archivo Configuración
.
Usando un compilador que no sea de Microsoft en Windows¶
Borland/CodeGear C++¶
Esta subsección describe los pasos necesarios para utilizar Distutils con el compilador Borland C++ versión 5.5. Primero, debe saber que el formato de archivo de objetos de Borland (OMF) es diferente del formato utilizado por la versión de Python que puede descargar del sitio web de Python o ActiveState. (Python está construido con Microsoft Visual C++, que usa COFF como formato de archivo de objeto). Por esta razón, debe convertir la biblioteca de Python python25.lib
al formato Borland. Puede hacer esto de la siguiente manera:
coff2omf python25.lib python25_bcpp.lib
El programa coff2omf
viene con el compilador Borland. El archivo python25.lib
está en el directorio Libs
de su instalación de Python. Si su extensión usa otras bibliotecas (zlib, …), también debe convertirlas.
Los archivos convertidos tienen que residir en los mismos directorios que las bibliotecas normales.
¿Cómo logra Distutils usar estas bibliotecas con sus nombres cambiados? Si la extensión necesita una biblioteca (por ejemplo foo
) Distutils verifica primero si encuentra una biblioteca con el sufijo _bcpp
(por ejemplo foo_bcpp.lib
) y luego usa esta biblioteca. En el caso de que no encuentre una biblioteca tan especial, usa el nombre predeterminado (foo.lib
.) 1
Para permitir que Distutils compile su extensión con Borland C++, ahora debe escribir:
python setup.py build --compiler=bcpp
Si desea utilizar el compilador Borland C++ como predeterminado, puede especificar esto en su archivo de configuración personal o de todo el sistema para Distutils (consulte la sección Archivos de Configuración de Distutils.)
Ver también
- Compilador *C++ Builder*
Información sobre el compilador gratuito de C++ de Borland, incluidos enlaces a las páginas de descarga.
- Crear Extensiones de Python usando el Compilador libre de Borland
Documento que describe cómo usar el compilador C ++ de línea de comandos gratuito de Borland para construir Python.
GNU C / Cygwin / MinGW¶
Esta sección describe los pasos necesarios para usar Distutils con los compiladores GNU C/C++ en sus distribuciones Cygwin y MinGW. 2 Para un intérprete de Python que fue construido con Cygwin, todo debería funcionar sin ninguno de estos pasos.
No todas las extensiones se pueden construir con MinGW o Cygwin, pero muchas sí. Las extensiones que probablemente no funcionen son aquellas que usan C++ o dependen de las extensiones de Microsoft Visual C.
Para dejar que Distutils compile tu extensión con Cygwin tienes que escribir:
python setup.py build --compiler=cygwin
y para Cygwin en modo no-cygwin 3 o para tipo MinGW:
python setup.py build --compiler=mingw32
Si desea utilizar cualquiera de estas opciones/compiladores por defecto, debería considerar escribirlo en su archivo de configuración personal o de todo el sistema para Distutils (consulte la sección Archivos de Configuración de Distutils).
Versiones antiguas de Python y MinGW¶
Las siguientes instrucciones solo se aplican si está utilizando una versión de Python inferior a 2.4.1 con un MinGW inferior a 3.0.0 (con binutils-2.13.90-20030111-1).
Estos compiladores requieren algunas bibliotecas especiales. Esta tarea es más compleja que para C++ de Borland, porque no hay un programa para convertir la biblioteca. Primero debe crear una lista de símbolos que exporta la DLL de Python. (Puede encontrar un buen programa para esta tarea en https://sourceforge.net/projects/mingw/files/MinGW/Extension/pexports/).
pexports python25.dll >python25.def
La ubicación de un instalado python25.dll
dependerá de las opciones de instalación y la versión y el idioma de Windows. En una instalación «solo para mí», aparecerá en la raíz del directorio de instalación. En una instalación compartida, se ubicará en el directorio del sistema.
Luego puede crear a partir de esta información una biblioteca de importación para gcc.
/cygwin/bin/dlltool --dllname python25.dll --def python25.def --output-lib libpython25.a
La biblioteca resultante debe colocarse en el mismo directorio que python25.lib
. (Debe ser el directorio libs
en el directorio de instalación de Python.)
Si su extensión usa otras bibliotecas (zlib, …), es posible que también deba convertirlas. Los archivos convertidos tienen que residir en los mismos directorios que las bibliotecas normales.
Ver también
- Building Python modules on MS Windows platform with MinGW
Información sobre la creación de las bibliotecas necesarias para el entorno MinGW.
Notas al pie
- 1
Esto también significa que puede reemplazar todas las bibliotecas COFF existentes con bibliotecas OMF del mismo nombre.
- 2
Diríjase a https://www.sourceware.org/cygwin/ para mayor información
- 3
Entonces no tiene disponible la emulación POSIX, pero tampoco necesita
cygwin1.dll
.