Displayed inference library version is wrong in InferenceData from PyMC3

[rpgoldman]

Describe the bug

I was running PyMC3 version 3.9.1, and returned an InferenceData object from pymc3.sample(). The resulting InferenceData shows this:

>>> tr.posterior
<xarray.Dataset>
Dimensions:   (chain: 2, draw: 1000, features: 5)
Coordinates:
  * chain     (chain) int64 0 1
  * draw      (draw) int64 0 1 2 3 4 5 6 7 8 ... 992 993 994 995 996 997 998 999
  * features  (features) int64 0 1 2 3 4
Data variables:
    a         (chain, draw, features) float64 96.61 44.09 26.66 ... 78.56 -55.58
    b         (chain, draw, features) float64 -85.38 94.78 45.37 ... 29.86 7.584
Attributes:
    created_at:                 2020-06-21T20:22:46.159824
    arviz_version:              0.8.3
    inference_library:          pymc3
    inference_library_version:  3.8
    sampling_time:              2.887521743774414
    tuning_steps:               1000

But that is not the PyMC3 version reported by PyMC3:

>>> pm.__version__
'3.9.1'

To Reproduce

I ran this script (trying to replicate an issue in PyMC3):

import pymc3 as pm
import numpy as np

chains = 2
n_features = 5
n_samples = 1000

coords = {"features": np.arange(n_features)}

with pm.Model(coords=coords):
    a = pm.Uniform("a", -100, 100, dims="features")
    b = pm.Uniform("b", -100, 100, dims="features")
    tr = pm.sample(n_samples, chains=chains, return_inferencedata=True)

Expected behavior

Two reported versions of PyMC3 version should agree.

Additional context

ArviZ from git at 7cec6dd and PyMC3 from git at 66cd2163039b3c2f76420357ee801d7ec351c4fc

[michaelosthege]

I observe the same problem after installing with pip install -e.
It looks like pip thinks version 3.8 is installed. No idea why though.

[OriolAbril]

Looks like here is where things go wrong: https://github.com/arviz-devs/arviz/blob/master/arviz/data/base.py#L227 no idea why though, just leaving this here im case it could help

[rpgoldman]

Another possible issue, I see this error from mypy in sampling:

v = packaging.version.parse(pm.__version__)

According to mypy, packaging is a Module, and has no version property, and it suggests I change it to __version__. This might be a false positive, but I mention it for what it is worth.

[michaelosthege]

Another possible issue, I see this error from mypy in sampling:
v = packaging.version.parse(pm.version)

According to mypy, packaging is a Module, and has no version property, and it suggests I change it to version. This might be a false positive, but I mention it for what it is worth.

packaging.version is created upon import. VS code is also confused by this.

To solve this issue however, the question is: Should/can we fix the problem of pip not recognizing the version correctly? Or should ArviZ just use the __version__ attribute if available?

[OriolAbril]

ArviZ uses __version__ if pkg_resources.get_distribution errors out, I guess we could invert the behaviour to check for __version__ first, but something feels fishy 🤷

[michaelosthege]

ArviZ uses version if pkg_resources.get_distribution errors out, I guess we could invert the behaviour to check for version first, but something feels fishy 🤷

The __version__ attribute is the ultimate source of truth, right?

I can't reliably reproduce the fishyness of incorrect pip version reports. Maybe it's just a rare issue, specific to Robert and me?

[OriolAbril]

not sure if this has happened again, so I'll close for now given there doesn't seem to be other reports of this either