¿Debo poner #! (shebang) en los scripts de Python, y ¿qué forma debería tomar?

¿Debo poner el shebang en mis scripts de Python? En que forma

#!/usr/bin/env python 

o

#!/usr/local/bin/python

¿Son estos igualmente portátiles? ¿Qué forma se usa más?

Nota: elproyecto tornado usa el shebang. Por otro lado, elproyecto Django no.

La línea shebang en cualquier secuencia de comandos determina la capacidad de la secuencia de comandos para ejecutarse como un ejecutable independiente sin escribir de pythonantemano en el terminal o al hacer doble clic en un administrador de archivos (cuando está configurado correctamente). No es necesario, pero generalmente se coloca allí para que cuando alguien vea el archivo abierto en un editor, inmediatamente sepan lo que están viendo. Sin embargo, qué línea de shebang usas ES importante.

El uso correcto de los scripts de Python 3 es:

#!/usr/bin/env python3

Esto predeterminado a la versión 3.latest. Para Python 2.7. Uso posterior python2en lugar de python3.

Lo siguiente no se debe utilizar (excepto en el caso raro que usted está escribiendo código que es compatible tanto con Python 2.x y 3.x):

#!/usr/bin/env python

La razón de estas recomendaciones, dadas en PEP 394 , es que pythonpueden referirse a diferentes sistemas python2o python3en ellos. Actualmente se refiere a la python2mayoría de las distribuciones, pero es probable que eso cambie en algún momento.

Además, NO USE:

#!/usr/local/bin/python

"Python puede instalarse en / usr / bin / python o / bin / python en esos casos, el #! anterior fallará".

- "#! / usr / bin / env python" frente a "#! / usr / local / bin / python"

Realmente es solo una cuestión de gustos. Agregar el shebang significa que las personas pueden invocar el script directamente si lo desean (suponiendo que esté marcado como ejecutable); omitirlo solo significa pythonque debe invocarse manualmente.

El resultado final de ejecutar el programa no se ve afectado de ninguna manera; son solo opciones de los medios.

¿Debo poner el shebang en mis scripts de Python?

Pon un shebang en un script de Python para indicar:

• este módulo puede ejecutarse como un script
• si se puede ejecutar solo en python2, python3 o si es compatible con Python 2/3
• en POSIX, es necesario si desea ejecutar el script directamente sin invocar el pythonejecutable explícitamente

¿Son estos igualmente portátiles? ¿Qué forma se usa más?

Si escribe un shebang manualmente, úselo siempre, a #!/usr/bin/env pythonmenos que tenga una razón específica para no usarlo. Este formulario se entiende incluso en Windows (Python Launcher).

Nota: los scripts instalados deben usar un ejecutable de Python específico, por ejemplo, /usr/bin/pythono /home/me/.virtualenvs/project/bin/python. Es malo si alguna herramienta se rompe si activa un virtualenv en su shell. Afortunadamente, el shebang correcto se crea automáticamente en la mayoría de los casos por las setuptoolsherramientas del paquete de distribución (en Windows, setuptoolspuede generar .exescripts de envoltura automáticamente).

En otras palabras, si el script está en un proceso de pago de origen, entonces probablemente verá #!/usr/bin/env python. Si está instalado, el shebang es una ruta a un ejecutable de Python específico como #!/usr/local/bin/python (NOTA: no debe escribir las rutas de la última categoría manualmente).

Para elegir si debe usar python, python2o python3en el shebang, consulte PEP 394 - El comando "python" en sistemas tipo Unix :

• ... pythondebe usarse en la línea shebang solo para scripts que sean compatibles con fuentes tanto con Python 2 como con 3.

• En preparación para un eventual cambio en la versión predeterminada de Python, los scripts de Python 2 solo deben actualizarse para que sean compatibles con Python 3 o bien para usar python2en la línea shebang.

Si tiene más de una versión de Python y el script necesita ejecutarse bajo una versión específica, she-bang puede garantizar que se use el correcto cuando el script se ejecuta directamente, por ejemplo:

#!/usr/bin/python2.7

