You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by GitBox <gi...@apache.org> on 2022/01/22 18:35:59 UTC

[GitHub] [airflow] potiuk commented on issue #21033: Chart test framework as package

potiuk commented on issue #21033:
URL: https://github.com/apache/airflow/issues/21033#issuecomment-1019330625


   My opinion: I think it's far too early (and maybe even never will be a good time)  to share that code. 
   
   Sharing code is not always 100% good. While it removes duplication but introduces coupling between the parties that use the same code - and often the coupling is hidden. And when you have completely unrelated release schedule and needs and when you will need to fix something quickly, such coupling (and necessary need to introduce another release for the shared library) might have very bad impact on both projects.
   
   Sharing code is always a trade-off of "duplication" and "coupling". We saw it for example in Flask App Builder - also shared between Airflow and Superset. It causes us a lot of headeaches (for Airflow mainly because FAB is necessarily much closer to Superset due to Daniel working there)  and eventually we are about to (in the future) vendor-in only parts of Flask Appbuilder - mainly becaue of different and unpredictable release cycle between Airflow, FAB and Superset.
   
   I think the code to copy for that is very little and benefits of non-dupllcating the code are fare ouweighted by the coupling introduced. Maybe - after we introduce some optimisations it will be worthwile to make a shared library, but for now I think just copying the code responsible for those tests is better. Even if it will mean that some future changes in Airlfow will be several times copy&pasted to Superset or the other way round. At least unti we find few other 3rd-parties that would also like to use it.
   
   Maybe - at some point in time - there will be enough code and reusability to merge those approaches but I would be against introducing it now. I have the saying "the code must be usable first and you can make it reusable later" so I tend to think about having a shared "reusable" library when there are at least 3 users of very similar "usable" code.
   
   This is just my opinion though so I wonder what others think.


-- 
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.

To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org

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