Update contributing docs for [dev] install change needing Qt backend install

[psobolewskiPhD]

Description

This PR updates the contribution docs for the changes to the installation pattern to remove [all] from [dev]. This means that doing a pip install -e .[dev] will no longer install a Qt backend (currently pyqt5). As a result, a Qt backend needs to be installed along side [dev] or be pre-existing. The goal is to make it easier for people to test other Qt backends than pyqt5 or when using platforms that don't have pyqt5 wheels on pypi (e.g. macOS arm64).

Type of change

• Fixes or improves existing content
• Adds new content page(s)
• Fixes or improves workflow, documentation build or deployment

References

This is needed in pair with napari PR: napari/napari#5438

Final checklist:

• My PR is the minimum possible work for the desired functionality
• I have commented my code, particularly in hard-to-understand areas
• I have added alt text to new images included in this PR

[psobolewskiPhD]

Here's what the new docs page looks like:

[melissawm]

Hi @psobolewskiPhD , this looks great to me. Just wondering if we can integrate with #72 as well? Or maybe scrap that if it's not useful. Thanks!

[psobolewskiPhD]

Ah, I forgot about that one. This specific PR is to account for the napari/napari PR changing [dev]—which may not be merged, I'm not sure what the consensus is.
I'll take a look at #72 — it may be best to get that merged and then update for the change to [dev] proposed here if needed due to the napari/napari PR.

[jni]

I might be confusing my bash syntax here, but I think if you put a space in the list of packages ([pyqt, dev]), then the quotes are needed for any shell, not just zsh. If you don't put a space ([pyqt,dev]), then you can omit the quotes in bash. So, I would either remove the comment or the space.

[jni]

I don't really understand the plan here... Are we merging #72 and then this one, the reverse, or cherry-picking the changes of one PR into the other? Either way I'm ok with this being merged soon, and happy to pull the simul-trigger on napari/napari#5438 and here!

[psobolewskiPhD]

I don't have an opinion on the merging.
For #72 I'm not a fan of the shields for python version and would prefer using the python version substitution from #84
Regardless of merge order I think the conflicts will be minor and easy to resolve.