Tenga en cuenta que el script aún se puede ejecutar a través de una línea de comando completa de Python, o mediante importación, en cuyo caso se ignora el she-bang. Pero para los scripts ejecutados directamente, esta es una razón decente para usar she-bang.

#!/usr/bin/env python generalmente es el mejor enfoque, pero esto ayuda con casos especiales.

Por lo general, sería mejor establecer un entorno virtual de Python, en cuyo caso el genérico #!/usr/bin/env pythonidentificaría la instancia correcta de Python para virtualenv.

Debe agregar un shebang si el script está destinado a ser ejecutable. También debe instalar el script con un software de instalación que modifique el shebang a algo correcto para que funcione en la plataforma de destino. Ejemplos de esto son distutils y Distribute.

El propósito de shebang es que el script reconozca el tipo de intérprete cuando desea ejecutar el script desde el shell. Principalmente, y no siempre, ejecuta scripts al proporcionar el intérprete externamente. Ejemplo de uso:python-x.x script.py

Esto funcionará incluso si no tienes un declarador shebang.

Por qué el primero es más "portátil" es porque /usr/bin/envcontiene su PATHdeclaración que explica todos los destinos donde residen los ejecutables de su sistema.

NOTA: Tornado no usa estrictamente shebangs, y Django estrictamente no lo hace. Varía según cómo esté ejecutando la función principal de su aplicación.

TAMBIÉN: No varía con Python.

A veces, si la respuesta no es muy clara (quiero decir que no puede decidir si sí o no), entonces no importa demasiado y puede ignorar el problema hasta que la respuesta sea clara.

El #!único propósito es lanzar el script. Django carga las fuentes por sí solo y las usa. Nunca necesita decidir qué intérprete debe usarse. De esta manera, la #!realidad no tiene sentido aquí.

Generalmente, si es un módulo y no se puede usar como un script, no hay necesidad de usar el #!. Por otro lado, una fuente de módulo a menudo contiene if __name__ == '__main__': ...al menos algunas pruebas triviales de la funcionalidad. Entonces el #!tiene sentido de nuevo.

Una buena razón para usarlo #!es cuando usa los scripts Python 2 y Python 3: deben ser interpretados por diferentes versiones de Python. De esta manera, debe recordar qué pythondebe usarse al iniciar el script manualmente (sin el #!interior). Si tiene una mezcla de tales scripts, es una buena idea usar el #!interior, hacerlos ejecutables y ejecutarlos como ejecutables (chmod ...).

Al usar MS-Windows, #!no tenía sentido, hasta hace poco. Python 3.3 presenta un Lanzador de Python de Windows (py.exe y pyw.exe) que lee la #!línea, detecta las versiones instaladas de Python y usa la versión correcta o explícitamente deseada de Python. Como la extensión se puede asociar con un programa, puede obtener un comportamiento similar en Windows como con el indicador de ejecución en sistemas basados ​​en Unix.

Cuando instalé Python 3.6.1 en Windows 7 recientemente, también instalé Python Launcher para Windows, que se supone que maneja la línea shebang. Sin embargo, descubrí que Python Launcher no hizo esto: la línea shebang fue ignorada y Python 2.7.13 siempre se usó (a menos que ejecute el script usando py -3).

Para solucionar esto, tuve que editar la clave de registro de Windows HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Python.File\shell\open\command. Esto todavía tenía el valor

"C:\Python27\python.exe" "%1" %*

de mi instalación anterior de Python 2.7. Modifiqué este valor de clave de registro a

"C:\Windows\py.exe" "%1" %*

y el procesamiento de la línea shebang de Python Launcher funcionó como se describió anteriormente.

Si tiene diferentes módulos instalados y necesita usar una instalación específica de Python, entonces shebang parece estar limitado al principio. Sin embargo, puede hacer trucos como el siguiente para permitir que se invoque el shebang primero como un script de shell y luego elija python. Esto es muy flexible:

