Magic CLI alpha community feedback and questions
You can leave feedback and questions about the alpha test for the
magic CLI here, the doc to install and test it is here: https://modul.ar/magic-alpha-doc
You can raise issues or errors you're running into here: https://modul.ar/raise-magic-issue
70 Replies
Congrats on the release! I noticed that magic is built ontop of Pixi, what additional features are added ontop of Pixi? I'm trying to understand the difference between magic and pixi
Suggest edit to add:
profile’s $PATH (bash, zsh, fish, etc are all supported). You may need to source your shell rc or create a new shell to make sure that magic is in your $PATH.
Verifying Installation
You can verify magic installation
Forking and running MAX examples
I don't know if I should assume... 🙂 But if I understand this correctly, I do not need to
Modular clean and it will install in an environment on the side.Yeah we use Pixi along with a few other things under-the-hood to power magic to make working with MAX and Mojo a bit easier out of the box. One of the significant features is support for a new mojoproject.toml manifest format (like pyproject.toml) that will be the basis for other tools (stay tuned!). A lot of the things we are working on getting upstreamed into Pixi where it makes sense, though. What is great, however, is that the underlying packages are conda ecosystem compatible, so you can use other frontends like conda, mamba, or Pixi.
FYI: magic --version returned 0.1.1 but magic as a command later on would not be recognized. I then
source ~/.bashrc and then magic was recognized.Yeah on the first install it adds it to your shell but you may have to source to shell's rc file or create a new terminal/shell to get it to pick up 🙂 curl script should print that on first install but easy to miss
that was the odd part, I did close my terminal and start a fresh one. All good, cooking up some Bert now
Great! I'll definintely be checking this out. I saw in the provided document that there may be some rough edges between pixi | magic. Is it not recommended to have both installed on a system?
or is it more so not installing mojo/max via pixi but rather via magic
From the instructions
"cd max
Try to run a model like bert-python-torchscript. Follow the instructions in the README.md file.c
cd examples/inference/bert-python-torchscript
magic run run.sh
" .
That README.md has a anchor link which may potentially be used. The real issue is that it has Are you expecting the viewer to do the Magic MAX serving?? Not sure why the viewer goes to the README in the first place as the
Also, if they end up running serving
That README.md has a anchor link which may potentially be used. The real issue is that it has Are you expecting the viewer to do the Magic MAX serving?? Not sure why the viewer goes to the README in the first place as the
bert-python-torchscript is part of the max/examples/inference/bert-python-torchscript/.magic/envs/default/lib/python3.11/site-packages/transformers already.Also, if they end up running serving
magic run deploy.sh it fails for Docker(!!).GitHub
max/examples/inference/bert-python-torchscript at max-conda · modul...
A collection of sample programs, notebooks, and tools which highlight the power of the MAX Platform - modularml/max
having both is totally fine 🙂 they shouldn't have any conflicts. if you find any issues let us know though!
ahh yeah, good catch. Yeah the docs for serving are missing some details there in general 🙂
While my computer is downloading llama3... Out of curiousity...Does conda and subsequently magic have a local cache that will pull the model each time for each environment like pip?
Yeah it caches to
~/.cache/modular or $XDG_CACHE_PATH/modular if you have that setwanders off to check
magic --help to see what kind of trouble I can get intohaha have fun. this is an early preview release so let us know if you find anything weird
Congrats @Zac Bowling, you just advanced to level 3!
when I run
magic add open3d is there do a --no-install kind of thing or more specifically, how would I go about easily adding a requirements list to this environment?
Ohhh...it hasn't exactly.... OK, but is there still a way to add it to the environment without installing?you can edit the mojoproject.toml or pixi.toml file directly 🙂
magic add ... is shorthand for amending/editing the file and then running magic installGot it
mojoproject.toml is nearly 100% compatible with pixi.toml today (it's a superset at the moment during this preview but that could change in the future)
Is
project a container for environment. When I am in -default. Is that the project or the environment or they both existing with the same name ? magic init deleteme ; cd deleteme; magic project environment list and I expected to see "default" and "deleteme" but only say 'default"each project has a set of environments (with an implicit default one) but it doesn't create an environment with the name of the project, no.
magic environments are project scoped (almost like poetry if you ever used that) rather than global (like conda)
on the backend, packages are installed into a global cache though so each env doesn't end up with a full set of duplicate packages on your disk 🙂
Since I have jsut the default project, and I created a temp environment, when I use the command
magic project environment list should it show all the environments in that project?yeah exactly
My tmp is called "deleteme" and I don't see it in the list.
yeah, you have an implicit env called default in each project. it doesn't create an env named after the project. you can make one named the same if you want though with "magic project environment add tmp"
I usually only make different envs to test different versions of python or different combos of dependency versions (like a CPU or cuda), but i usually use the default for the most common setup I want to develop since you don't have to pass a specific env each time
That's my point, I swear I already did and it's not there
I did
magic init deleteme and then changed into the directory, then added open3d and then I can verify that the magic.lock does indeed have it added. I can't find it on any environment listif you edited the mojoproject.toml/pixi.toml it might have got removed.
should see something like this in one of those files after adding an env
[environments]
tmp = []
Ohh, so let's see if we're on the same page then...
you would also likely see the env in ".magic/envs" in that folder after you install into that env
I did
My expectation is that I could find that
deleteme environment through the magic command just like conda env list. Am I able to do that with magic???
I am also under the impression that it got created under my default project so I did magic project environment list and there was only -defaut, is that expected behavior??
Ohhhh, yea, so that's the problem... And I bet I won't be the first that makes this mistake...
magic init deleteme does not create a new environment... It creates a new project called deletemeYeah!!
init just creates a project file with some defaults
Yeahhh... nooo...yeahhh...ummm.... I am totally familiar with project based environments but that's not my standard for venv
Ah yeah, this is similar to poetry merging both project management and virtual environments into a single tool
DaVinci Resolve or Blender or something. projects. Python / mojo environments nope. Also, I bet most people will not come with a project first mindset
I do think it's the right decision, I just think that's not what most people come thinking.
Dumb question: how do I exit from
magic shell?Suggestion:
After
"Creating and running a Mojo project with Magic🪄"
Magic uses a project system. Each project has a default environment to use or you can create additional environments. This allows for migration, prototyping, debugging, and more.
"Create a new Mojo project:
magic init --mojoproject my_magical_project
cd my_magical_project"
exit worked for me
Didn't work for me 😦
Soz, got same return, but environment returned to shell. /shrug
I was excited when I saw this brewing in the Pixi discord. Glad to see how quickly this came together.
:party_parrot: me too!
you might be two levels nested in a magic shell
Okay I was in nested shell:
yeah 🙂
😂
It's truly like fire, I can't seem to stop the spread...
Joking of course. But is there a magic command to remove a project or do we just
rm -rf like a venv env or ???can just rm -rf 🙂 if you want to kill the envs and not the code in the project, there is ~/.magic in the folder and you can just rm -rf that.
I'm getting a warning here, should it be a concern?
known issue 🙂 it's all good
yeah, that warning is the libstdc++ in the venv from conda is really new, so the built in lldb/llvm in mojo doesn't recognize new debug symbols stored in the library produced with the latest and greatest gcc so mojo likes to be a little too vocal when it sees something it never seen before 😆
fyi there is also
magic clean cache if you want to blow about the global cache used to store packages. if you use that though then the next time you invoke a project, it will redownload all the packages into the environment.Is the ability to install multiple different versions of mojo available... say one per project?? (One can dream)
yep 🙂 but the only version in the conda repo right now is 24.4
gotcha, so no main and nightly or every nightly ever (to support SSD manufactures) ???
maybe 🙂 can't give timelines on any releases after this preview
Can we add to the local cache? And/OR, can we make ourselves a channel?
but one of the goals is reproducible and consistent environments where projects can specific their exact dependencies including the exact version of max/mojo your code depends on
Congrats @Zac Bowling, you just advanced to level 4!
you can add additional conda channels in your project that you want to source dependencies from like nvidia, jupyter, pytorch, or bioconda including custom ones (or even include pypi dependencies from python). Not announcing any tools by us for creating sharable packages yet 🙂
Wonderful release, looks pretty polished for alpha and I know there's a LOT of moving parts going on behind the scenes. Make sure you take a victory lap.
Even if we continue to use the modular CLI to install them, in the name of reproduciblity could you create dummy packages for nightly versions so we can document which nightly version to use for projects which require nightly? I've seen a lot of issues with projects no longer building with the current version of nightly mojo, especially after all the recent changes to pointers, and the author having issues determining what version does work. Ideally also make the magic cli drop the version info of the currently installed/active mojo version into the project file when you create a project with this so authors don't need to think about it.
Absolutely! This is one of the things we were looking to solve. The magic.lock provides that info on what was used when it resolved versions which you are building together. You you can check that in with the code if you want and others can check out the same exact versions of all the deps (sorta the same rules as cargo.lock files there if you are familiar). Then you can be granular to a specific build in your mojoproject.toml/pyproject.toml/pixi.toml file with the specific version the code depends on or give a range of versions that are supported in some cases.
For modular CLI is a little harder problem and little brittle with nightlies. You can do it but a bit more complicated and not easy for us to build tooling to support well. Magic helps solve all that and a dozen other long tail issues that have been a problem 🙂
The reason I proposed leaving nightly installs up to the user using the modular cli was because I wasn’t sure if you wanted to duplicate hosting for nightlies and have to go set up another deploy pipeline which actually pushes the binaries in vs “create a new package version with a text file in it as a placeholder”.
I’m not sure what your internal CICD looks like so I don’t want to ask for something difficult or long-term expensive. Placeholders compress well, so it’s cheap.
I’m not sure what exactly you mean with “placeholders” (the repo format for the current CLI is a bit unique). Right now, though, as you were saying it is difficult to sort of determine the current build of max/mojo that you’re using sometimes so that you can communicate that to somebody else so they can use the same code at that same version. We had a somewhat of an open secret command to install versions of mojo/max/nightlies at a specific version but the input was hard to figure out (we actually write to a file in the toolchain install folder with the version you can pass in but not obvious 😅). With nightlies we originally assumed most folks would use it to work on things like the mojo open source stdlib to test changes or to try latest new features or bug fixes, but we didn’t design it well for the use case of people who want share their code in a way that others could reproduce well with those nightlies.
We want to help with that and that’s what magic is really great at. As MAX and mojo mature and people build more complex things with it, we’re trying to make sure folks can keep their code working consistently with all the dependencies that code uses (including MAX). Now you can keep a record with your code of what your code built with your manifest + lock file.
But I hear you. 😁 Best I can say is that our ci/cd setup is pretty complex 😅 duplicated hosting is the least concern or complexity though for nightlies.
Does magic have its own config.toml, or it uses pixi’s? I need to specify custom pypi index url and conda mirror
And also a question - can I use mojo to install mojo from already downloaded mojo binaries without downloading online? I want to install mojo on my offline machines easily
Maybe some flag to specify or manually putting files in cache folder?
Great questions! Wasn’t expect such advanced questions already. Let me work on getting documentation together on that. Magic uses its own global config (in the modular directory depending on OS and if XDG is being used in your distro) but the location isn’t in the final location it’s going to be in later versions.
Oh, that’s a valid use case. Let me look into that
@Zac Bowling thank you!
also waiting for
magic self update now and magic self add system for future plugins support like in pdm https://github.com/pdm-project/awesome-pdmGitHub
GitHub - pdm-project/awesome-pdm: A curated list of awesome PDM plu...
A curated list of awesome PDM plugins and resources - pdm-project/awesome-pdm
Congrats @toiletsandpaper, you just advanced to level 9!
magic self-update is coming after this preview 🙂 I have to teach magic about our distribution platform so it can check for updates and download specific versions.
love the idea about a plugin model. Some of that can work with global installed tools but some things would be cool to hook inside magic. One idea i've been talking about with pixi devs is an initalizer plugin, almost like how
npm create works, so that plugins (packages also in conda) can help with project scaffold generation.just to be clear, you know you can specify whatever channels you want per project now. I hear that a global would be nice, just wanted to make sure that you knew that you can hack it already.
Would be nice to have a separate channel for Magic CLI related stuff, IMHO.
Good idea
I second this, this thread is going to get lost in a week or two and be difficult to find.
Created a channel here: #magic-cli locking this thread now thanks for the suggestion @SyseAdmine