Closed josegcpa closed 1 year ago
Why it's not possible to use the extension? It should work fine when micromamba installed globally. It should not interfere with global installation, download the micromamba executable into .micromamba directory in the root of the project and create an environment also in .micromamba directory and activate environment from there. The idea is to isolate virtual environments in a project scope. Of course this approach needs more disk space, but this is easier for non experienced users and also easy to clean the disk space. Similar to npm storing deps in node_modules directory inside the project root.
I'm going to add a setting to allow reuse of MAMBA_ROOT_PREFIX or to provide a custom path to store environments Then by default extension would work in isolation and you should be able to reuse environments. Wdyt? @josegcpa
I'm going to add a setting to allow reuse of MAMBA_ROOT_PREFIX or to provide a custom path to store environments Then by default extension would work in isolation and you should be able to reuse environments. Wdyt? @josegcpa
I think this is a great idea, that way there can be deviations from the usual .micromamba directory. Thank you!
That would be great. If it could also reuse the pkgs directory we could avoid re-downloading cached packages with each environment setup.
Great extension by the way.
@josegcpa If I may, by changing this setting,
"python.condaPath": "/usr/local/bin/micromamba"
you can get VS Code to use your already existing micromamba installation. The usual GUI will find your Python environment, the first time you run a Jupyter cell, it will ask you to install ipykernel, etc. All because micromamba command-line is a drop-in replacement for the conda command-line afaiu.
Sure you won't be able to manage that micromamba environments from VS Code as this extension does but as for me, I am fine with that. I use that extension for what it was designed for: a fully encapsulated installation per project, which can be useful when sharing a Jupyter notebook with other VS Code users. So @corker I see above that you plan to add the management of user-wise micromamba environments. I am not sure about that actually. I think it may end up being confusing as it would be very easy to misidentify a project environment with a user one.
Indeed, @luc-j-bourhis it's important for me to make it convenient for developers and not mess up user/project environments. My initial thinking is to reuse package cache and create project environments with a unique hash suffix in the environment name. Another option is to add a command to select one of existing micromamba user environments for the project. There are some platform specifics that have to be handled separately on windows and Linux. I'm still thinking it through. It makes sense what you say, please share any thoughts you have. I'd be glad to know.
I also noticed that yarn conflicts with node projects when package type is module (esm) It seems that project environments have to be moved out from the .micromamba dir, and as a python developer it's often more conventional to keep environments inside .micromamba dir.
I added a Global Home Dir mode that allows one global package cache and micromamba executable. I still need to see how to enable the extension to work with existing environments created outside of the extension. I aim to ensure the dev UX for already implemented features is not affected, so I need more time to understand how to do it right. Please look at v0.1.16 and tell me what you think about this approach.
In v0.1.17 there is a command 'activate environment by path'. With this command, it's possible to point to an existing environment created by micromamba outside of vscode-extension. Happy coding!
I was very excited to see that micromamba had a VS code extension but I have a major drawback - I already had micromamba installed in a custom path and all my environments in there, so I cannot use this extension! Is there a way to add some way of configuring this?