[horizon][requirements] django-3 blocked by usage of django-babel
amotoki at gmail.com
Sat Dec 28 20:24:39 UTC 2019
Update on django-babel/enmerkar.
To switch django-babel to enmerkar, we need:
(1) Cleanup babel configurations in horizon plugins, and
(2) Switch django-babel to enmerkar in global-requirements
To move (1) forward, I proposed patches to horizon plugins .
The babel extractors are registered via entry points so this change makes the
maintenance simple regardless of that we switch to enmerkar.
Once the cleanup of babel configurations in horizon plugins is done,
the cost of switching the babel extractor for django would be low as
we can switch the babel extractor for django only by changing it in the horizon
repo (+ requirements repo), so I think we can switch enmerkar and if
changes we can switch back to django-babel or others.
Regarding (2), I proposed patches both to the requirements and horizon
The current blocking issue is that enmerkar depends on Django>=2.2 but horizon
still supports Django 1.11. We plan to drop Django 1.11 support in
so we need to wait until Django 1.11 support is dropped. (python 2.7
support has been
dropped in most horizon plugins so there is no blocking topic for
django 1.11 drop.)
django-babel is not a runtime requirement of horizon. It is just used
when we extract
translation strings and the current user is the infra translation jobs
, so I think we don't
need to care co-installability much. It can be moved to
test-requirements.txt in horizon
and we can install django-babel/enmerkar explicitly in
common_translation_update.sh in .
 https://review.opendev.org/#/c/700727/ (requirements repo)
 https://review.opendev.org/#/c/700728/ (horizon repo)
On Mon, Dec 23, 2019 at 4:09 PM Akihiro Motoki <amotoki at gmail.com> wrote:
> I am aware of the issue.
> While switching to enmerkar looks like the straightforward way,
> I am trying to explore a way to continue django-babel to minimize the
> impact to consumers and packagers.
> When we switch enmerkar, we need to clean up babel-django.cfg in horizon 
> and all horizon plugin repos, plus the infra manual. babel-django.cfg specifies
> an extractor from django-babel explicitly. We need to drop the extract
> entry first
> (as the "django" extractor is registered via an entrypoint in the
> recent django-babel
> and enmerkar).
> BTW, how did you notice this?
>  https://opendev.org/openstack/horizon/src/branch/master/babel-django.cfg
> On Sun, Dec 22, 2019 at 6:28 AM Matthew Thode <mthode at mthode.org> wrote:
> > it looks like django-babel is unmaintained since 2017, so perhaps it's
> > time to look for a replacement. Looking through github issues, it looks
> > like enmerkar is a possible replacement. If that's fine with horizon /
> > django consumers we can start by adding enmerkar to global-requirements
> > and upper-constraints.
> > Thanks,
> > --
> > Matthew Thode
More information about the openstack-discuss