Describe the bug
The ArviZ metapackage currently checks compatibility between arviz_base, arviz_stats, and arviz_plots by constructing a formatted status string and then parsing that string with a regular expression.
In src/arviz/init.py, the compatibility check currently uses:
python
pat = re.compile(r"arviz_(base|stats|plots)\s([0-9]+.[0-9]+)")
matches = pat.findall(info)
versions = dict(pat.findall(info))
unique_versions = set(versions.values())
The check therefore depends on the formatting of the generated status messages rather than directly inspecting the version metadata of the three packages.
This works with the current version format, but it makes the compatibility logic tightly coupled to an intermediate human-readable string. Changes to that formatting could unintentionally break the compatibility check.
Furthermore, there is no explicit handling of how version metadata containing pre-release or other PEP-440 version information should be treated by this compatibility check (the regex implicitly discards everything after major.minor).
I think the compatibility check would be more robust if it operated directly on the installed package versions rather than parsing the formatted status output.
Expected behaviour
The compatibility check should determine whether arviz_base, arviz_stats, and arviz_plots satisfy ArviZ's intended version-compatibility policy using their version metadata directly.
The existing requirement that the ArviZ subpackages share the same minor-version line should be preserved.
The implementation should also make the intended behaviour for edge-case versions (such as release candidates or pre-releases) explicit, rather than relying on the regular expression to implicitly discard them.
Steps to reproduce
Steps to reproduce
Note: This is an implementation robustness issue rather than a currently demonstrated runtime failure.
The behaviour can be inspected in src/arviz/init.py, where the versions of arviz_base, arviz_stats, and arviz_plots are first inserted into formatted status strings and are subsequently extracted using:
python
pat = re.compile(r"arviz_(base|stats|plots)\s([0-9]+.[0-9]+)")
The extracted major.minor values are then compared. A concrete user-facing failure would only occur if there is a change in the status-string formatting or a version format that is not represented correctly by the current regular expression.
Additional context
Current main defines the ArviZ metapackage version as 1.3.0 and correctly declares the constraints in pyproject.toml:
arviz_base>=1.3.0,<1.4.0
arviz_stats[xarray]>=1.3.0,<1.4.0
arviz_plots>=1.3.0,<1.4.0
I am not proposing a specific implementation (e.g., using packaging.version) at this stage because the desired semantics for pre-release versions should be clarified first. However, a direct version-metadata comparison using an appropriate PEP-440-aware mechanism may be a more robust direction.
If the maintainers agree that this is worth addressing, I would be happy to investigate the existing tests and submit a PR for this refactor
Additional context
No response
Describe the bug
The ArviZ metapackage currently checks compatibility between arviz_base, arviz_stats, and arviz_plots by constructing a formatted status string and then parsing that string with a regular expression.
In src/arviz/init.py, the compatibility check currently uses:
python
pat = re.compile(r"arviz_(base|stats|plots)\s([0-9]+.[0-9]+)")
matches = pat.findall(info)
versions = dict(pat.findall(info))
unique_versions = set(versions.values())
The check therefore depends on the formatting of the generated status messages rather than directly inspecting the version metadata of the three packages.
This works with the current version format, but it makes the compatibility logic tightly coupled to an intermediate human-readable string. Changes to that formatting could unintentionally break the compatibility check.
Furthermore, there is no explicit handling of how version metadata containing pre-release or other PEP-440 version information should be treated by this compatibility check (the regex implicitly discards everything after major.minor).
I think the compatibility check would be more robust if it operated directly on the installed package versions rather than parsing the formatted status output.
Expected behaviour
The compatibility check should determine whether arviz_base, arviz_stats, and arviz_plots satisfy ArviZ's intended version-compatibility policy using their version metadata directly.
The existing requirement that the ArviZ subpackages share the same minor-version line should be preserved.
The implementation should also make the intended behaviour for edge-case versions (such as release candidates or pre-releases) explicit, rather than relying on the regular expression to implicitly discard them.
Steps to reproduce
Steps to reproduce
Note: This is an implementation robustness issue rather than a currently demonstrated runtime failure.
The behaviour can be inspected in src/arviz/init.py, where the versions of arviz_base, arviz_stats, and arviz_plots are first inserted into formatted status strings and are subsequently extracted using:
python
pat = re.compile(r"arviz_(base|stats|plots)\s([0-9]+.[0-9]+)")
The extracted major.minor values are then compared. A concrete user-facing failure would only occur if there is a change in the status-string formatting or a version format that is not represented correctly by the current regular expression.
Additional context
Current main defines the ArviZ metapackage version as 1.3.0 and correctly declares the constraints in pyproject.toml:
arviz_base>=1.3.0,<1.4.0
arviz_stats[xarray]>=1.3.0,<1.4.0
arviz_plots>=1.3.0,<1.4.0
I am not proposing a specific implementation (e.g., using packaging.version) at this stage because the desired semantics for pre-release versions should be clarified first. However, a direct version-metadata comparison using an appropriate PEP-440-aware mechanism may be a more robust direction.
If the maintainers agree that this is worth addressing, I would be happy to investigate the existing tests and submit a PR for this refactor
Additional context
No response