この記事は、独特なネーミングがされていて、知っているようで知らないHomebrewの用語の意味を正しく理解するために書きました。
Homebrewは「自家醸造」の意味です。この「醸造」の世界観の元で、Homebrewで扱う一部の概念の名前がつけられていて、直感的に何を指すのかが少しわかりにくいことがあります。
インストール関連のトラブルやPATHを通すパッケージのバージョンを調整したいときに、これらの用語を知っていると、エラー・警告メッセージの内容や、brew info
コマンドなどで説明されている内容を理解しやすくなると思います。
以下、用語の定義と意味を説明します。正式な情報は公式サイトを参照してください。
formula (製法)
homebrewでupstreamのソースからビルドするパッケージの定義。formulaeは、その複数形。
cask (大きいたる)
macOSネイティブアプリケーションをインストールするパッケージの定義。
keg (小さいたる)
任意のformulaの任意のバージョンのインストール先ディレクトリ。 例 : /usr/local/Cellar/[formula]/0.1
rack (棚)
1つ以上のバージョンのkegを含むディレクトリ。 例: /usr/local/Cellar/[formula]
prefix
homebrewでパッケージを配置する親ディレクトリ。 例: Intel Macの場合は、/usr/local
keg-only
kegにパッケージを配置するだけで、prefixのbinディレクトリに、シンボリックリンクが作られないこと。
postgresqlもkeg-onlyなので、brew install postgresql
でインストールしても、PATHが通った状態にはならない。
(keg-onlyなパッケージにPATHを通したければ brew link
コマンドを使う。)
cellar (貯蔵室)
1つ以上のrackを含むディレクトリ。 例: /usr/local/Cellar
Caskroom (cask用の貯蔵室)
1つ以上のcaskを含むディレクトリ。 例 : /usr/local/Caskroom
external command
Homebrew/brewのGitHubリポジトリ外で定義されているbrew
の(追加インストール可能な)サブコマンド。
tap (蛇口)
formula、cask、external command用のディレクトリ(かつ、通常はGitリポジトリ)。
bottle (ボトル)
ソースからビルドするのではなく、cellarやrackに配置するために、事前にビルドされたkeg。
本サイトの更新情報は、Twitterの株式会社プレセナ・ストラテジック・パートナーズエンジニア公式アカウントで発信しています。ご確認ください。
ngrok(エングロクと読む)は、httpのトンネリングサービスです。
ngrokでホストされるURL(例:http://xxxx.ngrok.io/ )へのアクセスをローカル環境のwebサーバー(http://localhost:3000 など)にトンネリングしてくれます。
例えば、stripeやLINE、その他クラウドサービスのwebhook処理を開発する際に、インターネット上に本番やステージングのwebサーバーを構築する前に、ローカル開発環境でwebhookへの対応コードを実装、テストすることができるようになります。
この記事では、ngrokの開発環境を用意する手順を紹介します。
公式サイトでダウンロードして、インストールすることもできますが、インストールはmacOSの場合であれば、homebrewを使うほうが楽です。以下のコマンドでインストールできます。
ngrokを使うためには、サービスの利用登録が必要なので、公式サイトでサインアップを行ってください。
サインアップするとログイン後のページにauthtokenが表示されているので、それをコピーして、以下のように、コンソールから設定します。
そうすると、~/.ngrok2/ngrok.yml
にtokenの値が書き込まれてサインアップしたngrokアカウントが認識されるようになります。
トンネリングを開始するためには、以下のようなコマンドを実行します。
これで、以下のような情報がコンソールに表示され、トンネリングに使えるURLが分かります。
この記事では <your-random-subdomain>
と記載しましたが、ここに、トンネリングで使えるインターネットアクセス可能なURLが表示され、また、そのURLがローカルのhttp 3000番ポートにトンネリングされているのが分かります。
この一般公開されているURLをクラウドサービスのwebhookのエンドポイントとして指定しておけば、ローカル環境のwebサーバーを使って動作確認をしながら開発を行うことができます。
無償のアカウントでは、ngrokを起動するたびに、http://<your-random-subdomain>.ngrok.io
の <your-random-subdomain>
の部分がランダムなサブドメインになってしまい、そのたびに、クラウドサービス側の呼び出し先設定を更新しなければなりません。
これは、ngrokの有償登録をすることで固定化できます。有償登録をすると、以下のようにサブドメインを他のユーザーが使っていない任意の文字列に固定できます。
ngrok起動中のコンソールでCtrl+U
でアップデートが開始されます。
本サイトの更新情報は、Twitterの株式会社プレセナ・ストラテジック・パートナーズエンジニア公式アカウントで発信しています。ご確認ください。
ngrokが最近メジャーバージョンアップして、バージョン3がリリースされましたので、アップグレード手順を紹介します。
なお、設定ファイルは、下位互換性がなくなっているので、ngrok本体のアップグレード後には、設定ファイルのアップグレードが必要になります。
当サイトの導入記事で紹介したように、Homebrewでcask(Mac用アプリケーション)としてngrokをインストールしている場合は、以下のコマンドで本体をアップグレードします。
ちなみに、ngrokには、ngrok update
コマンドもありますが、このコマンドではメジャーバージョンアップはされません。
アップグレード後にバージョンを確認するには、以下を実行します。
なお、この直後に、ngrokを起動すると以下のようなエラーが出るため、後述の設定ファイルのアップグレードが必要になります。
さきほどのエラーメッセージにも、公式サイトにも説明されている通り、設定ファイルのアップグレードも必要になります。
これで、~/.ngrok2/ngrok.yml
ファイルが更新されて、通常通りngrokが使用できるようになります。
本サイトの更新情報は、Twitterの株式会社プレセナ・ストラテジック・パートナーズエンジニア公式アカウントで発信しています。ご確認ください。
当社の日常業務の中で、Slackのリマインダーを設定することは、頻繁にあります。
しかし、Slackのコマンドを使ってリマインダーを指定する際、とくに、日時の指定の仕方を中々覚えられず、公式ヘルプを見に行くことが多いです。
公式ヘルプにも詳しく載ってはいるのですが、特に「When」を指定する部分について、この記事では、一覧で分かるように紹介します。チートシート的な使い方を想定しています。
/remind
コマンドのフォーマットは以下です。
この[what]
の部分まではわかりやすいのですが、この記事では最後の[when]
の部分を詳細に紹介します。
[when]
の部分は、以下のように、細かく指定することが出来ます。
x分後、x日後、x週間後など、現在からの相対的な時間で指定する場合、in
を使います。
※秒を指定しても、そこまで正確なタイミングではリマインドされないようです。
なお、時間を指定せずに相対的な日付を指定すると、指定した日の9:00になるようです。
2日後のX時、など細かい時間を指定したい場合は、atも併用します。
次ように、at
とon
を使って、時間と日付を指定します。
次のように曜日を指定すると、指定した曜日が次に来る日に投稿されます。
この使い方が一番多い気がします。末尾にevery
をつけて頻度を指定します。
毎月月初にやらないと行けないタスクをリマインドさせるなどに便利です。
この場合もat
とon
を併用できます
以下のように、特に"
で囲んだりせずに、普通に指定できます。
本サイトの更新情報は、Twitterの株式会社プレセナ・ストラテジック・パートナーズエンジニア公式アカウントで発信しています。ご確認ください。
Slack emoji とGoogle meet を連携して使う
当社のエンジニアは全員フルリモートで働いているため、対面での相談は Google meet
を使うことが多いです。
ただ、対面で相談するまでの準備に手間がかかると、気軽な相談はしづらくなりがちです。
そこで当社では、「Slackのカスタムレスポンスとemoji」にGoogle meetのURLを紐付けています。その結果、Slackでのやりとりが難しいと感じた時に、すぐ対面での相談へと移行できています。
Google meet
Slack
Slackへ相談の前フリと :room:
などのemojiをポストする
Slack botが相談用のGoogle meetのURLを案内する
任意の画像を用意します。
もし、文字列画像を用意する場合は、絵文字ジェネレータ(https://emoji-gen.ninja/)などが便利です。
なお、 生成履歴に絵文字を表示する
のチェックボックスについては状況によりON/OFFします。
Slackのemoji設定ページ(https://***.slack.com/customize/emoji)を開き、文字列 (例: :room:
)と 上記1.の画像を登録します。
Google meetのページ(https://meet.google.com/)にて、URLを取得します。
Slack botの設定ページ( https://***.slack.com/customize/slackbot)を開きます。
Slackbotタブに以下を入力し、保存します。
When someone says
に、上記2.のemojiの値 (例: :room:
)
Slackbot responds
に、上記3.のGoogle meetのURL
以上で設定は完了です。
本サイトの更新情報は、Twitterの株式会社プレセナ・ストラテジック・パートナーズエンジニア公式アカウントで発信しています。ご確認ください。
公式サイトでインストーラーをダウンロードしてインストールしてください。
基本的に以下の公式サイトに従うだけです。
公式サイトにも載っている内容ですが、以下のコマンドを入力して、
以下4つの項目を設定すればOKです。
AWS Access Key ID
AWS Secret Access Key
Default region name
Default output format
これも公式サイトに載っているままの情報ですが、利用したいIAMユーザーのAccess Key IDとSecret Access Key は、https://console.aws.amazon.com/iam/ から、設定したいユーザーを選択して、「認証情報」タブでアクセスキーを生成してください。
次に、多くの場合に必要となるjqとSession Manager pluginをインストールします。
jqはJSONを操作するためのCLIツールで、近年急速に利用が広がっています。Macの場合はbrewでインストールできます。
Session Manager pluginは、AWS CLIのプラグインで、ECSタスク内のコンテナやCLI経由でEC2にログインする際に必要です。公式ドキュメントに従ってインストールしてください。
以上。
本サイトの更新情報は、Twitterの株式会社プレセナ・ストラテジック・パートナーズエンジニア公式アカウントで発信しています。ご確認ください。
当社の開発で使うRubyのバージョンは、プロジェクトごとに異なることが多く、また、プロジェクトごとにRubyのアップデート状況も異なります。
したがって、プロジェクトごとにRubyのバージョンを切り替える仕組みとしてrbenvを導入して使います。
直接rbenvをインストールするか、anyenv経由でインストールするかで手順が変わります。
anyenvがすでに導入されている場合、以下で簡単にrbenvをインストールできます。
公式サイトの手順に従います。
まずは、homebrewでrbenvをインストール。このとき、ruby-buildも同時にインストールされます。
次に、
を実行して、出力された手順にしたがって、シェルの設定を行います。zshを使っている場合、以下のように出力されるので、この内容に従います。
つまり、.zshrcファイルに以下を追加します。
rbenvがインストールされたら、次は、使いたいバージョンのRubyをインストールします。
まずは、インストール可能なRubyの安定バージョンを確認します。
ここに表示されたバージョンを指定して、開発環境にインストールします。
プロジェクトで使うRubyのバージョンは、他の開発メンバーとも共有したいため、.ruby-version
ファイルを作って、他のメンバーにも同じRubyのバージョンの使用を強制できるようにします。
プロジェクトルートで、以下を実行すれば.ruby-version
ファイルがプロジェクトルート直下に作られます。
Rubyのバージョンを上げる手順もanyenvでrbenvをインストールしたかどうかで異なります。
rbenv install -l
コマンドで、インストールしたいRubyのバージョンが表示されていない場合、anyenv内部のruby-buildのアップデートが必要です。このアップデートのコマンドを楽にしてくれるanyenv-updateを使うのをおすすめします。
anyenv-updateが設定してあれば、以下を実行するだけで、インストール可能なRubyのバージョン情報が最新化されます。
このあとは、普通に特定のバージョンのRubyをインストールします。
同様に、インストールしたいRubyのバージョンが表示されていない場合、先に、rbenvとruby-buildをアップデートする必要があります。rbenvとruby-buildのアップデートにはhomebrewを使います。
これで、インストール可能なRubyのバージョンが最新化されるので、特定のバージョンをインストールします。
本サイトの更新情報は、Twitterの株式会社プレセナ・ストラテジック・パートナーズエンジニア公式アカウントで発信しています。ご確認ください。
この記事でインストールしているバージョンは古くなっている可能性もあります。最新バージョンに読み替えて利用するようにしてください。
OS:Mac
Scala:2.13.6
Scala を使うには Java と sbt が必要になります。バージョン管理ツールを2つ紹介しますが、どちらを使っても構いません。
SDKMAN
Java と sbt どちらもこれ一つでインストールできるので、 anyenv を使っていないのであればこちらがおすすめです。
anyenv + jenv + sbtenv
anyenv ですべて管理したい人向けです。
無償JDKとして広く利用されていたAdoptOpenJDKはEclipse Adoptiumプロジェクトに移管されることが公表されており、2021/8/13にはそのサブプロジェクトであるEclipse Temurinプロジェクトから新たなJDKがリリースされました。今回はこちらのJDKを利用します。
また、Java には LTS バージョンが設定されており、このバージョンのみをサポートしているライブラリも多いです。特段の理由がなければ、最新版ではなく 8 や 11 といった LTS バージョンをインストールするのが良いと思います。
SDKMAN のインストール以下のコマンドを実施するだけです。
下記コマンドを実行してバージョンを確認してみます。 sdk-man-init.sh
の実行は .bash_profile
等の末尾に追加されているので、次からはターミナルを開いた時に自動実行されます。
バージョン管理ツールがインストールできたので、 Java と sbt をインストールします。
Java は 8系と 11系が LTS なので、どちらかをインストールします。選択肢が多いのですが、前項で述べた通り Temurin を選択します。
sbt はとりあえず新しいバージョンを入れておけば良いと思います。
ディレクトリ内で特定のバージョンを有効にするには、 sdk env
コマンドを利用します。
すると .sdkmanrc
ファイルが生成され、デフォルトでカレントバージョンが設定されるので、これを利用したいバージョンに変えればOKです。ただ、コメントにもあるように ~/.sdkman/etc/config
の sdkman_auto_env
を true
にしなければ自動的に適用されないので設定しておきましょう。
ちなみに Metals を使ったプロジェクトの場合、 sbt のバージョンに関しては project/build.properties を参照してくれるため、バージョン指定は不要です。
anyenvを利用する場合、java, sbtのバージョン管理ライブラリはそれぞれjenv, sbtenvを利用することになります。jenvはrbenvやnodenvと違って言語のインストール機能は持っていないため、JDKは手動でインストールし、jenvに読み込ませる必要があります。
環境構築の流れは以下の通りです。
anyenvのインストール
JDKのインストール
jenvのインストール&設定
sbtenvのインストール&設定
SDKMANではなくこちらの手順を選択している方は既にインストール済みの方が多いと思いますので、詳細な手順は割愛します。新規にインストールする方はanyenv公式のREADMEに沿ってインストールしましょう。
jenv公式で推奨されている通りHomebrewでインストールを行います。2021/9/14現在temurinからリリースされているJDKは16系が最新となりますが、先述のとおり今回はLTSである11系をインストールします。つまり最新版以外のJDKをインストールする必要があるため、複数バージョンを扱えるようにしてくれるhomebrew-cask-versionsをインストールします。
インストール可能なJDKを検索するとtemurin11
が表示されるようになりますので、これをインストールします。複数のJavaバージョンを切り替えて利用したい場合、ここで必要な分だけインストールしておきましょう。
これでJDKのインストールは完了です。
anyenvの通常の使い方に沿い、以下コマンドでjenvをインストールします。
jenvのexportプラグインを有効化しておきましょう。
インストールしたJDKのHomeディレクトリをjenvに認識させます。複数のJDKをインストールした場合はそれぞれ実施しましょう。ここで認識させたJDKがjenvのバージョン切り替え対象に加わります。
jenvで利用するバージョンを指定します。
これを行うと実行したディレクトリに.java-version
というファイルが生成されます(中身は指定したバージョン番号だけ記述されたシンプルなファイルです)。このディレクトリに移動した際にはjenvがこれを読み込み、指定されたjavaのバージョンが自動的に参照されるようになります。
shをリセットすると、先ほど有効化したexport
プラグインにより環境変数JAVA_HOMEも設定されます。
以下を実行すると、.java-version
ファイルが存在しないディレクトリでデフォルトで適用するバージョンを設定することができます。必要があれば設定してください。
これでjenvのインストールと設定は完了です。
以下コマンドでsbtenvをインストールします。
sbtのインストールを行います。バージョンはSDKMANの項と同様に1.5.5をインストールする場合、以下のようにします。複数バージョンのsbtを切り替えて利用したい場合、ここで必要な分だけインストールします。
※ gpgが必要
といったエラーが表示された場合、インストールしてsbtの公開鍵を設定してから再実行してください。
インストール完了後、jenvの時と同様に利用するバージョンのsbtを設定します。
以上でanyenv + jenv + sbtenvの環境設定は完了です。
以前は Scala といえば IntelliJ だったと思うのですが、最近は Metals という Language Server が出てきており、Metals を使えば Visual Studio Code や Emacs などエディタを選ばずに Scala の開発ができるようになっているようです。
scalameta.metals
という extension をインストールするだけです。
extension は Scala プロジェクト以外は有効化されないはずですが[1]、私の環境では ruby のワークスペースなどにも .metals ディレクトリが出来てしまいました。基本は disable にしておいて、Scala のワークスペースでだけ手動で enable にするのが良いと思います。
VS Code のサポートについてはこちらに詳しく書かれています。
https://scalameta.org/metals/docs/editors/vscode/
[1] 公式サイト に次の記載あり。The extension activates when the main directory contains build.sbt
or build.sc
file, a Scala file is opened, which includes *.sbt
, *.scala
and *.sc
file, or a standard Scala directory structure src/main/scala
is detected.
本サイトの更新情報は、Twitterの株式会社プレセナ・ストラテジック・パートナーズエンジニア公式アカウントで発信しています。ご確認ください。
おもにJavaScriptなどのフロントエンド系のソースコードのフォーマッタです。プラグインを追加することでRubyなどの言語にも対応可能です。詳細は公式サイトを参照してください。
以下、開発プロジェクトへのインストール手順を説明します。
開発プロジェクトにおいて、yarnでnodeパッケージが管理されている前提です。
まずは、開発環境のみの依存パッケージとして、prettier をインストールします。
必要に応じて、prettier-rubyもインストールします。
なお、prettier-rubyは、gemでもインストール可能ですが、JS用のprettierと別管理にしたくないので、上記のようにnodeパッケージのプラグインとしてインストールしています。
プロジェクトルートに以下のファイルを作成します。
上記の設定は、当社で使っているデフォルトの設定です。例えば、printWidth
は、デフォルトの80だと少し狭く、フォーマットしたときに、過度に改行が入ってしまうため、120にしています。
Railsのroutesファイルなどのように、なるべく改行をせずに一行で書いてしまいたいような特殊なコードは、pretterでのフォーマットがかからないように、ignoreファイルをプロジェクトルートに追加します。
rubocopも併用しているプロジェクトの場合、rubocopに定義されているスタイル関連のルールとprettierのフォーマットが競合して、gitのpre-commitにrubocopのチェックを行っているとリポジトリにコミットできなくなってしまいます。
そういった場合のために、rubocopでprettierと競合するルールをオフにするための設定が、prettier-rubyには含まれていて、この設定をプロジェクト用の.rubocop.yml
で継承します(参考:公式サイト)。
また、これ以外にも、rubyの後置ifや後置whileなどのフォーマットをprettierにまかせてしまいたいので、以下のように.rubocop.yml
にルールを追加します。
以下、RubyMineやVisual Studio Codeの設定を各自行います。
最新のRubyMineでは、Prettierプラグインはデフォルトでインストール済なので、設定だけ行います(参考:公式サイト)。
JavaScriptやTypeScriptだけでなく、Rubyもフォーマットの対象にする場合は、設定画面で、Preferences -> Languages & Frameworks -> JavaScript -> Prettier
から、Prettier Packageを{Project Root}/node_modules/prettier
に設定した上で、Run for files
の部分でrbも含まれるように、以下のように変えておきます。
On save のチェックをいれておくと、⌘S を押したときにフォーマットがかかります。 設定保存後もprettierが動作しない場合は、一度RubyMineを再起動するとうまくいきます。
prettier-vscodeプラグインを使います。
上記プラグインをインストールした上で、以下のように、.vscode/settings.json
をプロジェクトルートに追加して、言語ごとにフォーマットの設定をします。チームメンバーのvscodeの設定状況によっては、このファイルはリポジトリにpushして他のメンバーと共有してもよいです。
なお、editor.formatOnSave
は任意の設定で、保存時に自動的にフォーマットをかけるかを設定します。
本サイトの更新情報は、Twitterの株式会社プレセナ・ストラテジック・パートナーズエンジニア公式アカウントで発信しています。ご確認ください。
zshを使うときに、補完用の情報を設定をしておくことで、例えば、git、aws-cli、dockerなどのコマンドやサブコマンドをTabキーで補完してくれるツールです。
公式サイトは、以下です。
macOSを使っている前提ですが、homebrewで簡単にインストールできます。
zsh-completionをインストールすると、以下のようなメッセージがでます。
なお、このメッセージは、brew info zsh-completion
コマンドで再表示できます。
このメッセージにしたがって、まずは、次のように .zshrc
ファイル設定します。
次に、zsh関連ファイルの権限設定を行います。これも前述のbrew info
で表示されるメッセージに従います。
前述の brew info
で表示されるメッセージの /opt/homebrew
の部分は、使用しているMacのCPUがIntel製かApple Siliconかによって異なります。
なので、環境に応じて次のようにコマンドを打ちます。
あるいは、以下のコマンドを打てばどちらの環境でもOKです。
なお、この go-w
は、g(roup)とo(thers)から(つまりuser以外から)、書き込み権限を削除(-)しています。
homebrewでgitをインストールすると、自動的に /usr/local/share/zsh/site-functions/ 以下に、git用の補完設定もインストールされるので、それ以上何もする必要はありません。
gitはmacOS標準のものもありますが、上記の補完設定のために、筆者はhomebrewでgitをインストールしなおしてしまいます。
設定がうまくいっている場合、以下のように補完されます。ブランチ名などは、覚えられないので補完を使うと便利になります。
公式サイトに説明があるので、それに従います。手順は公式サイトに記載されていて、また、迷うところもないので、ここに手順を記載するのは省略します。
設定がうまくいっている場合、以下のような補完が使えます。
aws-cliも公式サイトに従うだけですが、少しわかりにくいので、補足説明を追加します。
公式サイトは、以下です。
なお、この記事では、AWS CLI の記事に記載さた手順でインストールされている前提で補足説明をします。
前述の前提の場合、aws_completer はすでにPATHが通っているので、やることは以下の設定を.zshrc
ファイルに追加するだけです。
設定後は、zshを再起動します。
設定がうまくいっていれば、以下のようにawsコマンドの補完が効くようになります。
本サイトの更新情報は、Twitterの株式会社プレセナ・ストラテジック・パートナーズエンジニア公式アカウントで発信しています。ご確認ください。
この記事では、M1 Macでの開発環境構築でハマったところを共有するために、記載して行きます。今後、随時新しいハマりどころが発生した場合は、情報を追加していきます。
筆者の環境では、環境構築の検証もかねているので、Rosetta 2をインストールしていません。Rosetta 2をインストール済みの場合は前提が異なってくるため、ご注意ください。
また、以下のものはインストール済みとします。
rbenv
Docker Desktop(4.3.0以上)
postgresql(実行用ではなく、gem pgのビルド時に利用する想定。brewでインストールする)
※Docker Desktopは、バージョン4.3.0以降でもRosetta 2に依存している部分は残っているようですが、依存度は以前と比べて低くなっているようです。
のように、古めのRubyのバージョンをインストールすると、以下のようなエラーが発生しました。
gem ffiの公式リポジトリのissueによると、以下2つの対処法があるようです。
以下のように、RUBY_CFLAGS
を指定して、rbenvのインストールコマンドを実行すると上手く行きます。
筆者もこの方法を先に試して上手く行ったため、この後の2つめの方法を試せていません。
brew info libffi
コマンドを実行すると、以下のようなCaveatsが表示されます。
これにしたがって、環境変数LDFLAGS
、CPPFLAGS
、PKG_CONFIG_PATH
を指定して、以下のように実行すると良いとのことです(筆者は、試せていませんが掲載しておきます)。
※記事のみやすさのために、環境変数ごとにexportをしていますが、一気に複数の環境変数を指定しても良いと思います。
Docker公式サイトで説明されているように、docker-compose
コマンドはv1のdocker-composeが使われるためRosetta 2のインストールが必要です。、これまでdocker-compose
コマンドを使用していた場合は、以下のように、docker compose
コマンドを使います。
bundle install時にネイティブ拡張が含まれるいくつかのgemでインストールに失敗したのでgemごとの対処法を記載しておきます。
このgemのインストールに失敗する原因は、古いRubyをインストールしたときに出たエラーとと同じです。筆者は、gemのインストール時に発生したエラーに対しては、以下のように、brew info コマンド実行時に表示されるCaveatsの内容にしたがって対処しました。
pgは、M1 Mac特有のエラーというよりかは、Intel Macでもよく発生する、Ruby開発者ならよく見たことあるエラーですが、以下のエラーが発生します。
対処法もいつもどおりで、やり方はいくつかありますが、筆者は以下のようにbundleのbuild時のconfigを指定したのち、bundle install
を実行しました。
なお、このコマンドを実行すると設定が~/.bundle/config
に書き込まれます。
rmagickもM1固有の問題ではなく、毎回遭遇する以下のエラーが発生します。
これは、まず、imagemagickがインストールされていないことが原因で、もしインストール済でこのエラーが発生しているなら、convertコマンドへのPATHが未設定であったり、ビルドに必要なファイルが指定されていなかったりすることが原因です。
以下のように対処します。
まずは、必要なImageMagickをインストールします。Rmagickが対応しているバージョン6を、必ずインストールしてください。
次に、brew info imagemagick@6 コマンドを実行して表示される以下にしたがって、
まず、実行時に必要と思われるconvert
コマンドへのPATHを通しておきます。
念の為、以下のようにconvertコマンドが使えるかを確認しておくとよいでしょう。
次に、rmagickのビルドに必要な環境変数を指定してから、bundle installを実行します。
ここまでで、gemのインストールまで出来ました。
なお、2022年1月17日現在、筆者の環境では、この後、古いnodeをインストールしようとしてエラーが発生して失敗し、対応方法が調べきれず、まだRailsアプリケーションを実行するところまでたどり着いておりません。ただ、今後、nodeをバージョンアップさせる予定なので、新しいバージョンのnodeを利用することで、エラーを回避できる可能性があります。
上記については、後日、この記事をアップデートして共有しようと思います。