Error: /bin/sh: pod: command not found

[whck6]

As title.

ℹ️  STARTED: "wipe system iOS Pods cache"
error

Task "wipe system iOS Pods cache"
Error: /bin/sh: pod: command not found
.
Exit code: 127

.
Error:

Task "wipe system iOS Pods cache"
Error: /bin/sh: pod: command not found
.
Exit code: 127

[mikehardy]

You don't specify your platform. Are you not on macOS? If you are a react-native developer and you are on iOS, then pod is required to be in your PATH. If you are not on macOS (just developing on windows or linux perhaps) then perhaps react-native-clean-project shouldn't try it.

How did it go when you edit the code in this module to check platform first, and avoid pod / brew commands if you aren't on macOS?

[whck6]

You don't specify your platform. Are you not on macOS? If you are a react-native developer and you are on iOS, then pod is required to be in your PATH. If you are not on macOS (just developing on windows or linux perhaps) then perhaps react-native-clean-project shouldn't try it.

How did it go when you edit the code in this module to check platform first, and avoid pod / brew commands if you aren't on macOS?

I suppose it because i installed the cocoapods with Gemfile. And I ran as below

bundle install --path vendor/bundle

I guess it is problem

   wipeSystemiOSPodsCache: {
     name: 'wipe system iOS Pods cache',
     command: 'cd ios & pod',
     args: ['cache', 'clean', '--all']
   },

Fix temporary for me

   wipeSystemiOSPodsCache: {
     name: 'wipe system iOS Pods cache',
     command: 'cd ios & bundle exec pod',
     args: ['cache', 'clean', '--all']
   },

[pmadruga]

Which OS are you using?

[mikehardy]

For what it's worth, I see this when running on windows and Ubuntu, both valid for development if doing android-only app or temporarily on those platforms and just doing pure JS work and validating on android. Both of those are use cases for me from time to time

But that is issue #92 (and I need to propose the related PR...)

This is something maybe related to recent changes in react-native where there is a .ruby-version file, a Gemfile/Gemfile.lock and a bundle directory. It's possible now to run cocoapods via bundle I suppose ? I haven't ever done this myself

So the more interesting question for @whhotw might be: how do you do your react-native project checkout/installation and how do you normally install pods etc?

[whck6]

Which OS are you using?

macOS 11.6

[whck6]

For what it's worth, I see this when running on windows and Ubuntu, both valid for development if doing android-only app or temporarily on those platforms and just doing pure JS work and validating on android. Both of those are use cases for me from time to time

But that is issue #92 (and I need to propose the related PR...)

This is something maybe related to recent changes in react-native where there is a .ruby-version file, a Gemfile/Gemfile.lock and a bundle directory. It's possible now to run cocoapods via bundle I suppose ? I haven't ever done this myself

So the more interesting question for @whhotw might be: how do you do your react-native project checkout/installation and how do you normally install pods etc?

Basically, I don't want to install cocoapods with global, so I created Gemfile/Gemfile.lock and install them via bundle install --path vendor/bundle. by the way, I don't think which is related to react-native development, that's just my way of dependencies management.

[mikehardy]

Your method is valid but you are in the minority, I think. The PR you propose, switching all of the pod execution to bundle ... - is that backwards compatible? Just curious as I've never run pod that way. I actually want a "global" install, but since I use rvm, "global" for me is actually version-scoped ruby from my user's home directory

In that way though, pod is on the path but it's user-scoped not machine-global

[FilDevTronic]

@mikehardy just FYI, using Bundler, the Ruby package manager, and something like .ruby-version to pin your version of Ruby through an environment manager tool for your local project has been possible from the outset, given that React Native uses Ruby for the iOS side of development. It's just that the React Native team seemingly decided to use it in the official project itself probably to keep those things the same across dev environments for people working on the official project.

Just in case that you don't know of it, Bundler is to Ruby what Node Package Manager and Yarn are to JavaScript - a way to pin Ruby and Ruby Gems by version in any Ruby project. As npm uses package.json, bundle uses Gemfile.

As an example, here's the Gemfile that we're using in our project at work:

source "https://rubygems.org"

ruby "3.1.0"

gem "cocoapods", "1.11.3"
gem "fastlane", "2.205.1"

As you can see, it works much how package.json works for Node and NPM, where the gem fields are for Ruby Gem dependencies, and ruby is akin to engines in package.json for the version of Node you expect to run the project with.

Given you are using rvm, I imagine you know about .ruby-version? If not, it's used to set the Ruby version you're using in your environment, and, in our case here, in the local React Native project directory. While the Gemfile makes sure that the right version of Ruby is run when using any Ruby Gems, the .ruby-version file ensures we actually have the correct Ruby version loaded at the start.

As for being in the minority for using Bundler - definitely, if we look at the gamut of everyone who might be making a React Native project, however it is good practice to use something like Bundler when trying to keep the dev environment the same across many machines that developers could be working on, for the same project.

You may consider just creating a gemspec file instead of using Bundler but that is probably not a good idea for a React Native app.

The trouble with Bundler, compared to npm or yarn is that it isn't as neatly integrated into the dev experience, demanding that any command you want to run for a Ruby Gem is prepended with bundle exec. See here for the docs.

Note that @whhotw didn't actually propose any PR as you say, he merely shared his "Fix temporary for me". May be handy to do this with something like patch-package locally but it definitely isn't a fix that is going to stick.

It could be accommodated, however, by creating a new task list in tasks.js that gets used when a flag gets passed, e.g. --withBundler, as it would be more than just making sure that we do bundle exec pod instead of just pod, but also clean the Bundler specific artifacts (e.g. vendor/bundle/ruby/[version]/cache, vendor/bundle/ruby/[version]/gems or perhaps vendor/** all-together), including making these both optional and part of auto.

Think it's time I forked this project....

[mikehardy]

Think it's time I forked this project....

Hopefully with PRs back to this repo though, I've been recommending it for a couple years now and it's really handy to have one canonical place to send people.

I understand everything you mentioned, I just want to say that my use case is that I clone the raw react-native template all the time as a react-native release tester, and I use current ruby via rvm. I make sure pod is up to date, and ruby is up to date in my PATH like a good maintainer of environments. I just want react-native to run and use them, personally. I don't want a full-fledged Ruby dev environment with Gemfiles and all that. So if you make a PR please just consider my use case (which may be summarized as: the way react-native worked from 2018 to 2021)

[FilDevTronic]

Yep, 100% agree - the default position should be a bare-bones project, that's why I was thinking to myself "hmm, I just want it to be able to capture the option of using Bundler 🤔".

And yep, fork and a PR back to this repo, just want to make sure I am not actually writing garbage first 😅!

[whck6]

--withBundler

I think that's a good idea!