Solución:
Puede establecer / anular las opciones de flujo de aire especificadas en ${AIRFLOW_HOME}/airflow.cfg
con variables de entorno mediante el uso de este formato: $ AIRFLOW __ {SECTION} __ {KEY} (tenga en cuenta los guiones bajos dobles). Aquí hay un enlace a los documentos de flujo de aire. Entonces puedes simplemente hacer
export AIRFLOW__CORE__DAGS_FOLDER=/path/to/dags/folder
Sin embargo, es tedioso y propenso a errores hacer esto para diferentes proyectos. Como alternativa, puede considerar usar pipenv para administrar entornos virtuales en lugar de Anaconda. Aquí hay una buena guía sobre pipenv
y problemas que resuelve. Una de las funciones predeterminadas de pipenv
es que carga automáticamente las variables definidas en .env
archivo cuando genera un shell con el virtualenv activado. Así que aquí está tu flujo de trabajo pipenv
podría verse así:
cd /path/to/my_project
# Creates venv with python 3.7
pipenv install --python=3.7 Flask==1.0.3 apache-airflow==1.10.3
# Set home for airflow in a root of your project (specified in .env file)
echo "AIRFLOW_HOME=${PWD}/airflow" >> .env
# Enters created venv and loads content of .env file
pipenv shell
# Initialize airflow
airflow initdb
mkdir -p ${AIRFLOW_HOME}/dags/
Nota: uso de
Flask==1.03
Lo explicaré al final, pero esto se debe a que pipenv comprueba si las subdependencias son compatibles para garantizar la reproducibilidad.
Entonces, después de estos pasos, obtendría la siguiente estructura de proyecto
my_project
├── airflow
│ ├── airflow.cfg
│ ├── airflow.db
│ ├── dags
│ ├── logs
│ │ └── scheduler
│ │ ├── 2019-07-07
│ │ └── latest -> /path/to/my_project/airflow/logs/scheduler/2019-07-07
│ └── unittests.cfg
├── .env
├── Pipfile
└── Pipfile.lock
Ahora, cuando inicialice el flujo de aire por primera vez, se creará ${AIRFLOW_HOME}/airflow.cfg
archivo y usará / expandirá ${AIRFLOW_HOME}/dags
como valor para dags_folder
. En caso de que aún necesite una ubicación diferente para dags_folder
, puedes usar .env
archivo de nuevo
echo "AIRFLOW__CORE__DAGS_FOLDER=/different/path/to/dags/folder" >> .env
Por lo tanto, tu .env
el archivo se verá así:
AIRFLOW_HOME=/path/to/my_project/airflow
AIRFLOW__CORE__DAGS_FOLDER=/different/path/to/dags/folder
¿Qué hemos logrado y por qué esto funcionaría bien?
- Desde que instalaste
airflow
en un entorno virtual, necesitaría activarlo para poder usarairflow
- Desde que lo hiciste con
pipenv
, necesitarías usarpipenv shell
para activar venv - Desde que usas
pipenv shell
, siempre obtendría variables definidas en.env
exportado a su venv. Encima de esopipenv
seguirá siendo una subcapa, por lo tanto, cuando salga de ella, también se borrarán todas las variables ambientales adicionales. - Los diferentes proyectos que usan el flujo de aire tendrían diferentes ubicaciones para sus archivos de registro, etc.
Notas adicionales sobre pipenv
- Para usar venv creado con pipenv como intérprete de proyecto de su IDE, use la ruta proporcionada por
pipenv --py
. - Por defecto,
pipenv
crea todos los venvs en la misma ubicación global como lo hace conda, pero puede cambiar ese comportamiento para crear.venv
en la raíz de un proyecto agregandoexport PIPENV_VENV_IN_PROJECT=1
en tu.bashrc
(u otrorc
). Entonces PyCharm podría recogerlo automáticamente cuando ingrese a la configuración del intérprete del proyecto.
Nota sobre el uso de Flask==1.0.3
El flujo de aire 1.10.3 de PyPi depende de flask>=1.0, <2.0
y en jinja2>=2.7.3, <=2.10.0
. Hoy, cuando probé los fragmentos de código, los últimos disponibles flask
era 1.1.0 que depende de jinja2>=2.10.1
. Esto significa que, aunque pipenv puede instalar todo el software necesario, no puede bloquear las dependencias. Entonces, para un uso limpio de mis ejemplos de código, tuve que especificar la versión de flask
que requiere la versión de jinja2
compatible con los requisitos de flujo de aire. Pero no hay nada de qué preocuparse. La última versión de airflow
en GitHub ya está arreglado.