MacOs Error.
Hi everyone, I'm getting a fail when I try to install Wasp on my Mac.
Error is =
It looks like '/Users/cankaytaz/.local/bin' is not on your PATH! You will not be able to invoke wasp from the terminal by its name.
You can add it to your PATH by adding following line into your profile file (~/.profile or ~/.zshrc or ~/.bash_profile or ~/.bashrc or some other, depending on your configuration):
export PATH=$PATH:/Users/cankaytaz/.local/bin
Can anyone help me with that situation?
27 Replies
ok great - so what you need to is actually what is written in the message: open your
.bash_profile
file and paste the following line in it: export PATH=$PATH:/Users/cankaytaz/.local/bin
.bash_profile
should be located in your. home dir, /Users/cankaytaz/.bash_profile
Lmk how it goes!With the latest updates, Mac has been changed the .profile name to .zprofile . Everything worked when I made the necessary changes.
Ah yes it switched to zsh -> awesome, thanks for sharing that!
So i initially had that issue, but then got past it, and immediately ran into another with the Node dependency, so I used Brew to install Node, but Wasp wants an older version than whats installed?!
MYMACHINE VenuisanCalendar-m8fw6 % curl -sSL https://get.wasp-lang.dev/installer.sh | sh Installing wasp version 0.11.1 (latest). Found an existing installation on the disk, at /Users/ME/.local/share/wasp-lang/0.11.1. Using it instead. Configuring wasp executable at /Users/ME/.local/bin/wasp to use wasp version 0.11.1. ============================================== WARNING: It looks like '/Users/ME/.local/bin' is not on your PATH! You will not be able to invoke wasp from the terminal by its name. You can add it to your PATH by adding following line into your profile file (~/.profile or ~/.zshrc or ~/.bash_profile or ~/.bashrc or some other, depending on your configuration): export PATH=$PATH:/Users/ME/.local/bin wasp has been successfully installed! To create your first app, do: - Add wasp to your PATH as described above. - wasp new MyApp Optional: - to install bash completion for wasp, run wasp completion and follow the instructions. MYMACHINE VenuisanCalendar-m8fw6 % export PATH=$PATH:/Users/adamblak/.local/bin MYMACHINE VenuisanCalendar-m8fw6 % wasp completion โ --- [Error] Node requirement not met: ------------------------------------------ Your Node version does not meet Wasp's requirements! You are running Node 20.4.0. Wasp requires Node ^18.12.0 to be installed and in PATH. Check Wasp documentation for more details: https://wasp-lang.dev/docs/quick-start#requirements. Any clues on how to move past this?
MYMACHINE VenuisanCalendar-m8fw6 % curl -sSL https://get.wasp-lang.dev/installer.sh | sh Installing wasp version 0.11.1 (latest). Found an existing installation on the disk, at /Users/ME/.local/share/wasp-lang/0.11.1. Using it instead. Configuring wasp executable at /Users/ME/.local/bin/wasp to use wasp version 0.11.1. ============================================== WARNING: It looks like '/Users/ME/.local/bin' is not on your PATH! You will not be able to invoke wasp from the terminal by its name. You can add it to your PATH by adding following line into your profile file (~/.profile or ~/.zshrc or ~/.bash_profile or ~/.bashrc or some other, depending on your configuration): export PATH=$PATH:/Users/ME/.local/bin wasp has been successfully installed! To create your first app, do: - Add wasp to your PATH as described above. - wasp new MyApp Optional: - to install bash completion for wasp, run wasp completion and follow the instructions. MYMACHINE VenuisanCalendar-m8fw6 % export PATH=$PATH:/Users/adamblak/.local/bin MYMACHINE VenuisanCalendar-m8fw6 % wasp completion โ --- [Error] Node requirement not met: ------------------------------------------ Your Node version does not meet Wasp's requirements! You are running Node 20.4.0. Wasp requires Node ^18.12.0 to be installed and in PATH. Check Wasp documentation for more details: https://wasp-lang.dev/docs/quick-start#requirements. Any clues on how to move past this?
aha got it - Wasp is currently requiring 18.12.0 because that is a LTS (long time support version). Check out why is that so and how to get it using nvm here: https://wasp-lang.dev/docs/quick-start#requirements
Quick Start | Wasp
Installation
yeah, I saw that, and my attempts to get nvm installed and functioning seem a little strained. reading the nvm OSX tips, it mentioned a tip that I tried with still no success:
MYMACHINE VenuisanCalendar-m8fw6 % touch ~/.zshrc
MYMACHINE VenuisanCalendar-m8fw6 % brew install nvm
==> Downloading https://formulae.brew.sh/api/formula.jws.json
############################################################################################################################################################################################ 100.0%
==> Downloading https://formulae.brew.sh/api/cask.jws.json
############################################################################################################################################################################################ 100.0%
Warning: nvm 0.39.3 is already installed and up-to-date.
To reinstall 0.39.3, run:
brew reinstall nvm
MYMACHINE VenuisanCalendar-m8fw6 % nvm install 18
zsh: command not found: nvm
ooof yeah, I've tried a lot of permeations now to properly install nvm, and downgrade but I can not seem to fit the environment to the requirements. I'll pause testing on this for now I guess. I like the premise of this but I'll have to wait till its requirements are a bit more OSX friendly.
@Moretea sorry to hear that -> Wasp is in Beta so most of the people using it already have some experience with Node and usually have node/nvm already installed, but of course we would love to make it easy to install for people who are new to it! Btw most of our users are Linux or Mac, and our team is also half Linux half Mac.
As for help with your issue, this is the first link I git on google when searching for it, and I am pretty confident one of our the suggestions in it will work: https://stackoverflow.com/questions/27651892/homebrew-installs-nvm-but-nvm-cant-be-found-afterwards .
While I can't be sure what is the issue in your situation, after reading the SO above, I would probably run
brew info nvm
and then add the suggested lines to .zprofile
(or whatever file is relevant for you), restart the terminal, and see if nvm is now available.
If not, I would go with the suggestion to uninstall the brew installation and install nvm
directly as explained here: https://github.com/nvm-sh/nvm#installing-and-updating -> there is also troubleshooting for MacOS there for some extra hints.Hiya, when I check if I have wasp by typing wasp -v it gives the following error - /Users/xxx/.local/bin/wasp: line 2: /Users/xxx/.local/share/wasp-lang/0.11.1/wasp-bin: Bad CPU type in executable
Are you on M1 mac?
I am
That is the issue then probably! Have you installed Rosetta? https://support.apple.com/en-us/HT211861#:~:text=Rosetta%20is%20not%20an%20app,it%20like%20you%20normally%20would.
Apple Support
If you need to install Rosetta on your Mac
Rosetta 2 enables a Mac with Apple silicon to use apps built for a Mac with an Intel processor.
@Kera I will close the issues for now, but let us know if you need more help!
Hey guys! I encountered the same issue. It would be nice that you note this somewhere in the official docs. Right now I needed to find discord link, join the group, search for the issue just to find a link that will redirect me to the Apple support. Simple note in the docs like "Make sure to install Rosetta on Mac with Apple Silicon". What do you think?
that's a very good point @kd240 ! I'm happy to do it, but if you'd like to add a line or two to our docs I'd be happy to give you credit as a contributor - let me know ๐
Sure thing! Comming right up!
awesome ๐
GitHub
Apple rosetta by kristian240 ยท Pull Request #1559 ยท wasp-lang/wasp
Description
As agreed in Discord I added a note in docs about MacOS Rosetta.
The next step is to detect the Apple SIlicon, check if the Rosetta is installed, and prompt the user to install it if ne...
@matijash very new to the community (~30 secs :) is there a roadmap item for M1/M2/M3 support for Wasp? just read your note to @kd240 about needing to install rosetta
I'm on a M1 max mac studio -- if I can help or contribute or test anything, please let me know. I'm not sure if anything besides just the wasp build process needs x86, but I'm not super excited about installing Rosetta if I can possibly avoid it.
sorry for the late reply here! I completely understand what you're saying and not wanting to install more stuff if not needed. Tagging @miho who is also on M1 (I'm still on Intel) - he might have an idea of what is possible
Thanks! Matija. Assuming I can get it to build, I could possibly build a waspc for arm64 and submit it as a PR
@matijash Okay, so I have it built for arm64 and works as well as the command -- that said, I may need some help figuring out how to package a bundle. I can rewrite the script to accomodate arm64 if one of the devs can help guide me on creating the tar.gz
obviously I could simply list the files in
wasp-macos-x86_64.tar.gz
and replace/move my wasp-cli
to waspc
-- but I suspect it's more complicated than that.
@matijash I updated installer.sh
to accomodate x86_64 and arm64 versions of MacOS (ready to submit the PR) -- now I just need to create the wasp-macos-arm64.tar.gz
bundleWohooo @zerodave, you just became a Waspeteer level 1!
FYI it was a bit of a bear to get LLVM@13 to go on MacOS Sonoma 14.1, but I got it figured out. I assume the arm64 binaries are all portable, but would need @kd240 and/or others with M1/M2/M3 hardware to perhaps test
Also per your suggestion, tagging @miho for visibility
@zerodave , a bit of context on how we create binaries!
In Github Actions we have a workflow that on every tagged release (if we tag it with
v0.1
or smth like that) builds binaries and posts them as a part of Github release.
Here is workflow: https://github.com/wasp-lang/wasp/blob/main/.github/workflows/waspc-ci.yaml -> there is Create binary package (Unix)
step.
They are built on Github's servers, and we run workflow multiple times, once on ubuntu https://github.com/wasp-lang/wasp/blob/main/.github/workflows/waspc-ci.yaml#L54 , once on mac https://github.com/wasp-lang/wasp/blob/main/.github/workflows/waspc-ci.yaml#L55 , and once on windows https://github.com/wasp-lang/wasp/blob/main/.github/workflows/waspc-ci.yaml#L56 . On windows we just compile to confirm codebase is owrking correctly, we don't yet build a binary (we have some more work to do there).
What really happens under Create binary package ...
step is the call to https://github.com/wasp-lang/wasp/blob/main/waspc/tools/make_binary_package.sh and that is it.
What this script really does is just package the binary that was built in the previous step ( https://github.com/wasp-lang/wasp/blob/main/.github/workflows/waspc-ci.yaml#L133 ).
So, the final result is that we have a binary built on Ubuntu, and we have another package built in MacOs.
It is not a completely static build, but is "quite" static (it depends on glibc and maybe something else), so the binary for Ubuntu works on most of other Linux distributions.
Now, what you want to do is build wasp for arm64. So what I guess you will want to do is modify this Github workflow so that there is another system it runs on, mac with arm64, and then everything else is kind of the same, but you also expand a bit the step with Create binary package ...
so it takes into account that third option (mac with arm64).
What I am a bit foggy about, as I don't have much Mac experience, is what you need to do to accomplish this.
So as I said, Github workflow currently runs on Ubuntu and on latest Mac. I guess that latest Mac is not arm64, or binary would be built for arm64. OK I took a quick look here: https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources -> but I don't see much info on which processor this macs use.
I found this though: https://github.blog/2023-10-02-introducing-the-new-apple-silicon-powered-m1-macos-larger-runner-for-github-actions/ .
On the other hand, do we need to do building on arm64 do create a binary for arm64, or can we do it on "normal" mac and just somehow tell cabal to build the binary for arm64 as a target? If so then we could do it on current github runner, just build additional binary.
----------------------------
OK OK, so I remembered we had similar discussion internally, and one of our devs there said that he was building natively on ARM:
But ok, this is I think the same as you said -> with correctly setting up LLVM@13 it can be built on MacOS.
Ok sorry for a bit of a train of thought! I hope some of this helps, but just to confirm something for me:
1. So current Wasp binary that we build for MacOS, that one doesn't work on arm macOSes? Because it was not built on arm machine?
2. And the solution is to build it on arm macOS, right?
If so, what I wrote above makes sense, I just wanted to check this is correct.
Yeah ok, TLDR we need to make Github Actions also use MacOS arm64 next to currently Ubuntu and MacOS x86, and that we can produce the binary. So we should investigate how to make Github Actions use MacOS arm64 as a runner and modify our workflow file accordingly.@martinsos yes -- that all makes sense to me now and following your train of thought was helpful. Thanks for the info on the Github actions. The binary that is pre-built for MacOS is the x86_64 version of Mac which is the old Intel Mac (I have several of those as well). The Mac OS/x86_64
waspc
binary will not run without Rosetta compatibility (x86 for arm64) which is a bit of a horror show performance-wise as it is a processor emulator for the new chips to run the old architecture.
I will have some time to dig deeper on this tonight. I may be able to create a PR for the particular modifications to the yaml Actions/Workflow files. This will give me an interesting opportunity to learn more about GH Actions. I've modified installer.sh
to detect x86_64 vs. arm64 macOS and to download the proper package, now I just need to get the workflow building it (if possible)
@martinsos after some research, I could patch the yaml to add macos-latest-large
alongside macos-latest
which will build against an arm64 M1 Mac, but... these are beta, and only available as large runners which are paid by the minute and not included in the monthly minutes of a regular Github plan. reference: https://github.com/actions/runner-images/issues/8439
Potential options to move forward:
1. If paid minutes are an option, I can patch the waspc-ci.yaml
and installer.sh
and test CI with the new paid runners building a wasp-macos-arm64.tar.gz
bundle
2. Wait until January 2024 when the macos-latest
will become GA and arm64 per the above issue #8439
3. Investigate adding Circle CI (https://circleci.com/open-source/) to the CI pipeline for macOS arm64 as they give 30,000 Mac M1 credits for free to OpenSource projects
4. Create a temporary branch (or fork) for Wasp on macOS arm64 and test CI via CircleCI above
and a final option:
5. Investigate and cross-compile waspc
on the existing macos-latest
runner to arm64 and build both x86_64 and arm64 arch binary bundles on the existing runner. It is definitely possible to x-complile arm64 on x86_64, but I am fairly sure the cabal test
functionality can't test the non-native arch. Then have the current runner build both macOS archs and build the two separate .tgz bundles.Wow thanks for the awesome research, this really helps a lot! I love how you analyzed all the options and presented them very clearly!
If
macos-latest
is indeed going to become GA and arm64 in Jan 2024, I think it is probably best investment of our efforts to wait till then. I will put an event in my calendar to remind myself at that point to check out the situation with the arm64 github runners.
Alternatively, we could try to go for the large
runner now as you suggested, as it wouldn't be wasted effort, we would later just replace that one with macos-latest
and also replace current macos-latest
with a fixed older version of mac runner.
I just looked at https://docs.github.com/en/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners -> it seems that even macos-latest-large
doesn't have arm, only macos-latest-xlarge
(or macos-13-xlarge
, those are the same thing currently) has arm64, so we would have to go with that one.
While currently we have free plan since we are open source, this wouldn't count against that and we would need to pay per minut, and from what I saw it is 0.16 USD at least per minute or maybe more I am not sure, which sounds like it could become a lot potentially.
Btw there are also self-hosted runners on Github, and they have support for M1 for some time now https://github.blog/changelog/2022-08-09-github-actions-self-hosted-runners-now-support-apple-m1-hardware/ , but I have to admit I don't know much about them and it also seems like a bit too much of a hassle right now, if we indeed have easier solution coming in the Q1 of 2024.
Cross compilation -> sounds tricky, probably best not to bother with it.
So to summarize, I think it is probably best to wait for Q1 of 2024 -> if we really really wanted to have something now I would go for the macos-latest-xlarge
, but I am a bit vary of how much it might cost us. I saw 0.16 USD being mentioned somewhere, and our macos build currently takes ~15 minutes to finish (almost ~3 times slower than linux or win btw). We can have 10 to 20 of these daily. So that is 0.16 * 15 * 20 = ~50 USD daily, which is a lot.
I created an issue in our repo for this here so we can track it! https://github.com/wasp-lang/wasp/issues/1574you are indeed correct, it is
I also should have said Q1 of 2024 instead of Jan 2024, as that's where it currently sits on the Github roadmap, according to @Steve-Glass from Github: https://github.com/github/roadmap/issues/819 I'll poke around with self-hosted runners if only for increasing my own knowledge, but I completely agree with your thinking. The costs would seemingly be enormous with 10-20 builds per day. I've got a local running copy of
macos-latest-xlarge
for the M1 Mac (arm64) -- I misread that article and thought they had made a change moving the M1 arm64 to large
, when in fact they made the old 12-core x86_64 which was -xlarge
the new -large
--confusing, no ๐
?I also should have said Q1 of 2024 instead of Jan 2024, as that's where it currently sits on the Github roadmap, according to @Steve-Glass from Github: https://github.com/github/roadmap/issues/819 I'll poke around with self-hosted runners if only for increasing my own knowledge, but I completely agree with your thinking. The costs would seemingly be enormous with 10-20 builds per day. I've got a local running copy of
waspc
on my M1 Max so I can play with it on my dev platform, and all my prod/staging infrastructure is Linux, so I'm all happy.
Thanks for the engagement on this topic (and for Wasp!). I learned a bunch looking into this.Vice versa, thanks for driving this conversation -> my understanding of the whole Mac arm64 situation was quite foggy at the start of it, but now we have a clear understanding of both the problem and possible solutions, so that is great!