Better reproducibility wrapping Python ArviZ

[sethaxen]

One of the ways the Julia ecosystem achieves reproducibility even with binary dependencies is by defining glue packages that wrap the binaries and are tagged for specific versions. e.g. https://github.com/JuliaBinaryWrappers/wget_jll.jl. This way Julia packages can specify exact supported versions for these dependencies.

I'm considering doing something like that here until #130 is completely resolved. Specifically, we would create an ArviZ_py.jl (or PyArviZ) package that only depends on PyCall. v0.12.0 of the package would install v0.12.0 of the ArviZ Python package upon loading, and upon start-up it would check that the exact Python ArviZ version is installed and otherwise prompt the user to update (what we currently do in this package). When a new Python ArviZ release is made, a new release is tagged there, and then we only update our compat here when we fully support that version (and drop compat for versions we don't support). As an added bonus, we maybe could ensure that on the main branch, the main branch of Python ArviZ is always installed, so testing Julia ArviZ against future releases of Python ArviZ would be as easy as

] add ArviZ, ArviZ_py#main

Since Python ArviZ releases are relatively rare, this would not be much of an additional maintenance burden, and it would let us be at least more reproducible than we currently are.

[sethaxen]

Apparently PythonCall allows for providing a TOML file for dependencies to ensure reproducibility, so that's an alternative. I'm not certain how well PyPlot will work without PyPlot.jl, which uses PyCall not PythonCall.

[devmotion]

PythonPlot is the PythonCall version of PyPlot: https://github.com/stevengj/PythonPlot.jl I've never used it, so I can't comment on the differences.

[sethaxen]

I spent some time replacing PyCall with PythonCall, but it turns out to require quite a lot of surgery. PythonCall by default does no conversions between Python and Julia, and we extensively rely on PyCall's automated conversions, so it would require quite some code for ArviZ to "just work" with PythonCall the way it does with PyCall. Plus, every time one installs ArviZ, a new Conda environment is created. Already-downloaded conda packages are not reused, so package installation becomes much slower and internet-bound.

I've opted for #234 to hopefully resolve our major dependency issues, and the time that would go toward using PythonCall will instead go toward removing Python as a dependency.

[sethaxen]

With #290, we no longer use Python