Please share any feedback or questions on the installation process in this thread!
Hey Modular forum 
I am having a bit of trouble setting up my local repository environment to install packages. I have magic-cli installed and it populated a magic.lock file to my local repo. When I add max magic add max to install mojo in my folder/repo, I also pop errors and I traced it back to the pixi.toml file. I am running WSL2 in a bash shell on Ubuntu 24.04.1 LTS. I also notice when I initialize a magic shell I pop errors as well.
⠤ docs:linux-aarch64 [00:00:01] [━━━━━━━━━━━━━━━━━━━━] 6.61 MiB @ 4.11 MiB/s downloading repodata ⠁ default:linux-64 [00:00:00] loading repodata × could not find subdir 'noarch' in channel 'https://github.com/modular/modular-community/' ╰─▶ HTTP status client error (404 Not Found) for url (https://github.com/modular/modular-community/noarch/repodata.json)
I added both the prefix.dev and github modular-community url repos just to see what would happen. I also commented/removed out 2 of the platforms as I am only utilizing linux-64 in my setup environment. But I re-added all 3 and still the same.
pixi.toml file:
[project] channels = ["conda-forge", "https://conda.modular.com/max", "https://github.com/modular/modular-community", "https://repo.prefix.dev/modular-community"] name = "modular-community" platforms = ["linux-64", "linux-aarch64", "osx-arm64"]
But I stopped after this point. 
Hi there! It looks like you added the github URL to your toml. All you want is the actual community conda repo in your toml (“https://repo.prefix.dev/modular-community”).
4 Likes
Hey Zac will do I’ll check it out when I have some time thx Zac
Hey y’all I installed max, hue, and mojmelo. Are the .toml and .lock files going to be consolidated in some way? I feel this would clean up mojo standard packaging for deploying and setup on all machines. Or have a dedicated docs folder for a clean look. I verified the installation via command line and validated further thru magic list. Will prefix.dev be the default for mojo packages or will there be a standalone mojo.org. Could host the package index directly on the modular.com domain. Either way really cool start to get the codebase moving 
magic is based on the pixi project and by default will create a pixi.toml file if no mojo related options are given
When you created your project did you use the --format mojoproject option?
This should create a mojoproject.toml which includes the conda-forge and modular MAX links so you should never have to. magic will check to see if the local version of MAX matches the one on the server and if so, it will link the local one.
darin@home$ magic init --format mojoproject project_name
✔ Created /media/darin/M2/magic/project_name/mojoproject.toml
✔ Added max >=24.6.0,<25
Once, you enter your project directory and [optional] enter magic shell. You can then
magic project channel add https://repo.prefix.dev/modular-community
So, to you answer your question, yes to consolidations (see above)
Modular and prefix.dev have worked together to insure a that solid community package experience works through prefix.dev
2 Likes
Hey Darin. Yes what I mean is instead of project_name/mojoproject.toml, it could be something like project_name/config/mojoproject.toml and then you could have the rest of your folders src, data, etc
Ah I see what you’re meaning now Darin. I’ll have to look over the docs again. Is the —format method complete or still being built out?
It’s tested and working as intended. I was hoping there was an easy way to add the community channel in the project init process but channel add are sequential and channel priority strict. Put another way, we would have to do magic init -c chanel1 -c channel2 -c channel3 --format mojoproject project_name and that’s just a bit much for me (though it works). mojoproject.toml is aligned to make MAX work out of the box and adding the community channel to default creates all sorts of issues.
Is magic essentially going to be pip, apt, cargo, or npm for the Modular stack? I really liked the modular for command line when I first came across it. Martches well for the Mod stack I wonder why it was deprecated
Yes, and also environment management through conda. The original Modular CLI would have needed a buildup to include package and environment management; or, extend a pre-existing tool made by the (awesome!) prefix.dev team.
One other thing that pixi/magic also does is allow for multiple languages.
Hi,
No real issues, mostly smooth sailing, but you might want to be aware of the following.
I installed hue and mojmelo using magic 0.5.0. My project was originally on the latest nightly build. The first time I added the first package (mojmelo) magic added the package and downgraded my max to be >=24.5.0,<=25.0a0 without giving me an error or prompting me to downgrade.
I then removed mojmelo and max and then added max back by itself, which upgraded max to the latest nightly build, as expected. Then when I added mojmelo the second time, it gave me the expected error that it couldn’t solve the conda requirements of ‘default’ ‘linux-64’ and basically that I needed max >= 24.5.0,<25.0a0.
So, I downgraded max and reattempted to add mojmelo, which worked as expected. So did the follow-on add of hue.
I have also upgraded magic to the 0.6.0 prerelease and redid the above steps with no issues. That is, I was still not able to replicate the unexpected downgrade behavior I experienced the first time.
One additional thing I would like to note is that if a package fails to install it remains listed in the mojoproject.toml file. For example, in this case when mojmelo failed, it was still listed in the in the mojoproject.toml file under [dependencies] as mojmelo = “*”. When the install completes the “*” is updated to “>=24.5.0,<25.0a0”.
This isn’t limited to just community packages; this is true in general and created a problem for me a few days ago. When I tried to install a Python package unsuccessfully and then moved on to installing other packages, the package that had failed was blocking my other packages from installing. All I had to do was delete it from the mojoproject.toml file, and everything was good-to-go from there. It was a pretty minor inconvenience. Do I need to file an issue, or is this a known behavior?
In case it matters, I’m on Fedora 40.
1 Like
Important well-written feedback. Thank you.
If you could please write up two magic issues that would be greatly appreciated: one for the lack of errors and the other for the dependencies remaining even if they don’t resolve.
This may or may not be related to upstream pixi that magic is based on. Since it is the holidays, a gh issue (or two) will get eventually the attention.
1 Like
Hello!
I had a small issue adding the new nightly community channel (mojo-community-nightly - prefix.dev | prefix.dev) to my mojoproject.toml
It turns out I was using the modular-community prefix given in the shared Google Doc file and it took me some time to realize the channels are now prefixed with mojo instead of modular so it’s mojo-community-nightly not modular-community-nightly.
(Sharing it just in case someone else stumbles upon the same problem)
1 Like
Thank you. Nice catch.
@stano there are actually two channels. For the Modular supported packaging, the modular-community channel is correct. Prior to that, the community has self-organized around the mojo-community channel. The latter currently has more packages that are being shipped in it, while the former is under active development with early access. The confusion is entirely understandable, though.
1 Like
Yes, and just to clarify – the official community Prefix.dev channel doesn’t have a nightly version (yet). So modular-community is official, while mojo-community and mojo-community-nightly are community-owned.
We’ll make sure this is better communicated – thanks so much for the feedback!
1 Like