Django-prometheus breaks due to prometheus-client python package release 0.4.0 on Oct 04 2018 about django-prometheus

[crccheck]

I'm using Waitress and prometheus-client 0.4.1 is still working for me

[korfuri]

Can you clarify what the failure is?

…

On Wed, Oct 10, 2018, 03:55 Chris Chang ***@***.***> wrote: I'm using Waitress and prometheus-client 0.4.1 is still working for me — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#83 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABEnp6WceHNw829x8bSdgZ-AgP1qnt75ks5ujP8pgaJpZM4XJpGK> .

[manics]

Looks like the unit tests are failing: #87

  File "/home/travis/build/korfuri/django-prometheus/django_prometheus/testutils.py", line 48, in getMetricFromFrozenRegistry
    for n, l, value in metric.samples:
ValueError: too many values to unpack (expected 3)

I think this is the relevant PR: prometheus/client_python#300
I haven't found the actual change, but metric.samples is being used differently e.g. https://github.com/prometheus/client_python/pull/300/files#diff-52e98fdb8931e88f7d37feb48ba6ded2L51

[NightTsarina]

Hi!

Any news on this?

I am one of the Debian maintainers for this package and it currently risks being excluded from the next release because currently it fails to build. I am tempted to patch the package as per #88, but that is lacking the changes requested in #84. I could implement those, but I would not like to end up with different metrics names than the ones you end up with! (For example, following that change, I'd also remove _total_ from other metric names...

[bz2]

I suggest this should be fixed by pinning the prometheus_client version to <0.4.0 now, then releasing a new large version bump with updated metric names and so on matching the new scheme that is >=0.4.0

[NightTsarina]

@bz2 Any ETA on that new release? Right now the situation (in Debian) is that prometheus_client is at 0.5.0, and that this package fails to build (normally, we don't keep old libraries around). I would like to patch it so it can be included in the next stable release, but the deadline for that is in a couple of weeks.

[bz2]

@TheTincho I'd happy do the work in time for buster freeze, but don't have the ability to make a release. I have poked @korfuri by email to see if he wants help with maintaining this package.

Also checked the mysqlclient-python that needed fixing as well, but isn't a dep in the Debian packaging, and doesn't have that updated fork packaged anyway yet?

[NightTsarina]

@bz2 I would be happy to work with an unreleased patch. Ideally, the metric names would stay the same in the release later, so users don't get their timeseries screwed up in the next update, but even if we don't get that it would be better than no package.

I don't know what's the story with the mysqlclient library.. It indeed is not a dependency now, would it be in the next release?

[manics]

I think MySQL is an optional dependency: https://github.com/korfuri/django-prometheus#monitoring-your-databases

[bz2]

@TheTincho Doesn't need to be a debian binary dependency - is a driver that provides for django.db.backends.mysql, and is needed for running the end to end tests (which I guess are not plugged in to dep8).