GSoC 2026: Clarification on linting tools (ruff/pylint) and coverage expectations

[Sakshee-D]

Hi, I was looking at the linting setup across repositories and had a few questions.

• In arviz-base, ruff is used via pre-commit, but a .pylintrc file is still present and it looks like pylint isnt activly used.
• In arviz-stats, there are all of these tools (ruff, pylint, and also absolufy-imports) in `.pre-commit-config.yaml.

So is the intention to gradually standardize with ruff as the primary linting tool? In that case, can we remove absolufy-imports(superseded by ruff )? And whether in that case pylint would still be needed, or if both ruff and pylint are needed in practice?

Also I checked the overall coverage of arviz-base and found that it is around 50%. I wanted to confirm whether this is the current coverage level, or if optional dependencies would affect this number.

Moreover, are there particular modules where increasing coverage would be considered more valuable than others or overall coverage increment is the goal?

[OriolAbril]

The general goal should be to have ruff for all formatting and then both ruff and pylint for linting. We started switching to ruff but realized it misses too many pylint checks that are relevant and useful to us so we stopped but didn't get back to adding it to arviz-base again. absolutify-imports can be removed if ruff takes care of its tasks yes (that is, not only warns when linting but automatically fixes things).

Checking the coverage manually is quite hard for both arviz-base and arviz-stats due to all the different test environments involved. You can check that on codecov instead: https://app.codecov.io/gh/arviz-devs/arviz-base. It is currently 72%

I am not sure what to answer a priori. I think the most important task related to coverage is carefully going through the reports on codecov to see if there are any modules or files with much lower coverage than the others. I would also like to try and take a better look at the hypothesis tests we have for arviz-plots to make sure we are covering all relevant cases. Especially for plots, even if the files have a 100% code coverage, it doesn't mean we are covering all important combinations of input parameters. Tangentially related, the organization of tests files and functions in arviz-stats is also quite a mess; if when going over all this finding where each function is tested turns out to be a challenge it would also be a signal we need to think about their organization.

[Sakshee-D]

Thanks for the detailed clarification, this helps a lot.

[Sakshee-D]

I wanted to confirm the expected scope for docstring standardization and typing.
Is it preferred to focus first on public APIs and core modules, and then expand to internal functions if time permits. For mypy, as it depends on type hints,we can start with these modules rather than full coverage across all functions . Is this the expected approach ?

Also,I reviewed the CI workflow in arviz-stats and noticed that linting is run via a separate lint.yml, while the same checks are also available through the check tox environment. Can we add the check environment to the gh-actions so that all checks are done through tox, similar to arviz-base and plots.
Would you prefer consolidating linting into tox, or keeping a separate workflow for clarity?

[OriolAbril]

Is it preferred to focus first on public APIs and core modules, and then expand to internal functions if time permits. For mypy, as it depends on type hints,we can start with these modules rather than full coverage across all functions . Is this the expected approach ?

I am not sure how useful mypy will be if only part of the codebase has type hints but if it can already run with some ignores then I think that sounds good yes. Moreover, depending on the type of private function we can also consider adding type hints directly instead of a full proper docstring to it if it is shortish and somewhat easy to read.

Also,I reviewed the CI workflow in arviz-stats and noticed that linting is run via a separate lint.yml, while the same checks are also available through the check tox environment. Can we add the check environment to the gh-actions so that all checks are done through tox, similar to arviz-base and plots.
Would you prefer consolidating linting into tox, or keeping a separate workflow for clarity?

lint.yml is running tox -e check if you look at it. We only want to run the check job for tox once, not in every CI job so we externalized it. I don't think it is an issue because it is a simple workflow that is easy to understand and maintain. The testing job has a more complicated matrix structure to run all the tox jobs with the different subsets of optional dependencies for all requested python versions so trying to add the exception that only one of those also runs the check job is will probably give more problems than what it solves.

[Sakshee-D]

Hi, I have prepared a draft of my GSoC proposal and I wanted to get your feedback before finalizing it.

Proposal (comments enabled):
Sakshee_Dhormale_GSoC2026_Proposal

I would really appreciate any suggestions, especially on timeline, and technical approach.