You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The code I see here seems very Django specific. I'm ok with this, but it is in contrast with the name of the package, python-dockerflow. Is the goal of this package to be generic across any Python app? Or should we rename the repo to django-dockerflow?
Yep, the code is currently Django specific since that's what was existing when I started to port it. That's why the Django support is in dockerflow.django.
The plan is to have a central repo for various Python bits, e.g. a Flask extension in dockerflow.flask is next on my TODO list for Re:dash/Airflow. The general idea is to keep the code in one repo to be able to implement the core pieces centrally instead of individually per Python-based framework/toolset.
Alternatively we could have made python-dockerflow only implement the core features (e.g. "get content of version.json from a location") and then have separate packages per framework/toolset (e.g. django-dockerflow, flask-dockerflow, pyramid-dockerflow). I decided against that since it increases the amount of maintenance burden dramatically at this stage, and we can still do that split if really needed at a later stage.
Activity
jezdez commentedon Nov 15, 2016
Yep, the code is currently Django specific since that's what was existing when I started to port it. That's why the Django support is in
dockerflow.django.The plan is to have a central repo for various Python bits, e.g. a Flask extension in
dockerflow.flaskis next on my TODO list for Re:dash/Airflow. The general idea is to keep the code in one repo to be able to implement the core pieces centrally instead of individually per Python-based framework/toolset.Alternatively we could have made python-dockerflow only implement the core features (e.g. "get content of version.json from a location") and then have separate packages per framework/toolset (e.g. django-dockerflow, flask-dockerflow, pyramid-dockerflow). I decided against that since it increases the amount of maintenance burden dramatically at this stage, and we can still do that split if really needed at a later stage.
jezdez commentedon Nov 15, 2016
Closing this as I think it's not an issue, please do reopen if you want to do the split right away.
mythmon commentedon Nov 15, 2016
I think having this all in one repo makes sense. I just wanted to clarify what the intentions were.
jezdez commentedon Nov 15, 2016
@mythmon \o/