Context

I have a desire as an end user, to specify the build rather than the environment that a notebook or script uses.

One possible workflow for this (though there are others):

1. I have a notebook that uses a conda-store environment. As an end user, I have no visibility into which build is loaded in my notebook.
2. Over time, I rebuild the environment several times, the latest build becomes the "active" build.
3. Notebooks still points to previous build from step 1, but I want to use the updated env.
4. Load a different env in the notebook
5. Load the original environment (effectively switching to the "active" build)
6. Realize that my notebook no longer works and decide to rollback.
7. Attempt to recall the date of the build that worked for the notebook and make it the "active" build.
8. Repeat steps 4-7 until I figure out the build that worked.

Rolling back to different builds of environments is "easy" in conda-store but the practical usage of it in Jupyter Notebooks (or python scripts) is less clear. It is handy to just say "this runs in this environment" and let conda-store handle which environment is active. But in reality, its often really useful to say "run this in this environment build" which is much more explicit. And if not that, then just make it easier for me to know which build I'm currently using.

I believe there are symlinks which are obfuscating the environment name from the build hash. I'm wondering if its possible for me as an end user to point to the build hash itself?

Or maybe we could add a symlink that adds part of the build hash to the env name? The same hash could be shown in the conda-store UI for easy visibility and cross reference. That would cause a LOT of noise so I'm sure that would take some effort to control.

Value and/or benefit

Improved practical usage of conda-store

Anything else?

No response