Update installation instructions for the new conda-forge packages and other changes in our packaging infra

docs/developers/packaging.md

@@ -100,7 +100,7 @@ company: Napari
 license: EULA.md
 channels:
   # - local  # only in certain situations, like nightly installers where we build napari locally
-  - napari/label/bundle_tools_2  # temporary location of our forks of the constructor stack
+  - napari/label/bundle_tools_3  # temporary location of our forks of the constructor stack
   - conda-forge
 specs: # specs for the 'base'  environment
   - python   # pinned to the version of the running interpreter, configured in the CI
@@ -110,9 +110,10 @@ specs: # specs for the 'base'  environment
 extra_envs:
   napari-1.2.3: # this is the environment that will actually contain the napari packages
     specs:
-      - napari=1.2.3=*pyside*
+      - napari=1.2.3
       - napari-menu=1.2.3
       - python   # pinned to a specific version, configured by CI
+      - pyside2  # pinned to a specific version, configured by CI
       - conda    # needed for the plugin manager
       - mamba    # needed for the plugin manager
       - pip      # needed for the plugin manager
@@ -144,11 +145,11 @@ signing_certificate: certificate.pfx  # path to signing certificate
 
 The main OS-agnostic keys are:
 
-* `channels`: where the packages will be downloaded from.
-  We mainly rely on `conda-forge` for this, where `napari` is published.
-  However, we also have `napari/label/bundle_tools_2`, where we store our `constructor` stack forks (more on this later).
-  In nightly installers, we locally build our own development packages for `conda`, without resorting to `conda-forge`.
-  To make use of those (which are eventually published to `napari/label/nightly`),
+* `channels`: where the packages will be downloaded from. 
+  We mainly rely on `conda-forge` for this, where `napari` is published. 
+  However, we also have `napari/label/bundle_tools_3`, where we store our `constructor` stack forks (more on this later). 
+  In nightly installers, we locally build our own development packages for `conda`, without resorting to `conda-forge`. 
+  To make use of those (which are eventually published to `napari/label/nightly`), 
   we unpack the GitHub Actions artifact in a specific location that `constructor` recognizes as a _local_ channel once indexed.
 * {{ '`extra_envs> napari-NAPARI_VER`'.replace('NAPARI_VER', napari_version) }}: the environment that will actually contain the napari installation.
   In this key, you will find `specs`, which lists the conda packages to be installed in that environment.
@@ -255,13 +256,13 @@ Very fun! So where do all these packages live?
 | `constructor`      | [jaimergp/constructor @ `menuinst-cep`][9]      | [jaimergp-forge/constructor-feedstock][12]         |
 | `conda-standalone` | _Same as feedstock_.                            | [conda-forge/conda-standalone-feedstock PR#21][13] |
 | `conda`            | [jaimergp/conda @ `cep-menuinst`][10]           | [jaimergp-forge/conda-feedstock][14]               |
-| `menuinst`         | [jaimergp/menuinst @ `cep`][11]                 | [jaimergp-forge/menuinst-feedstock][15]            |
+| `menuinst`         | [conda/menuinst @ `cep-devel`][11]                 | [jaimergp-forge/menuinst-feedstock][15]            |
 
 
 Most of the forks live in `jaimergp`'s account, under a non-default branch. They are published
-through the `jaimergp-forge` every time a commit to `master` is made. Versions are arbitrary here,
-but they are set to be greater than the latest official version, and the `build` number is
-incremented for every rebuild.
+through the `jaimergp-forge` every time a commit to `main` (`master` in some repos) is made.
+Versions are arbitrary here, but they are set to be greater than the latest official version, and
+the `build` number is incremented for every rebuild.
 
 The only exception is `conda-standalone`. It doesn't have its own repository or fork because it's
 basically a repackaged `conda` with some patches. Those patches live in the feedstock only. The
@@ -283,11 +284,10 @@ a high-level list of the main changes introduced in the stack.
 * Maintain backwards compatibility with Windows
 * Simplify API
 * Remove CLI
-* Provide binary launchers for better compatibility with the macOS permissions system
+* Provide binary launchers for better compatibility with the macOS permissions and events system
 
 ##### Changes in `conda`
 
-* Add API support for menuinst v2
 * Enable code paths for non-Windows Platforms
 * Fix shortcut removal logic
 * Add `--shortcuts-only` flag to support `menu_packages` constructor key natively
@@ -318,7 +318,7 @@ a high-level list of the main changes introduced in the stack.
 [8]: https://conda-forge.org/docs/maintainer/updating_pkgs.html#rerendering-feedstocks
 [9]: https://github.com/jaimergp/constructor/tree/menuinst-cep
 [10]: https://github.com/jaimergp/conda/tree/cep-menuinst
-[11]: https://github.com/jaimergp/menuinst/tree/cep
+[11]: https://github.com/conda/menuinst/tree/cep-devel
 [12]: https://github.com/jaimergp-forge/constructor-feedstock
 [13]: https://github.com/conda-forge/conda-standalone-feedstock
 [14]: https://github.com/jaimergp-forge/conda-feedstock

docs/tutorials/fundamentals/installation.md

@@ -98,7 +98,7 @@ conda-forge channel. We also recommend this path for users of arm64 macOS machin
 (Apple Silicon, meaning a processor with a name like "M1"). You can install it with:
 
 ```sh
-conda install -c conda-forge napari
+conda install -c conda-forge napari pyqt
 ```
 
 You can then upgrade to a new version of napari using:
@@ -110,7 +110,7 @@ conda update napari
 If you want to install napari with PySide2 as the backend you need to install it using
 
 ```sh
-conda install -c conda-forge "napari=*=*pyside2"
+conda install -c conda-forge napari pyside2
 ```
 ````