#!/bin/sh
#
# Choose the python we need. Explanation:
# a) '''\' translates to \ in shell, and starts a python multi-line string
# b) "" strings are treated as string concat by python, shell ignores them
# c) "true" command ignores its arguments
# c) exit before the ending ''' so the shell reads no further
# d) reset set docstrings to ignore the multiline comment code
#
"true" '''\'
PREFERRED_PYTHON=/Library/Frameworks/Python.framework/Versions/2.7/bin/python
ALTERNATIVE_PYTHON=/Library/Frameworks/Python.framework/Versions/3.6/bin/python3
FALLBACK_PYTHON=python3

if [ -x $PREFERRED_PYTHON ]; then
    echo Using preferred python $PREFERRED_PYTHON
    exec $PREFERRED_PYTHON "$0" "$@"
elif [ -x $ALTERNATIVE_PYTHON ]; then
    echo Using alternative python $ALTERNATIVE_PYTHON
    exec $ALTERNATIVE_PYTHON "$0" "$@"
else
    echo Using fallback python $FALLBACK_PYTHON
    exec python3 "$0" "$@"
fi
exit 127
'''

__doc__ = """What this file does"""
print(__doc__)
import platform
print(platform.python_version())

O mejor aún, tal vez, para facilitar la reutilización del código en múltiples scripts de Python:

#!/bin/bash
"true" '''\'; source $(cd $(dirname ${BASH_SOURCE[@]}) &>/dev/null && pwd)/select.sh; exec $CHOSEN_PYTHON "$0" "$@"; exit 127; '''

y luego select.sh tiene:

PREFERRED_PYTHON=/Library/Frameworks/Python.framework/Versions/2.7/bin/python
ALTERNATIVE_PYTHON=/Library/Frameworks/Python.framework/Versions/3.6/bin/python3
FALLBACK_PYTHON=python3

if [ -x $PREFERRED_PYTHON ]; then
    CHOSEN_PYTHON=$PREFERRED_PYTHON
elif [ -x $ALTERNATIVE_PYTHON ]; then
    CHOSEN_PYTHON=$ALTERNATIVE_PYTHON
else
    CHOSEN_PYTHON=$FALLBACK_PYTHON
fi

Respuesta: Solo si planea convertirlo en un script ejecutable de línea de comandos.

Aquí está el procedimiento:

Comience verificando la cadena shebang adecuada para usar:

which python

Tome el resultado de eso y agréguelo (con el shebang #!) En la primera línea.

En mi sistema responde así:

$which python
/usr/bin/python

Entonces su shebang se verá así:

#!/usr/bin/python

Después de guardar, seguirá ejecutándose como antes, ya que Python verá esa primera línea como un comentario.

python filename.py

Para convertirlo en un comando, cópielo para soltar la extensión .py.

cp filename.py filename

Dígale al sistema de archivos que esto será ejecutable:

chmod +x filename

Para probarlo, use:

./filename

La mejor práctica es moverlo a algún lugar de su $ PATH, por lo que todo lo que necesita escribir es el nombre del archivo.

sudo cp filename /usr/sbin

De esa manera funcionará en todas partes (sin el ./ antes del nombre del archivo)

Ruta absoluta vs lógica:

Esta es realmente una pregunta sobre si la ruta al intérprete de Python debe ser absoluta o lógica ( /usr/bin/env) con respecto a la portabilidad.

Al encontrar otras respuestas en este y otros sitios de Stack que hablaron sobre el tema de manera general sin pruebas de apoyo, realicé algunas pruebas y análisis realmente, REALMENTE , granulares sobre esta misma pregunta en unix.stackexchange.com . En lugar de pegar esa respuesta aquí, señalaré a los interesados ​​en el análisis comparativo a esa respuesta:

https://unix.stackexchange.com/a/566019/334294

Como ingeniero de Linux, mi objetivo siempre es proporcionar los hosts más adecuados y optimizados para mis clientes desarrolladores, por lo que el problema de los entornos Python era algo para lo que realmente necesitaba una respuesta sólida. Mi opinión después de la prueba fue que la ruta lógica en el she-bang era la mejor de las (2) opciones.

Usar primero

which python

Esto dará el resultado como la ubicación donde está presente mi intérprete de Python (binario).

Esta salida podría ser cualquiera como

/usr/bin/python

o

/bin/python

Ahora seleccione apropiadamente la línea shebang y úsela.

Para generalizar podemos usar:

#!/usr/bin/env

o

#!/bin/env