Joshua Bronson

Thank you for the suggestion! I have incorporated it into our `conda-lock install`-based automation and it has been working well. Please consider this a vote of confidence that this approach...

Strange: I picked up an upgrade from libmamba 2.1.0 to 2.1.1 ([released yesterday](https://github.com/mamba-org/mamba/releases/tag/2.1.1)) and it broke this "environment matches lockfile?" logic. From this diff, I think it may be due...

Unfortunately yes. Just tested again with latest libmamba (currently 2.2.0) and same version of conda-lock (2.5.8), and reproduced the behavior where the "environment matches lockfile?" logic no longer works.

Thanks for chiming in with the good idea, happy to see this getting more attention. I thought about something like this too. I'm all for any kind of even more...

Regarding the PyPI vs. conda-forge discrepancy I mentioned above (and repro'd [here](https://github.com/ctcjab/repro-conda-lock-libmamba-issue)), thank you @maresb for suggesting the workaround of using `mamba list` rather than `conda list` -- that did...

Meant to say, text input in notebooks and in text editor tabs is not affected. The severe input lag has only been observed in the integrated terminal thus far.

Thanks @krassowski! Still waiting on https://github.com/conda-forge/jupyter-resource-usage-feedstock/pull/20 to merge, but once it does I can test this more easily and get back to you.

Tested the new 1.2.0 release but unfortunately I'm still seeing this issue -- the behavior still matches the recording I posted in the description.

> in corporate environments, there may be centralized HTTP-based MCP servers available to overcome this. Just confirming that is in fact the case in the corporate environment in which I...

Adding a voila.json with the following config worked around this: ``` { "VoilaConfiguration": { "extension_language_mapping": { ".py": "python" } } } ```