py312 requirement

[kylejcaron]

It seems like due to docstub, arviz-base is constrained to python >= 3.12

Should this dependency be reconsidered to allow earlier versions of python? Or maybe work with the docstub developer to make it backwards compatible with earlier python versions? I opened up an issue in docstub for now scientific-python/docstub#73

[aloctavodia]

Hi!

We try to follow https://scientific-python.org/specs/spec-0000 I say "try" because it's not strictly enforced but it's used as guide. According to that we should drop 3.11 by the time we release the stable version of arviz-base (and the rest of the arvizverse). Still I would like to know how important is to you @kylejcaron to be able to work with Python < 3.12.

[OriolAbril]

It might be worth noting that the constraint is only for running the tox check job (and consequently pre-commit), not the package itself, testing or building docs. It might be possible to handle this gracefully with tox directly but not sure it is worth the extra effort

[kylejcaron]

It might be worth noting that the constraint is only for running the tox check job (and consequently pre-commit), not the package itself, testing or building docs. It might be possible to handle this gracefully with tox directly but not sure it is worth the extra effort

Thats a fair point, it would really only impact developers who can just work on >=py312

Hi!

We try to follow https://scientific-python.org/specs/spec-0000 I say "try" because it's not strictly enforced but it's used as guide. According to that we should drop 3.11 by the time we release the stable version of arviz-base (and the rest of the arvizverse). Still I would like to know how important is to you @kylejcaron to be able to work with Python < 3.12.

For the package requirements, I'd appreciate backwards compatibility since many industry projects tend to have complicted and outdated dependencies, but to @OriolAbril's point I was conflating the tox checks in the development process with the actual package requirements themselves - so overall I think this is fine thanks for your responses!

As a heads up I did decide to send a PR to docstub to allow some backwards compatibility to >= 3.10 - could always choose to integrate that with tox if the PR gets approved, but I think its not entirely necessary now

[OriolAbril]

I think "long(er) term support" is something we can add to the roadmap whenever we get to updating it, if something like that manages to attract some funding it would be great. As of now, while I would also prefer having more backwards compatibilities guarantees the extra maintenance required for that means we have to cut on new features or somewhere else (we are already quite stretched and in general not covering everything we'd like to cover).

In general I don't think is is sensible to expect to use the latest ArviZ while using very old python/numpy/scipy versions (or vice versa). And what we do guarantee is full backwards compatibility of serialized InferenceData objects (I don't think we have ever done a breaking change on that end, it is not recommended but still valid to have a log likelihood variable in the sample stats group instead of a log likelihood group). It is not ideal but always possible to save a netcdf/zarr file using 0.5 ArviZ then load it with the development version of arviz-base and use bleeding edge new features like plot_rootogram

[kylejcaron]

I think "long(er) term support" is something we can add to the roadmap whenever we get to updating it, if something like that manages to attract some funding it would be great. As of now, while I would also prefer having more backwards compatibilities guarantees the extra maintenance required for that means we have to cut on new features or somewhere else (we are already quite stretched and in general not covering everything we'd like to cover).

In general I don't think is is sensible to expect to use the latest ArviZ while using very old python/numpy/scipy versions (or vice versa). And what we do guarantee is full backwards compatibility of serialized InferenceData objects (I don't think we have ever done a breaking change on that end, it is not recommended but still valid to have a log likelihood variable in the sample stats group instead of a log likelihood group). It is not ideal but always possible to save a netcdf/zarr file using 0.5 ArviZ then load it with the development version of arviz-base and use bleeding edge new features like plot_rootogram

Makes sense thanks for walking me through this!