[all] Removing Babel from requirements.txt
Hi folks, Many of the projects have [1] Babel in requirements.txt. I'm not sure why it was needed initially, but now Babel is only used in the translation infrastructure to manage the catalogs. Particularly, it's not imported in runtime by anything (oslo.i18n has recently removed [2] its usage). The problem is, Babel weighs nearly 30MiB (estimated on a venv), making it probably the heaviest dependency we have. According to amotoki, we don't need Babel anywhere in the requirements, since the translation infrastructure installs it explicitly [3][4]. Sphinx has a requirement on Babel, so doc and release note builds will be fine as well. I suggest that all projects remove an explicit requirement on Babel completely. I've started proposing changes [5] to implement it for repositories that are used by ironic projects (since it's my immediate area of interest). I'd appreciate help with the others. Dmitry [1] http://codesearch.openstack.org/?q=Babel&i=nope&files=requirements.txt&repos= [2] https://review.opendev.org/720550 [3] https://opendev.org/openstack/project-config/src/branch/master/playbooks/tra... [4] https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-babel/task... [5] https://review.opendev.org/#/q/topic:no-babel
On Fri, 2020-04-17 at 15:35 +0200, Dmitry Tantsur wrote:
Hi folks,
Many of the projects have [1] Babel in requirements.txt. I'm not sure why it was needed initially, but now Babel is only used in the translation infrastructure to manage the catalogs. Particularly, it's not imported in runtime by anything (oslo.i18n has recently removed [2] its usage). The problem is, Babel weighs nearly 30MiB (estimated on a venv), making it probably the heaviest dependency we have.
According to amotoki, we don't need Babel anywhere in the requirements, since the translation infrastructure installs it explicitly [3][4]. Sphinx has a requirement on Babel, so doc and release note builds will be fine as well. I suggest that all projects remove an explicit requirement on Babel completely.
Looking at [1] it seems we're not using the setuptools entry point either. Does that mean we can drop the '[extract_messages]', '[compile_catalog]' and '[update_catalog]' sections from 'setup.cfg' also? Cheers, Stephen [1] https://opendev.org/openstack/openstack-zuul-jobs/src/commit/8ab3345e4dde2f5...
I've started proposing changes [5] to implement it for repositories that are used by ironic projects (since it's my immediate area of interest). I'd appreciate help with the others.
Dmitry
[1] http://codesearch.openstack.org/?q=Babel&i=nope&files=requirements.txt&repos= [2] https://review.opendev.org/720550 [3] https://opendev.org/openstack/project-config/src/branch/master/playbooks/tra... [4] https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-babel/task... [5] https://review.opendev.org/#/q/topic:no-babel
On 17.04.20 17:14, Stephen Finucane wrote:
On Fri, 2020-04-17 at 15:35 +0200, Dmitry Tantsur wrote:
Hi folks,
Many of the projects have [1] Babel in requirements.txt. I'm not sure why it was needed initially, but now Babel is only used in the translation infrastructure to manage the catalogs. Particularly, it's not imported in runtime by anything (oslo.i18n has recently removed [2] its usage). The problem is, Babel weighs nearly 30MiB (estimated on a venv), making it probably the heaviest dependency we have.
According to amotoki, we don't need Babel anywhere in the requirements, since the translation infrastructure installs it explicitly [3][4]. Sphinx has a requirement on Babel, so doc and release note builds will be fine as well. I suggest that all projects remove an explicit requirement on Babel completely.
Looking at [1] it seems we're not using the setuptools entry point either. Does that mean we can drop the '[extract_messages]', '[compile_catalog]' and '[update_catalog]' sections from 'setup.cfg' also?
Since we use "pybabel extract", I think we can - but in that case, let's first update the documentation: https://docs.openstack.org/i18n/latest/project_setup.html#python-projects Andreas -- Andreas Jaeger aj@suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB
participants (3)
-
Andreas Jaeger
-
Dmitry Tantsur
-
Stephen Finucane