Move development dependencies into a dependency group (no more extra)

[hoechenberger]

That way, the built distributions won't expose these optional dependencies anymore.

This is supported in pip since version 25.2 (released end of July).

FYI I originally placed the dependency-groups section in pyproject.toml below the extras, but one of our pre-commit hooks moved it up, right below the build system specs.

[drammock]

I realize this is a draft PR, so you may already know / be planning this, but FWIW you'll at least need to touch tools/circleci_dependencies.sh as we do there something like pip install -e .[test,doc,dev] or so

[hoechenberger]

you'll at least need to touch tools/circleci_dependencies.sh as we do there something like pip install -e .[test,doc,dev] or so

pip seems to treat extras and dependency groups the same when invoked like this, so there's no need to change those commands for now :) At least that's my understanding. Let's see how the tests come back

[hoechenberger]

I realize this is a draft PR

No worries, all feedback is welcome ;)

[drammock]

pip seems to treat extras and dependency groups the same when invoked like this, so there's no need to change those commands for now :) At least that's my understanding. Let's see how the tests come back

I though it was pip install --group dev -e . or so 🤔

(also if such changes are needed, then tools/azure_dependencies.sh will probably also need attention)

[drammock]

regardless, thanks for working on this! I've been wishing someone had the time to work on it

[hoechenberger]

I though it was pip install --group dev -e . or so 🤔

Me too, then I tested it, it seemed to work without --group; now I checked again and it seems I tested with a contaminated venv. It does, in fact, not work – just as you correctly assumed.

I'm wondering if it even makes sense to continue here, or if I should rather start working on switching over to uv right away instead. I've been using uv exclusively for all my projects for more than a year now (and also completely ditched conda).

Not sure what the best way forward is now. Any input is welcome!

[drammock]

I'm wondering if it even makes sense to continue here, or if I should rather start working on switching over to uv right away instead.

uv also supports --group (as well as --all-groups and other variations) so it should be straightforward to do this PR first, and then switch to uv in a subsequent PR. In other words, I don't think doing it all in 1 PR saves much effort. (I'd also like to save the conversion-to-uv as a training exercise for the new maintainers we're currently onboarding, so selfishly I'd prefer if this PR only did the dep groups part)

[hoechenberger]

CI errors are unrelated (NumPy API change, it seems)

This one is ready for review.

[larsoner]

LGTM +1 for merge!

[drammock]

CI errors are unrelated (NumPy API change, it seems)

np.ndarray.ptp -> Use np.ptp(arr, ...) instead.

https://numpy.org/devdocs/numpy_2_0_migration_guide.html#ndarray-and-scalar-methods

[larsoner]

Worked around in recent PR, I'll fix the conflict but it should come back green

[larsoner]

(See python-quantities/python-quantities#262)

[drammock]

... and also python-quantities/python-quantities#263

[drammock]

Great that this is working! Aside from a couple inline remarks below, 2 high-level comments:

1. I think we now need to pin to pip >= 25.1 as a dev dependency, right? (25.1 is when the --group flag was added)
2. Should we do some communication with downstream projects re: this change? If for some reason they were using one of our developer-focused extras in their CIs, and e.g. pip install mne[test] is going to start failing for them at the next release, it seems a bit mean to just spring it on them with no warning. Ideally we would have committed to doing this a while ago and announced it in the prior release's changelog, and then done it now. But since we didn't do that, I think we should at minimum announce this in the upcoming changelog (and tell them what the fix is) so that if they do need to change their CI config it will be as painless as possible.

[drammock]

what do people think about making dev group depend on test_extra instead of just test? That way, dev will include everything needed to run all tests (without test_extra some tests will get skipped)

Suggested change

	dev = ["rcssmin", {include-group = "doc"}, {include-group = "test"}]
	dev = ["rcssmin", {include-group = "doc"}, {include-group = "test_extra"}]

[hoechenberger]

Disk space is cheap and plenty, so why not :)

[drammock]

@larsoner can you make this change too while you're at it? (or just push the "commit suggestion" button)

[drammock]

I know it's legal to put these flags at the end of the command, but it seems to me a bit nicer to put them adjacent to -ve .[full] (since . is the package they apply to). IDK if it works to do pip install . --group=test package2 package3 (sticking the group flag in between other deps), but if it doesn't maybe we could just move -ve .[full] to the end (after curryreader)?

[hoechenberger]

I'm open to anything if you believe it improves readability!

Since we're talking about this particular section of the script: I'm not a fan of having dependencies listed inline like this … any chance we could change that?

[drammock]

Are you suggesting adding another dependency group for these? It seems a bit odd to add a dep group just for ease of CI usage (not sure end users will ever want this set of deps as a whole?) @larsoner WDYT about adding these to a dep group?

They look like the "related community projects" from https://mne.tools/dev/install/mne_tools_suite.html#related-software but it seems some are missing (antio, best-python, cross-domain-saliency-maps, ...) Maybe it's the set of community projects that are in the installer?

[larsoner]

This has more to do with our doc build than anything else (most are just used for the "related software" section) and it's the only place they're used, so circleci_dependencies.sh makes more sense as a place to have them to me than the more general pyproject.toml

[hoechenberger]

I was more thinking along the lines of a requirements.txt

[larsoner]

A doc/related_software.txt could make sense and be nicely scoped / named for its purpose etc., and reduce this to just -r doc/related_software.txt. Feel free to push here if @drammock agrees!

[hoechenberger]

This has more to do with our doc build than anything else (most are just used for the "related software" section) and it's the only place they're used, so circleci_dependencies.sh makes more sense as a place to have them to me than the more general pyproject.toml

Thinking about it, why shouldn't we have dep groups of the kind build-docs or docs-ci? That way, all dependencies for everything we do would be centralized 🤔

[larsoner]

Both approaches "centralize" different ways... depends on whether you want to centralize/prioritize "as many dependency specs as possible should live in pyproject.toml" vs "as much doc-build-related stuff as possible should live in doc/". To me pyproject.toml is most useful/ideal when lists are intended to get reused multiple places, rather than as a host for all possible dependency specs for a project. This particular list is really a one-off related to doc/sphinxext/related_software.py. The most natrual place actually would be for it to live in that .py script if we could pull it off -- there are some relationships between that file and this list -- but then at least doc/ is closer than pyproject.toml from a filesystem/scope sense.

For another example, if we wanted to move as many deps as possible to pyproject.toml, we'd want to add an entry for PyQt5 for our Qt tests in azure-pipelines.yml, and I think that would (also) make it a bit harder to maintain rather than keeping that specific dependency (which is only ever used there, like in the CircleCI case) in azure-pipelines.yml. There are probably other cases like this, too, for other CI-related things in our GHA and/or Azure runs.

[larsoner]

I'll push a quick commit to add the requirements file and fix the conflict then mark for merge-when-green, since this otherwise seems almost good to go

[hoechenberger]

thanks Eric, please feel free to take over and push this over the finish line, I likely won't have time for a bit!

[larsoner]

Should we do some communication with downstream projects re: this change? If for some reason they were using one of our developer-focused extras in their CIs, and e.g. pip install mne[test] is going to start failing for them at the next release, it seems a bit mean to just spring it on them with no warning.

Thinking about this a bit, I am pretty sure mne-* projects just install MNE, then do their own test-related deps. And if they don't, it should be a quick enough fix and mostly dev-facing. So I think an entry in doc/changes/13452.other.rst should be good enough to warn/tell people. I'll add that and you can see if you agree @drammock !

[larsoner]

Okay @drammock should be good to go!

[cbrnr]

Nice, thanks @hoechenberger, @larsoner, and @drammock!