Using VS code Mojo plugin with pixi virtual environment

Mojo VS Code Extension
1

Hello.
Can anyone explain how to configure VS code plugin for work with pixi virtual environment ?
As far as I understand at the moment, this is the only supported plugin for Mojo (pycharm version do not develop).

I have installed mojo as per the instructions using pixi, since it is a recommended option and only seems to contain all the necessary component. And now I want to use the created pixi virtual environment in VS code. But instead VS code downloads another old copy of mojo witch magic.

The extension description says that i must use MODULAR_HOME witch ā€œ/absolute/path/to/. modularā€, but there is no . modular folder. I havenā€™t found any explanation in the documentation or on the internet.

Can anyone describe in detail where and how to specify the correct path?

Path for my project looks like this: /home/user/IdeaProjects/Pycharm/mojo-pixi-project/

If i need additional changes for bash, zsh, fish please let me know too.

I use Arch Linux if it matters.
Thanks.

2

I got the direnv extension to work! I My.envrc file has the following content:

watch_file pixi.lock 
eval "$(pixi shell-hook)"
3

Well, now the console in VS code really allows me to work with a new version of mojo , but when trying to run a file from VS code I get an error message even if I want to run hello world.
VS code still trying to use mojo installed elsewhere. And if VS code canā€™t find it by the standard route, download it again. Should I do something else?

3
31595Ɨ1000 108 KB

trying to install the nightly version of the plugin causes VS code to download another copy of the mojo through magic, which also does not work

4

Currently, the VS Code nightly and stable extensions use an internal copy of Magic to download the Conda packages for the latest nightly and stable release of MAX, respectively. This is unfortunately independent of the version of Mojo / MAX used in your Pixi environment or Python virtual environment. If youā€™re using the latest nightly / stable release in your environment, you wonā€™t notice much of a difference in what VS Code reports, but these two can diverge if youā€™re using different pinned versions in your environment.

Weā€™re planning a revamp of the VS Code extension to allow for better interactions with virtual environments and more, but I canā€™t promise a timeline on that.

5

Okay, Iā€™ll wait for it to happen. I understand correctly that there is currently no IDE, which works properly with Mojo in pixi or uv virtual environment ? For me it is strange that the installation instruction suggests creating a virtual environment, which cannot be used in the IDE.
Can you tell how to change the location where the mojo copy will be downloaded ? I donā€™t want to keep 1.5 Gb in this path /home/name/. config/Code/User/globalStorage/modular-mojotools.vscode-mojo/magic-data-home/ Or ask VS code donā€™t download it in principle, so as not to waste space on disk?

6

Not sure if it helps with your case, but I use VSCode with:

pixi shell
code

which opens it in pixi virtual environment. Itā€™s not ideal, but good enough for a newbie to kick Mojo tires.

7

Hello, I really like Mojo and everything youā€™re trying to do, but the experience with the VS Code Mojo extension is really unpleasant, and Iā€™m not sure whether Iā€™m just missing something that Iā€™m supposed to be doing, or itā€™s just really like this. Iā€™m working on a recent Mac OS computer running VS Code and using the Mojo (nightly) extension and using Pixi to install the nightly Mojo, all as explained in the (excellent) tutorials. I have three comments about the VS Code extension:

  1. The Nightly extension documentation says in the Getting Started section to first ā€œInstall the Mojo SDKā€. I believe that must be superseded by a workflow that uses Pixi, because Iā€™m unable to find any way to install the Mojo SDK. If so, the documentation should be updated.
  2. When I use the extension, it crashes a lot, and I have to restart it often.
  3. The most annoying problem is that the extension gets confused about file imports. For example, if you go to the modular repo, and then go to examples/mojo/life, and start VS Code from there, and then look at the file test/test_gridv1.mojo, youā€™ll get a PROBLEM: ā€œUnable to locate module ā€˜gridv1ā€™.ā€ You can successfully say pixi run test so thereā€™s no actual problem with the code, itā€™s just that the extension is confused. It doesnā€™t matter if you run pixi shell before starting VS code. The only way I could find to solve the problem was to move test files up into the same directory as the other .mojo files that they are importing. That works, but in the long run, I want to be able to put my mojo files into a file structure that make sense without the extension reporting problems that donā€™t really exist.

I saw the same kinds of problems using Cursor instead of VS Code. Am I doing something wrong, or is the VS Code extension just broken?

8

Sorry about the rough time with the current VS Code extension. The good news is that weā€™re getting close to releasing a new extension that unifies the nightly and stable extensions and should solve some of these issues.

The README on the old extension definitely was out of date, and weā€™ve made sure to fix that in the new one. The new extension will use the Mojo LSP from the active project environment, whether thatā€™s in Pixi or a Python virtual environment. I canā€™t confirm that itā€™ll solve all issues with relative imports, but Iā€™m hoping itā€™ll do a much better job with those.

Crashes are often not due to the VS Code extension, but the Mojo LSP itself. We know that there have been some frequent crashes in that recently, and are working to patch those independently of the new extension. If you have consistent reproducer for those on the latest nightlies, please feel free to file a GitHub issue because those can often help us run down problematic cases.

1 Like
9

Thanks for the update about the VS Code extension and the Mojo LSP.

I thought Iā€™d share one thing that I understand now that makes my life better, in case other people had the same issue.

I wanted to be able to put the source code for a module in one place in my repo and be able to import that module from some other arbitrary place in my repo. I think thatā€™s an important thing to be able to do in general, and I figured Iā€™d copy the patterns in the modular repo, in the examples/mojo/ directory. But the patterns used in those examples make the Mojo LSP unhappy as I described in my previous post.

What does works fine is to build a compiled .mojopkg file as described in Modules and packages | Modular , and copy it into the same directory as the files that need to import the module. Then the Mojo LSP is happy, and Iā€™m happy.

10

I woke up this morning to find that the latest nightly version of the VS Code extension complained about my working code, now saying that it could not ā€œmaterializeā€ the module that I had compiled into a .mojopkg files. It was still also complaining about imports in the modular/examples/mojo/life/test files. And it was now also complaining about non-existent indentation problems in one of my .mojo files.

Fortunately, I could pin my version of mojo to 25.6.0.dev2025082105 and my version of the VS Code extension to 2025.8.2105 and the Mojo LSP went back to being OK with my code.

I look forward to the next stable version of Mojo and the VS Code extension, and seeing whether everything is sorted out with the Mojo LSP then!