[horizon][requirements] django-3 blocked by usage of django-babel
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
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 [1] 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? [1] https://opendev.org/openstack/horizon/src/branch/master/babel-django.cfg On Sun, Dec 22, 2019 at 6:28 AM Matthew Thode <mthode@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
The subject of this thread looks confusing to me. "django-3 blocked by usage of django-babel" Horizon team has not adopted Django 3. An issue I noticed is that django-babel is not compatible with Django 2.2 and translation message extraction in the master branch is now broken. If some test tries to install Django 3, it would be due to some misconfiguration. Thanks, Akihiro On Mon, Dec 23, 2019 at 4:09 PM Akihiro Motoki <amotoki@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 [1] 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?
[1] https://opendev.org/openstack/horizon/src/branch/master/babel-django.cfg
On Sun, Dec 22, 2019 at 6:28 AM Matthew Thode <mthode@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
On 12/23/19 9:59 AM, Akihiro Motoki wrote:
The subject of this thread looks confusing to me. "django-3 blocked by usage of django-babel"
Horizon team has not adopted Django 3. An issue I noticed is that django-babel is not compatible with Django 2.2 and translation message extraction in the master branch is now broken.
If some test tries to install Django 3, it would be due to some misconfiguration.
Thanks, Akihiro
Well, it'd be nice to have plans to get Django 3 compat for the end of this cycle, otherwise, we'll get again stuck in downstream distributions, just like we've been stuck in Debian with a broken Horizon for nearly the whole of the last summer (due to Django 2.2 and the new view class instead of method thing breaking all ...). I guess we're all being super tired of Django breaking the world every 2 weeks. At least, I am. But I don't think we have any alternatives... (and no, I do not have time, neither probably the skills, to work on this, sorry...) Cheers, Thomas Goirand (zigo)
On Thu, Dec 26, 2019 at 5:57 AM Thomas Goirand <zigo@debian.org> wrote:
On 12/23/19 9:59 AM, Akihiro Motoki wrote:
The subject of this thread looks confusing to me. "django-3 blocked by usage of django-babel"
Horizon team has not adopted Django 3. An issue I noticed is that django-babel is not compatible with Django 2.2 and translation message extraction in the master branch is now broken.
If some test tries to install Django 3, it would be due to some misconfiguration.
Thanks, Akihiro
Well, it'd be nice to have plans to get Django 3 compat for the end of this cycle, otherwise, we'll get again stuck in downstream distributions, just like we've been stuck in Debian with a broken Horizon for nearly the whole of the last summer (due to Django 2.2 and the new view class instead of method thing breaking all ...).
I guess we're all being super tired of Django breaking the world every 2 weeks. At least, I am. But I don't think we have any alternatives... (and no, I do not have time, neither probably the skills, to work on this, sorry...)
Djagno 3 support is not in the list of horizon priorities in Ussuri cycle as it is not an LTS release. It is documented in [1]. The top priorities are found in [2]. I don't think we can do it as a priority considering the resource of the active horizon developers. It completely depends on development resources and is a topic of investment. If someone is responsible to work on it to support both Django 2.2 and 3, I am happy to review it. Thanks, Akihiro [1] https://docs.openstack.org/horizon/latest/contributor/policy.html#django-sup... [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011442....
Cheers,
Thomas Goirand (zigo)
On 12/28/19 3:59 PM, Akihiro Motoki wrote:
On Thu, Dec 26, 2019 at 5:57 AM Thomas Goirand <zigo@debian.org> wrote:
On 12/23/19 9:59 AM, Akihiro Motoki wrote:
The subject of this thread looks confusing to me. "django-3 blocked by usage of django-babel"
Horizon team has not adopted Django 3. An issue I noticed is that django-babel is not compatible with Django 2.2 and translation message extraction in the master branch is now broken.
If some test tries to install Django 3, it would be due to some misconfiguration.
Thanks, Akihiro
Well, it'd be nice to have plans to get Django 3 compat for the end of this cycle, otherwise, we'll get again stuck in downstream distributions, just like we've been stuck in Debian with a broken Horizon for nearly the whole of the last summer (due to Django 2.2 and the new view class instead of method thing breaking all ...).
I guess we're all being super tired of Django breaking the world every 2 weeks. At least, I am. But I don't think we have any alternatives... (and no, I do not have time, neither probably the skills, to work on this, sorry...)
Hi Akihiro,
Djagno 3 support is not in the list of horizon priorities in Ussuri cycle as it is not an LTS release.
I often get this type of answer from the Horizon team. Unfortunately, this doesn't help with the situation. When Django 3 will reach Debian Sid, Horizon will likely be broken, regardless of Django 3 being LTS or not.
It is documented in [1]. The top priorities are found in [2]. I don't think we can do it as a priority considering the resource of the active horizon developers. It completely depends on development resources and is a topic of investment. If someone is responsible to work on it to support both Django 2.2 and 3, I am happy to review it.
Sure! I completely understand. <ranting about django upstream> Something like the Linux kernel never breaks userland, and it's been like this for decades. As I wrote, Django is breaking the world every 6 months. Not only these happen, but Django upstream only document it in the release note with "thing Z is removed in this release", when really, they should be saying "if you wrote X, then you should write Y instead to address Z being removed". Then we always got to search the internet for someone who already understood the breakage and fixed it, though when a new release of Django just happened, it's hard to find such example. All of this is annoying, frustrating, and IMO not professional at all from the Django upstream. I'm not sure how we can move things toward a better direction so the madness stops. </ranting> On top of that, very rarely, there's enough resources in the Horizon team to address the breakage early enough. I often tried to fix a few things, but I lack enough time and skills (both are related, of course: if I can't find time to work on these, I can't learn and get skills). Anyway, thanks for your answer, Cheers, Thomas Goirand (zigo)
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 [1]. 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 the situation changes we can switch back to django-babel or others. Regarding (2), I proposed patches both to the requirements and horizon repos [2][3]. 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 Ussuri milestone-2, 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.) (side note) 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 [4], 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 [4]. [1] https://review.opendev.org/#/q/topic:babel-config+(status:open+OR+status:mer...) [2] https://review.opendev.org/#/c/700727/ (requirements repo) [3] https://review.opendev.org/#/c/700728/ (horizon repo) [4] https://opendev.org/openstack/openstack-zuul-jobs/src/branch/master/roles/pr... Thanks, Akihiro Motoki On Mon, Dec 23, 2019 at 4:09 PM Akihiro Motoki <amotoki@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 [1] 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?
[1] https://opendev.org/openstack/horizon/src/branch/master/babel-django.cfg
On Sun, Dec 22, 2019 at 6:28 AM Matthew Thode <mthode@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
On 28/12/2019 21.24, Akihiro Motoki wrote:
[...] (side note) 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 [4], 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 [4].
How will you support stable branches? As you know, the change needs to work with all branches we have translations on, 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
On Mon, Dec 30, 2019 at 10:58 PM Andreas Jaeger <aj@suse.com> wrote:
On 28/12/2019 21.24, Akihiro Motoki wrote:
[...] (side note) 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 [4], 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 [4].
How will you support stable branches?
As you know, the change needs to work with all branches we have translations on,
What in my mind is just to move django-babel/enmerkar to test-requirements.txt in the master (ussuri). project-config is branchless, so I believe it is enough to make the following change in install_horizon(). Doesn't it work? (cd ${HORIZON_DIR} && pip install -c $UPPER_CONSTRAINTS_FILE .) to (cd ${HORIZON_DIR} && pip install -c $UPPER_CONSTRAINTS_FILE . && pip install -c $UPPER_CONSTRAINTS_FILE test-requirements.txt)
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
On 31/12/2019 01.10, Akihiro Motoki wrote:
On Mon, Dec 30, 2019 at 10:58 PM Andreas Jaeger <aj@suse.com> wrote:
On 28/12/2019 21.24, Akihiro Motoki wrote:
[...] (side note) 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 [4], 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 [4].
How will you support stable branches?
As you know, the change needs to work with all branches we have translations on,
What in my mind is just to move django-babel/enmerkar to test-requirements.txt in the master (ussuri). project-config is branchless, so I believe it is enough to make the following change in install_horizon(). Doesn't it work?
(cd ${HORIZON_DIR} && pip install -c $UPPER_CONSTRAINTS_FILE .) to (cd ${HORIZON_DIR} && pip install -c $UPPER_CONSTRAINTS_FILE . && pip install -c $UPPER_CONSTRAINTS_FILE test-requirements.txt)
That should work - too simple ;) 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 (4)
-
Akihiro Motoki
-
Andreas Jaeger
-
Matthew Thode
-
Thomas Goirand