[GitHub] [airflow] mik-laj commented on issue #13838: Setting up Airflow for local development is hard

[GitBox <gi...@apache.org>]

mik-laj commented on issue #13838:
URL: https://github.com/apache/airflow/issues/13838#issuecomment-766286812


   >  Go would be nicer for portability (we could relase convenience static binaries for different platforms) where python is better for our community to maintain.
   
   I don't know if this is needed as it would still be just a `docker-compose` wrapper, which would be limiting by nature and would create another layer of abstraction. In development and maintenance, we may find it easier to provide one docker-compoose file and one wrapper similar to the [`aws-cli.sh`](https://github.com/KlubJagiellonski/pola-backend/blob/master/scripts/aws-cli.sh)/[`mc.sh`](https://github.com/KlubJagiellonski/pola-backend/blob/master/scripts/mc.sh)/[`kadmin.sh`](https://github.com/mik-laj/presto-hive-kerberos-docker/blob/master/kadmin.sh) scripts to be able to access the CLI easily.  I don't want us to deal with creating another docker-compose alternative if docker-compose is a widely used tool that probably has everything we need. We have to remember that our users have different requirements and use cases that will be difficult for us to achieve if we build too thick abstraction. For example, I recently heard that one company would like to use Istio/Kerberoos, wh
 ich may require a major change to `docker-compose.yaml` to be able to get the network configuration working.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org