To deal with the dependency management of packages that are commonly used across all the Invenio modules, we're moving to a "centralized" approach of managing them in the following fashion:
invenio-base: flask (and werkzeug), sixinvenio-celery: celery and kombu,invenio-i18n: flask-babelexinvenio-admin: flask-admininvenio-accounts: flask-login, flask-security, flask-kvsession
So if e.g. invenio-records depends in its install_requires currently on Flask, we should instead change that to a dependency to invenio-base.
There should be a section in the documentation, describing:
- How exactly we manage these?
- What is the process of addressing e.g. issues in any of the upstream libraries (e.g. Flask breaking changes)?
- How do we approach the minimum/pinned versions of the 3rd-party dependencies (i.e.
flask, celery, etc.), and for these "centralized" modules (invenio-base, etc.)
- In extreme scenarios (e.g. when we need a hotfix), what is the way to tackle these?
Note that this is not an entirely new thing, since we've already been doing this for a while with invenio-db and invenio-search for managing SQLAlchemy and Elasticsearch dependencies.
To deal with the dependency management of packages that are commonly used across all the Invenio modules, we're moving to a "centralized" approach of managing them in the following fashion:
invenio-base:flask(andwerkzeug),sixinvenio-celery:celeryandkombu,invenio-i18n:flask-babelexinvenio-admin:flask-admininvenio-accounts:flask-login,flask-security,flask-kvsessionSo if e.g.
invenio-recordsdepends in itsinstall_requirescurrently onFlask, we should instead change that to a dependency toinvenio-base.There should be a section in the documentation, describing:
flask,celery, etc.), and for these "centralized" modules (invenio-base, etc.)Note that this is not an entirely new thing, since we've already been doing this for a while with
invenio-dbandinvenio-searchfor managing SQLAlchemy and Elasticsearch dependencies.