Homebrew で awscli を upgrade して、依存の keg-only python@3.8 を link する

Homebrew が提供する awscli が 2.0 になる前辺り、必要な python が python@3.8 になりました。
awscli を upgrade する際、 python を消して python@3.8 を使うようにしたログです。

環境(ブログ作成時)

• OS: macOS Mojave 10.14.6
• Homebrew: 2.2.13-74-gecea0e5
• homebrew-core (git revision eb6d; last commit 2020-04-19)
• python: Python3.7.7
• python@3.8: Python 3.8.2
• awscli: aws-cli/2.0.8 Python/3.8.2 Darwin/18.7.0 botocore/2.0.0dev12

keg-only formula と Homebrew の install 事情

Homebrew は元々、 /usr/local/bin へ直接 formula を install しません。

/usr/local/Cellar などの PATH に install して、そこから symlink を貼ります。

その中で key-only formula は「install しても /usr/local/bin に link しない」 formula です。

今回は python@3.8 が keg-only に指定されています。理由として executable の衝突回避が挙げられます。

• 前提として、現時点で Homebrew が提供している python は 3.7 系列
• python が存在する環境に python@3.8 も installすると /usr/local/bin/python3 が重複する
• /usr/local/bin/python3 を 3.7 系列に譲るために、 3.8 は keg-only として link しない

という感じかと思われます。

keg-only formula を link する前の確認

 link の前に、念の為 python が使われていないか、以下のコマンドでチェックします。

• $ brew uses --installed python

何も出力されない場合は install 済みの formulas 全てにおいて python を使っていません。
出力がある場合、その formula は python を使っています。 3.8 の link は止めた方が良いでしょう。

python@3.8 を /usr/local/bin に link する

上記のチェック時、私の環境では出力が無かった為 python@3.8 を link する事にしました。
なお、 keg-only formula を link する場合は --force が必要です。

• $ brew upgrade awscli
• 依存関係で python@3.8 が install される
• $ brew link --force python@3.8
• $ which python3 aws
  • /usr/local/bin/python3
  • /usr/local/bin/aws
• $ python3 -V
• Python 3.8.2
• $ aws --version
• aws-cli/2.0.8 Python/3.8.2 Darwin/18.7.0 botocore/2.0.0dev12

これで python3 と awscli が upgrade できました。良し良し。
ちなみに homebrew-bundle では、 link: true を付けると link してくれます。

python2 に依存した Vim plugin が無いか確認と修正対応をしたお話

2020/01/01(Wed) に python2 のサポートが終了しました。が、今の所私の周辺で問題は発生していません。

Neovim で :checkhealth を実行していると、まだ python2 provider が有効な事にふと気付きました。
「いつか python2 provider も消えるのだろうな」と悠長に考えたのが1つ目の感想。
「python2 に依存した plugin があったらマズいのでは」と思って焦ったのが2つ目の感想。
「問題は発生していない」と思っているけれど、本当にそうなのか念のために確認+対応したログです。

環境

• OS: macOS Mojave 10.14.6
• Neovim: 0.4.3
• Python2: 2.7.16 (system builtin)
• Python3: 3.7.6 (installed by homebrew)

has('python') している plugin が無いか確認

私は Neovim の plugin management に dein を使っています。

そして、plugin の install 先は ~/.config/nvim/dein を指定しているので、その先に cd して grep をかけてみます。

• $ cd ~/.config/nvim/dein/repos/github.com
• $ egrep 'has\(.python.\)' -R .

egrep のオプションの -R は、指定したディレクトリを起点に recursive に探索してくれます。

そして、渡しているディレクトリは '.' なので、 カレントディレクトリ以下の全てのファイルを対象にできます。

egrep で指定した正規表現は 'has\(.python.\)' です。これは

