It is sometimes hard to distinguish if it is a library or an application. Take operator as an example, a non-tech people may think it as a well-built application while an engineer may consider it as a library and extends functionalities on it.
On Thu, Aug 1, 2019 at 4:26 PM Qingping Hou <[email protected]> wrote: > see replies inline :) > > On Thu, Aug 1, 2019 at 12:42 PM Ash Berlin-Taylor <[email protected]> wrote: > > The usual advice (at least for other languages, I don't know about > Python) is that end applications should exactly pin their deps, but that > libraries should be forgiving, so that it is easier to use it alongside > other things, and for instance so that a site operator can install a > security fix to a module without us having to make patch release. > > > > This is the recommended practice for Python as well. Libraries should > have their dependencies defined as flexible as possible to avoid > downstream conflicts. For application, it's better to freeze as many > dependencies as possible to avoid surprises. > > > And Airflow is both an application, and a library. > > If this is the case, I can see the reasoning for maintaining two sets > of dependency requirements and let the user pick which one works best > for them. > > In an ideal world, it would be better to separate out library > functionality and application/core functionality. Then have a freeze > pin for the core source tree and flexible range for the library source > tree. >
