deploy - heroku python environment
¿Por qué heroku local: run quiere usar la instalación global de python en lugar del env virtual activado actualmente? (3)
Usando Heroku para implementar nuestra aplicación Django, todo parece funcionar según la especificación, excepto el heroku local:run .
Muchas veces necesitamos ejecutar comandos a través del archivo manage.py de Django. Ejecutarlas en el control remoto , como dinámicas únicas, funciona a la perfección. Para ejecutarlos localmente , intentamos:
heroku local:run python manage.py the_command
Lo que falla, a pesar del hecho de que el env virtual actual contiene una instalación de Django, con
ImportError: No module named django.core.management
Diagnóstico a través del camino del pitón.
Entonces heroku local:run which python devuelve heroku local:run which python :
/usr/local/bin/python
Mientras which python devuelve:
/Users/myusername/MyProject/venv/bin/python #the correct value
- ¿Es esto un error en Heroku local: correr? ¿O estamos entendiendo mal su comportamiento esperado?
- Y, lo que es más importante, ¿hay alguna forma de que
heroku local:runuse el entorno virtual actualmente instalado?
Después de contactar con el apoyo de Heroku, comprendimos el problema.
El soporte confirmó que heroku local:run debería, como se esperaba, usar el env virtual actualmente activo.
El problema es un problema de configuración local, debido a nuestro contenido en .bashrc : heroku local:run fuentes .bashrc (y en nuestro caso, esto precedía a $ PATH con la ruta a la instalación global de Python, por lo que se encontró antes que a la virtual env) . Por otro lado, heroku local no heroku local este archivo. Para citar el último mensaje de su apoyo:
heroku local: run ejecuta el comando usando bash en modo interactivo, que lee tu perfil, vs heroku local (con alias en heroku local: inicio) que no se ejecuta en modo interactivo.
La ejecución de Heroku localmente se documenta here , sin embargo, solo se refiere al uso de heroku local , que la documentación especifica es un sinónimo de heroku local:start
heroku local es una alternativa más corta a heroku local: inicio que hace lo mismo.
La auto-respuesta del OP especifica que los desarrolladores de Heroku han confirmado que si se heroku local (equivalente a heroku local:start ), entonces no se obtiene el origen .bashrc local y se usa el pitón virtualenv como se espera
Si se heroku local:run , entonces se obtiene el código .bashrc la máquina local y, en el caso del OP, ese .bashrc antepuso la ruta al sistema python a $PATH y, por lo tanto, se usó la instalación del sistema de python.
Por lo tanto, la conclusión es que heroku local:run debe usar el virtualenv python, pero no lo hará si su .bashrc contiene comandos que lo harían usar la versión del sistema de python (por ejemplo, poniendo la ruta al sistema python primero en la variable de camino).
Detalle via código a pie
Para ver el código y comprender los detalles desde ese punto de vista, consulte el repositorio de Github para ver heroku-local , en particular bajo los commands . Aquí vemos que hay un archivo Javascript para el comando de run y otro para el comando de start . Mire adentro y verá que se ven muy similares, excepto que llaman forego.run y forego.start respectivamente (note que forego.start está usando Foreman in Go - vea aquí ). Estos a su vez llaman a Node.js child_process.spawn() para generar el proceso anterior, nuevamente con run o start como argumentos respectivamente.
A continuación, run.go define un NewProcess , sobre el cual invoca ShellInvocationCommand , que es específico de la plataforma. Finalmente, vemos la raíz del problema en unix.go aquí donde se ve que el perfil se ShellInvocationCommand en ShellInvocationCommand . Cuando se utiliza start.go , el método para iniciar el proceso es completamente diferente, el profile no se obtiene, por lo que se utiliza el python virtualenv.
Para agregar a la respuesta de Ad N La razón por la que insistió en usar el sistema Python en lugar del entorno virtual desde el que se usó es la siguiente.
Heroku local: ejecute las fuentes .bashrc, que incluye la RUTA de un usuario y cualquier adición a la RUTA predeterminada. Esto incluye la ubicación del sistema Python, pero no necesariamente cualquier intérprete adicional de Python. Utilizará el primer intérprete de Python que se encuentre, que correctamente debería ser el sistema Python (de lo contrario, las cosas muy importantes, como init y la administración de paquetes, no funcionan correctamente, o no funcionan)
La forma de evitar esto es en lugar de ejecutarlo como heroku local: ejecute qué fuentes .bashrc e incluye el sistema Python para ejecutarlo como heroku local, de modo que use todo lo que esté activo en el entorno virtual.