• まず、 vim/neovim で特定の feature が有効か確認する方法として 'has' function があります。
• そして python2 provider が有効かどうかは has('python') の実行結果で分かります。
• 加えて考慮する事として、python を括る文字が ' と " のどちらかの問題があります。
• これは面倒なので . にしました。 ['"] 2つなどでもOKです。
• 最後に、'()' は egrep パターンマッチに使う記号なので \ でエスケープします。

さて、実行結果は以下のようになりました。

前後のソースを読んではいないので、 現段階では対応が必要かもしれない plugin 一覧とします。

一時的に python2 provider を無効にする

Neovim で :help provider とすると、各 provider の説明が確認できます。
その中には provider を無効化する方法も存在しており、 python2 の場合は

• let g:loaded_python_provider = 0

と ~/.config/nvim/init.vim に書くと無効化できます。

なお、この状態で :checkhealth を実行すると

• - INFO: Disabled (g:loaded_python_provider=0).

と表示されます。

さて、これで仮に python2 provider が消えた時状態を再現できました。

先程 egrep で見付けたプラグインの動作確認を行なった結果、

• gregsexton/VimCalc
• atton/gundo.vim

が動作しませんでした。

VimCalc 対応: VimCalc -> VimCalc3

安直に「VimCalc python3」で検索をかけてみます。

そうすると、fedorenchik/VimCalc3 が見付かりました。なお、 fork 元は本家の gregsexton/VimCalc です。

お試しでインストールすると、ほぼ同じ動作。ということで VimCalc3 に乗り換えます。

gundo.vim 対応: let g:gundo_prefer_python3 = 1

さて、二度目も安直に「gundo.vim python3」でググります。

そうすると bitbucket の issue のページがヒットしました。どうやら既に対応済みだったらしく

• let g:gundo_prefer_python3 = 1

と書くことで python3 を利用するようです。動作確認もできたので、 gundo.vim はそのまま使う事にします。

まとめ

これで Neovim がいつ python2 provider を消しても大丈夫になりました。

蛇足ですが、対応した2つのプラグインは利用頻度が低く、 LazyLoad していました。

なので、仮に Neovim が python2 provider を消したとしても、気付くのに時間がかかった可能性は十分にあります。

それを排除できたので、備えあれば何とやら、ですね。

Python 3 が /usr/local/bin/python に配置されるようになった Homebrew で NeoVim の :CheckHealth をパスさせる

いつの間にか Homebrew の /usr/local/bin/python が python3 になってました。中々気合が入っている変更ですね。
私は Python そのものはあまり使わないのですが、 Neovim が使っているのでいろいろと調整したログ。

さて、この変更がある前の Neovim + Python 周りをまとめると

• $ brew install python
• python 2 系が入る
• $ pip2 install neovim
• pip2 は /usr/local/bin/pip2
• $ brew install python3
• python 3 系が入る
• $ pip3 install neovim
• pip3 は /usr/local/bin/pip3

といった感じだったのですが、変更後は

• $ brew install python
• python 3 系が入る
• pip3 は /usr/local/bin/pip
• $ brew install python@2
• python 2 系が入る
• が、keg-only の formula 。
• python2 や pip2 を使うには  /usr/local/opt/python@2/ などに PATH を通す必要がある
• 詳しくは $ brew info python@2 

という形になっているようです。

keg-only の formula を使い続けると混乱しそうなので、python@2 はアンインストール。

Python 2 系は system builtin のものを使うことにしました。

root で書き込む必要があるのでしくじった時のダメージが大きいですが……

ということで

• $ brew uninstall python@2
• $ sudo easy_install-2.7 neovim

して解決。

具体的な :CheckHealth の結果は

• before
• after

といった感じです。:CheckHealth 便利。

環境

• macOS: 10.12.6
• Homebrew: 1.5.7
• Homebrew/homebrew-core (git revision b33d4d; last commit 2018-03-03)
• NeoVim: 0.2.2
• python2.7: 2.7.10 (macOS provided)
• python: 3.6.4 (Homebrew provided)

Ubuntu 16.04 LTS で NeoVim を使う

AWS の EC2 インスタンスに Ubuntu 16.04 があったので使ってみる。
環境構築の中で NeoVim のインストールと設定をしたログ。

環境

• OS: Ubuntu 16.04.3 LTS
• apt: 1.2.24
• NeoVim: 0.2.0
• Ruby: 2.3.1p112
• neovim gem: 0.6.1
• Python2: 2.7.12
• pip2: 8.1.1
• python2-neovim: 0.2.0
• Python3: 3.5.2
• pip3: 8.1.1
• python3-neovim: 0.2.0

NeoVim 本体をインストール

基本的には neovim の wiki を参考に。

• # apt-get install -y software-properties-common python-software-properties
• # add-apt-repository ppa:neovim-ppa/stable
• Enter 押す必要があったけれど -y とか付けたら良かったのかな
• # apt-get update
• # apt-get install neovim

で neovim 本体は入ります。楽で良い。

dot_files を設定する

私は dot_files を公開しているので

• git clone https://github.com/atton/dot_files
• cd dot_files
• ./install.sh

で設定終了。備えあれば何とやら。

NeoVim の環境を整える

私が使ってるプラグインが python3 必須だったりするのでその辺も整備。

• # apt-get install -s ruby bundler
• # gem install neovim
• # apt-get install -y python3 python3-dev python3-pip python python-dev python-pip
• # pip3 install neovim
• # pip install neovim

で python2 + python3 + ruby の環境が整った。

:CheckHealth すると clipboard が無い以外は問題無い、とのことでOK。

自己診断機能便利ですよね。 brew doctor とか。

おまけ

ec2 の IP 覚えるとか domain 振るのとか面倒なので私の ~/.ssh/config はこんな感じ。

というかOSごとに default user name 違うってなんでやねん。

PyPy ソースコード読み会に参加してきた

PyPy ソースコード読み会に参加してきました。
通算3日くらい。
バージョンは Python は 2.7.2 で pypy は 2.2-dev くらいで commit は 67874:84a635eb05a7 なところ。
環境は Mountain Lion。

これだけ大きいソースを追っていくのは初。
割と分かってないところが多いので間違っていることを書いているかもしれません。

PyPy

Python で言語を定義するとそれを pypy なレベルに落として、最終的にバイナリにしてくれるみたいです。
それが rpython なスクリプトで、例えば pypy は Python の実装を Python Code で書いて、それを実行すると一旦 C なファイルになって、それをコンパイルしてバイナリを生成するみたいです。

pypy-c

公式のページにある

$ pypy ../../rpython/bin/rpython -Ojit targetpypystandalone 

をすると python で実装された python が C に落ちて pypy-c という Python 実行系なバイナリができます。
その時には、  rpython/path/to/*.py は rpython_path_to_*.c みたいに / が _ になった C コードが生成される様子。
--lldebug とかを付けて

$ python ../../rpython/bin/rpython --lldebug -Ojit targetpypystandalone 

にすると lldb とかで追えるようになります。
生成されたコードは変数に5ケタとかの番号が付いてたり goto しまくりで直接読むのは厳しいです。

ちなみに pypy は 生成した C コードや debug object を /private に置くので、しばらくしていると消えてしまうようです。
なので PYPY_USESSION_DIR や PYPY_USESSION_KEEP を設定すると良さそう。

とりあえず一旦 C に落ちてからバイナリが作られるので、バイナリを追っても python code は読めなさそう、という結論に。

Python Code を読んでいく

Pypy には大量のモジュールがあるので、それらの知りたいところだけを追おう、ということに。
なのでテストルーチンを最小限に切り出して、それを実行していく形式にしました。
個人的にテストを直接 pdb で追おうとしていましたが、 py.test で書かれてるようで、どうも通常のコードとは勝手が違って断念。
ということで test くらいからめぼしいものを拾ってきて、method 1つを実行できるようにして pdb debug で trace していくことに。
これだと python 側のコードで読めます。
ちなみにテストコード側には space とかの環境っぽいコードは無かったりしたので、 pypy/bin/pyinterpreter.py とかの インタプリタコードな pypy/interpreter/main.py から StdObjSpace のコードを拝借したりで動かし動かし。
おそらくすぐ動く小さいコードは pypy/bin/pyinterpreter.py なので足りないパーツはその辺りにあるんじゃないかな、とか思ってます。

テストを切り出してみる

parser とか astcompiler とかのソースを追いたいので

pypy/interpreter/astcompiler/test/test_compiler.py

の compile_with_astcompiler を拾ってくる。
足りない space とかは

pypy/interpreter/main.py

から拾ったり。mainmodule とか w_globals  とかも。
そんなんで作ったコードがこんな感じ。

pyparser / astcompiler

そんな感じのコードを使って pyparser を読んだり。
tokenize で lines を split したりと割と富豪的。
おかげで高速化とかされていないわけなので素直で読みやすいといえば読みやすいかも。
astcompiler は buld_ast な parse 後のコードから ast を生成する部分をちょろっと読むなど。
token の type に応じて handle_expr やら handle_binop やらの関数で parse した node を拾ってきて AST オブジェクトを new っていく感じらしいです。
あと Python VM なやつは pyinterpreter を追っていったら出てきたような。

symbol table

token から ast にする時に expr_node.type を確認していったりするのですが、 この type が syms.stmt やら syms.simple_stmt やらとガンガン if で比較していく形式。if-elif祭り。
syms.stmt の値は定数の数値なので、 expr_node.type の数値が分かっても syms の何に相当するのかが謎。
なので dir(syms) とかで syms にある attr を拾ってきて getattr(syms, attr) とかしていって逆引きテーブルを作ったりして対応を取ることに。
この辺の対応を確認する便利コードが pypy にありそうだけれどなー、とかなりつつ。
というかこいう enum みたいなコードって 書く/読む 分にはマジックナンバーが隠れて良いけれど、実行していく分にはチェックするの大変だなー、とか思うなど。特にマジックナンバーな値しか分からない時。
そういう時はやっぱり debug helper チックなのでも書いてたら良いのかな。逆引きとか。

所感 / tips / もろもろ

読んでいくというよりは実行していく、といった感じで読んでいきました。
流れが分かりやすいし使わないところは読まなくて良いので、こんな感じで読むのかー、と。

ただ、実行の仕方分からないとだいぶ大変そうだなー、と。 python 分からない。
一番単純な example とか how to reading sources とかあれば嬉しいよなー、とか。

object の class を見て関連しそうなところとかを探していったり、関数に入ったら l っていってざっくり見てから n/s るのが自然な読み方なのかも?

一見見えないところでも lldb で stepi するとアセンブラに書かれてたりするのでそれを頼りに読むとかあってすごいなー、と。

lldb の debug symbols が /private にあったので読んでたら消えたり、なんか一部のコードを単体で実行したら pypy が動かなくなったり謎ハプニングも。
ちなみに動かなくなったら hg clone しなおしでどうにか直る。
でも hg diff には引っかからなかったのでどこが壊れたのかも謎でした。

とかとかいろいろあった読み会でした。