I'm still a little confused about the organization. We havedoc/devel/development_setup.rst anddoc/devel/dependencies.rst. I don't see how those are distinct, and suggest they just get combined and the one removed get a redirect to the one that is kept.

These two serve different purposes.development_setup is aguide how to set up everything for development. Part of this setup is installing additional dependencies. I anticipate that this guide will be extended for setting up via a conda recipe#17096 or docker. Then, manual installation of dependencies is just one way (and maybe not even the preferred one), and it's ok to just link to the dependencies you need.

In contrast, I regarddependencies is as areference. It documents all our dependencies. Some of them are runtime dependencies (which are also linked from the regular installation guide, which in turn does only need them when you want to install them manually, and not via pip/conda etc.). Additional dependencies are needed for development.

Given that we have quite complex dependencies, I find it worthwile documenting them concisely in one central place without cluttering them with installation instructions or similar.

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

$ git checkout v3.4.x$ git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

$ git cherry-pick -m1 93e716de372a8d6e95f999ce60ea8965d1488c4c

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

$ git commit -am 'Backport PR #20011: Move development dependencies to dependencies page'

4. Push to a named branch :

git push YOURFORK v3.4.x:auto-backport-of-pr-20011-on-v3.4.x

5. Create a PR against branch v3.4.x, I would have named this PR:

"Backport PR#20011 on branch v3.4.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free tosuggest an improvement.

I don't quite know what the backport policy is for docs....

Theoretically, doc changes only changing .rst files could go to 3.4-doc (which also implies backporting to the next bugfix release). However sooner or later we miss backporting some changes, so that the automatic backports will fail. In that case I give up and the change only goes to the next minor release. I don't think it's worth fix these kind of backports.