This is mostly for speed and image size. The mamba env update command is used as often folk only need to specify a few packages, and get them installed into the default env, running with most of the jupyter stack ready to go on python3.7. The default stance leaves less of a delta on disk, even if some packages are out-of-date.
Your specific environment.yml has a lot of tight pins, and a lot of channels, including the dreaded conda-forge/labels/broken. The jupyter metapackage is also rather troublesome, and you should drop that if you can, as qt doesn’t buy you much on binder without a lot of other tricks.
You could sacrifice speed and cache-ability by forcing more behavior with a renamed environment-foo.yml and a postBuild, e.g.
For binder, you’d need to ensure you had the jupyterhub-singleuser package installed.
this will generate a lockfile that you can check in and use with any conda or mamba install, and get exactly the packages you want, and install with the same mamba create technique above.
The jupyter metapackage is there since we intend to use the same environment to execute the code both locally and on binder (and being consistent across). Reading https://jupyter.org/install I also tried jupyterlab but qt is also installed with it. Any other suggestion?
I just played a bit with conda-lock but it wasn’t a great experience, and I couldn’t get it to work properly. Not sure if I will use this at the moment.
I have also played a bit with the postBuild, adding:
There are any number of packages that will pull it: jupyter is just a likely candidate due to qtconsole. Another candidate is matplotlib, vs matplotlib-base.
Really, unless your desktop work actively uses qt-based UIs, it’s worth trying to avoid the 200mb and rather arcane pins it sometimes forces.