PYTHONPATH vs. sys.path

Question

Otro desarrollador y yo no estamos de acuerdo sobre si PYTHONPATH o sys.path deben usarse para permitir que Python encuentre un paquete de Python en un directorio de usuario (por ejemplo, desarrollo).

Tenemos un proyecto de Python con una estructura de directorios típica:

Project 
    setup.py 
    package 
     __init__.py 
     lib.py 
     script.py 

En script.py, tenemos que hacer import package.lib. Cuando el paquete se instala en paquetes de sitio, script.py puede encontrar package.lib.

Sin embargo, cuando se trabaja desde un directorio de usuarios, se necesita hacer algo más. Mi solución es configurar mi PYTHONPATH para que incluya "~/Proyecto". Otro desarrollador quiere poner esta línea de código en el inicio de script.py:

sys.path.append(os.path.dirname(os.path.dirname(os.path.abspath(__file__)))) 

Así que Python puede encontrar la copia local de package.lib.

Creo que esta es una mala idea, ya que esta línea solo es útil para desarrolladores o personas que ejecutan una copia local, pero no puedo dar una buena razón por la que es una mala idea.

¿Deberíamos usar PYTOHNPATH, sys.path, o está bien?

Answer 1

Si la única razón para modificar la ruta es que los desarrolladores trabajen desde su árbol de trabajo, entonces debe usar una herramienta de instalación para configurar su entorno. virtualenv es muy popular, y si está utilizando setuptools, simplemente puede ejecutar setup.py develop para instalar el árbol de trabajo en su instalación actual de Python.

Answer 2

Creo que, en este caso, utilizar PYTHONPATH es una mejora, sobre todo porque no introduce un código innecesario (cuestionable).

Después de todo, si se piensa en ello, el usuario no es necesario que sys.path cosa, porque su paquete se instalan en site-packages, porque se va a utilizar un sistema de envasado.

Si el usuario elige ejecutar desde una "copia local", como usted lo llama, entonces he observado que la práctica habitual es afirmar que el paquete debe agregarse a PYTHONPATH manualmente, si se usa afuera los paquetes del sitio.

Answer 3

Odio PYTHONPATH. Me resulta frágil y molesto establecerlo por usuario (especialmente para usuarios daemon) y hacer un seguimiento de las carpetas de proyectos que se mueven. Preferiría establecer sys.path en las secuencias de comandos de invocación para proyectos independientes.

Sin embargo, sys.path.append no es la forma de hacerlo. Puede obtener duplicados fácilmente y no ordena los archivos .pth. Mejor (y más legible): site.addsitedir.

Y script.py normalmente no sería el lugar más adecuado para hacerlo, ya que es dentro de el paquete que desea que esté disponible en la ruta. Los módulos de la biblioteca ciertamente no deberían estar en contacto con el sys.path. En cambio, normalmente tendrías una secuencia de comandos hashbanged fuera del paquete que usas para crear y ejecutar la aplicación, y es en este guión de envoltura trivial donde pondrías detalles de implementación como sys.path -flugging.

Answer 4

Junto con las muchas otras razones ya mencionadas, también podría apuntar outh que la codificación dura

sys.path.append(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))

es frágil, ya que supone la localización de script.py - sólo funcionará si el script .py se encuentra en Proyecto/paquete. Se romperá si un usuario decide mover/copiar/enlace simbólico script.py (casi) en cualquier otro lugar.

Answer 5

En general, consideraría la creación de una variable de entorno (como PYTHONPATH) como una mala práctica. Si bien esto podría estar bien para una depuración única pero usando esto como
, una práctica regular puede no ser una buena idea.

El uso de la variable de entorno conduce a situaciones como "me funciona" cuando alguien
más informa problemas en la base de código. También se podría llevar a cabo la misma práctica con el entorno de prueba , lo que da lugar a situaciones como las pruebas que funcionan bien para un desarrollador en particular , pero que probablemente fallan cuando alguien inicia las pruebas.