Wasp•2y ago

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

matijash•2y ago

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!

flmxyzOP•2y ago

With the latest updates, Mac has been changed the .profile name to .zprofile . Everything worked when I made the necessary changes.

martinsos•2y ago

Ah yes it switched to zsh -> awesome, thanks for sharing that!

Moretea•2y ago

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?

matijash•2y ago

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

Moretea•2y ago

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.

martinsos•2y ago

@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.

Kera•2y ago

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

matijash•2y ago

Are you on M1 mac?

Kera•2y ago

I am

matijash•2y ago

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.

martinsos•17mo ago

@Kera I will close the issues for now, but let us know if you need more help!

kd240•14mo ago

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?

matijash•14mo ago

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 🙂

kd240•14mo ago

Sure thing! Comming right up!

matijash•14mo ago

awesome 🙂

kd240•14mo ago

https://github.com/wasp-lang/wasp/pull/1559

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...

zerodave•14mo ago

@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.

matijash•14mo ago

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

zerodave•14mo ago

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

cabal test

cabal test

works as well as the

wasp-cli

wasp-cli

command -- that said, I may need some help figuring out how to package a

wasp-macos-arm64.tar.gz

wasp-macos-arm64.tar.gz

bundle. I can rewrite the

installer.sh

installer.sh

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 bundle

MEE6•14mo ago

Wohooo @zerodave, you just became a Waspeteer level 1!

zerodave•14mo ago

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

martinsos•14mo ago

@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:

Ok, so I got Wasp building on my new Mac M2 too  ... I installed gchup using normal options and when I first tried to build I did get the crypto error, but the hint reminded me to check my personal M1 I used for Wasp about LLVM:
Configuring library for cryptohash-md5-0.11.101.0..
Preprocessing library for cryptohash-md5-0.11.101.0..
Building library for cryptohash-md5-0.11.101.0..

<no location info>: error:
    Warning: Couldn't figure out LLVM version!
             Make sure you have installed LLVM between [9 and 13)
[1 of 3] Compiling Compat           ( src/Compat.hs, dist/build/Compat.o, dist/build/Compat.dyn_o )


Basically, it cannot find LLVM out of the box. I looked at my old ~/.zshrc profile and saw the following lines:
export PATH="/opt/homebrew/opt/llvm@13/bin:$PATH"
export LDFLAGS="-L/opt/homebrew/opt/llvm@13/lib"
export CPPFLAGS="-I/opt/homebrew/opt/llvm@13/include"


To get that, just run brew install llvm@13

So TLDR, install LLVM 13 from homebrew and export it and then you can build Wasp on Arm just fine  Ping if that does not work for you @Zeko369 and sorry I didn't document, but I was previously the only one on M1 and I forgot that one tiny extra step that was required. Additionally, I am unsure if newer LLVM versions work or it has to be 13, but you can use that just to be safe if you want (which I would recommend).

Ok, so I got Wasp building on my new Mac M2 too  ... I installed gchup using normal options and when I first tried to build I did get the crypto error, but the hint reminded me to check my personal M1 I used for Wasp about LLVM:
Configuring library for cryptohash-md5-0.11.101.0..
Preprocessing library for cryptohash-md5-0.11.101.0..
Building library for cryptohash-md5-0.11.101.0..

<no location info>: error:
    Warning: Couldn't figure out LLVM version!
             Make sure you have installed LLVM between [9 and 13)
[1 of 3] Compiling Compat           ( src/Compat.hs, dist/build/Compat.o, dist/build/Compat.dyn_o )


Basically, it cannot find LLVM out of the box. I looked at my old ~/.zshrc profile and saw the following lines:
export PATH="/opt/homebrew/opt/llvm@13/bin:$PATH"
export LDFLAGS="-L/opt/homebrew/opt/llvm@13/lib"
export CPPFLAGS="-I/opt/homebrew/opt/llvm@13/include"


To get that, just run brew install llvm@13

So TLDR, install LLVM 13 from homebrew and export it and then you can build Wasp on Arm just fine  Ping if that does not work for you @Zeko369 and sorry I didn't document, but I was previously the only one on M1 and I forgot that one tiny extra step that was required. Additionally, I am unsure if newer LLVM versions work or it has to be 13, but you can use that just to be safe if you want (which I would recommend).

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.

zerodave•14mo ago

@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.

martinsos•14mo ago

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/1574

zerodave•14mo ago

you are indeed correct, it is 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.

martinsos•14mo ago

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!

Gaming

Programming

MacOs Error.