tmux 3.1c の window 分割線を ascii character にする

2020/10/30(Fri) に tmux 3.1c がリリースされました。

という事で、恒例の EastAsianAmbiguous を ascii に変更したバージョンを作成します。
過去の作業履歴は 3.1b や 3.0a や 2.9a  に、そもそもの問題についてはこの記事にまとめています。

環境

• OS: macOS Mojave 10.14.6
• tmux: 3.1c-border-ascii 7e7a923b7cd2e7cc8d2450e8a8e20838ded13298
• Homebrew: 2.5.8-118-g2ac5cff
• Homebrew/homebrew-core (git revision ce1b1; last commit 2020-11-06)
• Font: Ricty 4.1.1

インストール方法

• $ brew install --HEAD atton/customs/tmux

でインストールできます。

今回の作業

 3.1b と 3.1c の違いはほぼ無いようなものなので、 cherry-pick で対応できました。

PS4 の Prime Video の「次に観る」リストから消した作品を再度表示させる

私は Prime Video を観る際、大体 Play Station 4 を使っています。

Prime Video は「次に観る」というリストが視聴履歴から自動的に作成される為、放送中の作品を追うのに便利です。

観終わった作品をリストから削除していると、誤ってまだ観ていない作品を削除してしまいました。

すると、ウォッチリストに追加している作品にも関わらず、リストに表示されなくなりました。それを解決したお話です。

環境

• Play Station 4 システムソフトウェア: 7.51
• Prime Video: 3.13

元に戻す方法

作品を「次に観る」リストに再度表示させるには

• Amazon.co.jp にログイン
• [マイストア] -> [おすすめ作品を正確にする] -> [興味が無い商品] を表示
• 再度表示させたい作品の「興味がありません」のチェックを外す

事で解決します。

余談： 「次に観る」に表示されなくなる条件

非表示になる条件は以下の2つがあります。

• 観ていた作品を視聴履歴から削除する
• 「興味が無い商品」として登録する

特に後者の場合、ウォッチリストに追加していても表示されません(前者は未確認)。

PS4 の Prime Video で「リストから削除」を実行すると「興味が無い商品」に登録される、後者の挙動を取ります。

Web の Prime Video では「このシーズンを表示にする」という名前に変わっていますが、こちらも後者の挙動を取ります。

なので「興味が無い商品」の登録から作品を削除すると、リストに再度表示されるようになります。

参考

• Amazon | 本, ファッション, 家電から食品まで | アマゾン
  
• Amazon.co.jp: プライム・ビデオ: Prime Video
• Amazon プライムビデオの”次に観る”から消す『視聴履歴を確認』

GitHub へ push した際に Docker Hub で docker image を自動 build する

過去に「GitHub Actions で複数の Dockerfile の build と DockerHub への push を自動化した」という記事を書きました。

前回は image の build を GitHub で行なっていましたが、今回は Docker Hub で build するように変更したお話です。

Docker Hub で docker image を build する

GitHub と連携した automated build という機能を利用しました(設定方法はドキュメント参照)。

前回同様、GitHub に push すると自動的に Docker Hub に image が更新されます。

これまた前回同様、以降は作業ログ等です。

何故構成を変更したのか

image を更新する為に Docker Hub を触っていた時、 GitHub 連携の存在に気付いた為です。

ちなみに、更新していた image は latex-make というもので、MacTeX をインストールせずに LaTeX を実行できる image です。

更新内容は TeX Live 2019 から TeX Live 2020 へのアップデートでした。

GitHub Actions 作成時に気にしていた3つの条件のゆくえ

過去の記事では以下の3つの条件を気にしていました。

• Dockerfile が増えた場合も自動で対応する
• Dockerfile や関連ファイルに更新が無い Image は Push しない
• GitHub Actions だけでなく、ローカルの環境でも build できる

第1条件と第2条件は、 Repository を分割して解決としました(latex-make, webpage-title)。

第3条件はビルドスクリプトをローカルマシンに残す事で解決としました。

構成を変更して良かった点

• 他の image の README を参考にした結果、 README が整備された
• latex-make には使用例が無かったので追記した
• shields.io を利用して image のサイズ等のバッジを追加
• GitHub/Docker Hub の README を(手動で)統一
• Docker Hub に automated build のログが残るようになった
• 前回は「push したユーザは atton, push 時刻」程度の情報しか無かった
• ログイン情報を書くが必要無い
• 連携時に Docker Hub から GitHub へ権限を要求しているので docker login を実行する必要は無い
• 具体的に言うと GitHub Actions ではログインパスワードを Secrets に書いていた
• なので、Docker Hub のログインパスワードを変更後、Secrets を更新しないと docker login に失敗する

構成を変更して良くなかった点

• 移行作業が手作業だった
• 対象となる docker image が2つのみだったので、手作業で移行を行なった
• 仮に docker image が多かった場合、移行スクリプト等を書く必要があったかもしれない
• 第2条件が若干緩くなった
• master が更新された際に build が行なわれるので、 README だけの変更 commit でも build が発生する
• git の tag をトリガーにして build する、等の設定で修正可能
• しかし現状の image の tag は latest しか無いので放置中

GitHub Actions で複数の Dockerfile の build と DockerHub への push を自動化した

私は作成した Dockerfile を GitHub で公開しています(前回の記事の atton/webpage-title も含む)。
Docker Image を手動で管理するのは面倒なので、何らかの形で自動化する事にしました。
最終的に、 Dockerfile が更新された際に build して DockerHub に push する GitHub Actions を作成しました。

GitHub Actions を作成する際に考慮した条件

• Dockerfile が増えた場合も自動で対応する(現時点では2つ)
• Dockerfile や関連ファイルに更新が無い Image は Push しない
• GitHub Actions だけでなく、ローカルの環境でも build できる

具体的な GitHub Actions の内容

作成した .github/workflows/build-and-push.yml とbuild.sh は以下です(commit: 427f143)。

	# Original: https://github.com/atton/dockerfiles/blob/1566be5489c34ba743dd5735f6584d3ef213cdb5/.github/workflows/build-and-push.yml
	name: Build and Push Docker Images
	on: push
	jobs:
	build-and-push:
	runs-on: ubuntu-latest
	steps:
	- name: Clone repository
	run: git clone https://github.com/atton/dockerfiles
	- name: Build and Push Docker Images
	run: sh dockerfiles/build.sh ${{ secrets.DOCKER_PASSWORD }}

view raw build-and-push.yml hosted with ❤ by GitHub

	# Original: https://github.com/atton/dockerfiles/blob/1566be5489c34ba743dd5735f6584d3ef213cdb5/build.sh
	#!/bin/sh
	cd `dirname $0`
	git show --name-only
	if [ -n "$1" ]; then docker login -u atton -p $1; fi
	for name in `ls`; do
	if [ ! -d $name ]; then continue; fi
	if [ ! -f $name/Dockerfile ]; then continue; fi
	tag="atton/$name"
	docker build --compress --pull -t $tag $name
	git diff-tree --no-commit-id --name-only -r master | grep "$name/" >/dev/null 2>&1
	if [ $? -eq 0 ]; then docker push $tag; fi
	done
	if [ -n "$1" ]; then docker logout; fi

view raw build.sh hosted with ❤ by GitHub

自動化できたので手動 push の必要は無くなりました。べんり。

これ以降は作業ログなどを書いておきますが、かなり長いです。

第一条件: Dockerfile が増えた場合も自動で対応する

この条件については、特定の構成をしているディレクトリを build 対象にする事で対応しました。具体的には

• ディレクトリ名は任意
• ls と [ -d ] で確認
• ディレクトリの直下に Dockerfile が存在する
• ls と [ -f ] で確認

といったディレクトリです。なお、ディレクトリ名は Docker Image の tag を決める際に使っています。

第二条件: Dockerfile や関連ファイルに更新が無い Image は Push しない

Docker Image を自動 build する際、最初は elgohr/Publish-Docker-Github-Action@master を使っていました。

ここで問題が発生。README.md を変更しただけの commit でも Docker Image の更新が行なわれました。

幸い、GitHub Actions の step では if が使えるようなので試してみましたが改善せず。

elgohr/Publish-Docker-Github-Action@master のソースを確認すると、 action.yml に if はありませんでした。

なので elgohr/Publish-Docker-Github-Action@master は利用しない方針に変更。
使わない事になりましたが、 entrypoint.sh に書かれた(docker login/logout など)内容は参考にできそうです。

さて、次は「Dockerfile や関連ファイルに更新が無い」事を判定をできれば解決しそうです。ググってみると

• $ git diff-tree --no-commit-id --name-only -r ${{ github.sha }}

で確認できるとの事。ではこれを grep して exit code で判定すれば解決、しませんでした。

更新の有無に関わらず、全ての grep の exit code が 1 になっていました。
加えて、ローカル環境では想定通りの exit code が得られるので、どうやら原因は実行環境固有のようです。

「ローカルでは動くが、別環境では動かない」という悲しい事態なので、 printf debug で少しずつ状態を確認していきます。

• git は存在するか
• git の version は何か
• git は実行できるか
• remote origin は存在するか
• commit log は辿る事ができるか
• grep の version は何か
• ...

結果、「actions/checkout@master を使うと repository の情報が消える(?)」事が判明しました。具体的には

• git コマンドは実行できる
• git show を行なうと、全ファイルが新規作成扱いになっている
• origin を fetch しても commit が取得できない

という謎の状態でした。その為、 actions/checkout@master は利用せずに直接 git clone を実行。
clone した repository では diff-tree が実行可能で、更新の有無が判定可能になりました。

余談: 第二条件の部分を書いている時に思った事

• elgohr/Publish-Docker-Github-Action@master のソースを確認すると、 action.yml に if はありませんでした。
• Pull Request を作成して提案する手がある
• 「ローカルでは動くが、別環境では動かない」
• GitHub で動作 Image を提供している可能性がある
• 「actions/checkout@master を使うと repository の情報が消える(?)」
• 今は git clone で対応できるが、 branch の指定といったオプションに対応できない

第三条件: GitHub Actions だけでなく、ローカルの環境でも build できる

この条件は「ローカル環境でも Docker Image を作成可能」にする為につけました。メリットとしては

• 問題発生時の再現に使用できる
• commit 前の Dockerfile も試しに build できる
• 新しい Image 作成時の build が楽

等があります。なお、この条件は build.sh に与える引数の有無で解決しました。

まとめ

結構な文量になりました。debug の説明を含めると長くなりますね。

結果的に「uses を排除して自前の run で記述する」というオレオレ GtiHub Actions で解決。

前回も書いた気がしますが、「個人的には十分満足しているので良しとします。」

参考文献や関連した文献など

• GitHub - atton/dockerfiles: Dockerfiles of published my docker images
• atton.blog: chromium-browser を使って記事のタイトルを取得する
• atton's Profile - Docker Hub
• Set TZ in "latex-make" image · atton/dockerfiles@427f143 · GitHub
• Publish Docker · Actions · GitHub Marketplace · GitHub
• Setup GitHub Actions for publish atton/webpage-title · atton/dockerfiles@6781d4e · GitHub
• Workflow syntax for GitHub Actions - GitHub Help
• GitHub - elgohr/Publish-Docker-Github-Action at 5d8ac991f54837cdbd0b34fc627e9e83c500fa43
• Publish-Docker-Github-Action/action.yml at 5d8ac991f54837cdbd0b34fc627e9e83c500fa43 · elgohr/Publish-Docker-Github-Action · GitHub
• Publish-Docker-Github-Action/entrypoint.sh at 5d8ac991f54837cdbd0b34fc627e9e83c500fa43 · elgohr/Publish-Docker-Github-Action · GitHub
• Find what files changed in a pushed commit? - GitHub Actions - GitHub Support Community
• Checkout · Actions · GitHub Marketplace · GitHub

chromium-browser を使って記事のタイトルを取得する

私はブログに記事を引用する際、 URL だけ書く事はあまりしません。
何かの文字列に関連付けたり、記事のタイトルに関連付けます。特に後者は参考文献の場合によく行ないます。
これが結構面倒なので、タイトルを取得する Docker Image を作りました、というログです。

環境

• OS: macOS Mojave 10.14.6
• Docker for Mac: version 19.03.8, build afacb8b

実行例

• $ docker run --rm atton/webpage-title 'https://attonblog.blogspot.com/2020/04/upgrade-awscli-with-linked-python38.html'
• => atton.blog: Homebrew で awscli を upgrade して、依存の keg-only python@3.8 を link する
• '、' は curl で取得すると escape されて 、 になる事についても問題無し。

作成した経緯

最初は curl に grep で title タグを取得する、くらいの shellscript を使っていました。

それが次第にタグの attributes を考慮したり、sed を挟んだり、と色々拡張する事に。

最終的に『header に title は無く、JavaScript で後から設定する』サイトに遭遇。これは curl では厳しい。

この際ブラウザを動した方が色々と問題解決できるのでは、という事で chromium を headless で動かす事にしました。
DockerHub の repository は atton/webpage-title で、Dockerfile は GitHub に置いてあります。

記事のタイトルを取得する為だけに大仰なのでは、という感もあります。
ですが、現状タイトルの取得に失敗した事が無いので、個人的には十分満足しています。

tmux 3.1b の window 分割線を ascii character にする

2020/05/04(Mon) に tmux 3.1b がリリースされました。
という事で、いつも通り EastAsianAmbiguous を ascii に変更するバージョンを作成します。
過去の作業履歴は 3.0a や 2.9a や 2.8 に、そもそもの問題についてはこのこのポストにまとめています。

環境

• OS: macOS Mojave 10.14.6
• tmux: 3.1b-border-ascii 526f000f29abadeef9f804bb9aea5291b913a312
• Homebrew:  2.2.15-2-gb06a7af
  • Homebrew/homebrew-core (git revision 0058c; last commit 2020-05-04)
• Font: Ricty 3.2.2

インストール方法

• $ brew install --HEAD atton/customs/tmux

でインストールできます。

本家との diff : utf8proc を使わない

homebrew-core にある本家 tmux は再度 utf8proc を採用しました。

しかし、 utf8proc は現時点の最新バージョンである 2.5.0 でも EastAsianAmbiguous 対応はされていません。

前回(2.3, 2.2.0)のように utf8proc を変更する選択肢もありました。

ですが、 tmux のソースを読むと utf8proc が無い場合 wcwidth を使うようなので、変更しない選択肢もありそうです。

試しに utf8proc を抜いてビルドした tmux を軽く触っても、特段違和感は無し。

とりあえず YAGNI の精神で、今回は utf8proc を使わない事にしました。

前回との diff : atton/tmux の default branch を master から border-ascii に変更

これは tmux へパッチを当てる運用方法の変更です。

ローカルで設定している remote repository は以下の2つ。

• origin: atton/tmux
• upstream: tmux/tmux

upstream を fetch して origin に反映させつつ、リリースがあれば対応するパッチを当てる、という運用でした。

ここで面倒だったのが、両方の master の使い分け。

例えば upstream/master の変更を origin/master に適用する時は

• $ git fetch upstream
• $ git checkout origin/master
• $ git rebase upstream/master

と、prefix を指定する必要があります。それに加えて、紛らわしいのも改善したい。

そこで、atton/tmux の master は削除して default branch を border-ascii に変更。

そしてローカルの tmux は master の remote tracking branch を upstrem/master に指定。具体的には以下のような感じ

• $ git checkout master
• $ git branch -u upstream/master

これにより master は tmux/tmux に追従し、他のブランチは atton/tmux に反映される、という状態にできました。

前回との diff : GitHub Actions の追加

GitHub Actions を2ヶ所で利用しています。

1ヶ所目は atton/tmux で、centos 環境で make 可能かチェックしています。

2ヶ所目は atton/homebrew-customs で、macOS 環境で make 可能かチェックしています。

GitHub Actions では mac と docker が使えるので、様々な環境下でテストできる点が良いですね。

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 してくれます。

pry 0.13.0 で後方互換性を保ちつつ history file の path を設定する

pry が 0.13.0 になった際、実行履歴ファイルの指定方法が変更になった事への対応。加えて後方互換もつけたログ。

pry の警告(ruby 2.7.0 + pry 0.12.2)

ruby 2.7.0 で pry 0.12.2 を起動すると、以下のような警告が出ていました。

	<main>:1: warning: __FILE__ in eval may not return location in binding; use Binding#source_location instead
	/usr/local/bundle/gems/pry-0.12.2/lib/pry/commands/whereami.rb:40: warning: in `eval'
	<main>:1: warning: __LINE__ in eval may not return location in binding; use Binding#source_location instead
	/usr/local/bundle/gems/pry-0.12.2/lib/pry/commands/whereami.rb:41: warning: in `eval'
	<main>:1: warning: __FILE__ in eval may not return location in binding; use Binding#source_location instead
	/usr/local/bundle/gems/pry-0.12.2/lib/pry/method/weird_method_locator.rb:88: warning: in `eval'
	<main>:1: warning: __FILE__ in eval may not return location in binding; use Binding#source_location instead
	/usr/local/bundle/gems/pry-0.12.2/lib/pry/method/weird_method_locator.rb:80: warning: in `eval'

view raw warning.txt hosted with ❤ by GitHub

私は怠惰なエンジニアなので、問題が発生するまでは様子見をする事にしました。

pry 0.13.0 Released

そして、2020/03/21 に pry の version 0.13.0 がリリースされました。
素晴らしい事に起動時に例の警告が出ません。 pry の開発陣に感謝ですね。
しかし、これでハッピーエンド、という訳にはいきませんでした。

Pry.config の変更

私は pry の history file の path を指定していました。具体的な設定は以下。

Pry.config.history.file = File.expand_path('path/to/history')

view raw old_config.rb hosted with ❤ by GitHub

0.12.2 はこの設定方法で問題ありませんでした。
しかし、 0.13.0 では設定方法が変わったようで、以下のように NoMethodError が発生します。

	Error loading /root/.config/pry/pryrc: undefined method `file=' for #<Pry::History:0x00005624d9ce6298>
	Did you mean? filter
	/root/.config/pry/pryrc:1:in `__pry__'

view raw error.txt hosted with ❤ by GitHub

という事で設定方法を調べてみます。

設定方法探し

さて、指針も無く彷徨っても仕方が無いので、まずはそれらしい場所にあたりをつけます。

設定時、 Pry.config と書くので、 Config class か module あたりが無いか探します。

• $ git grep Config

すると lib/pry/config.rb に Config class がありました。

流し読みしつつ、 history で検索します。そうすると history に関連するコードの集まりを見付けました。

さらに言えば history_file なる attribute がありますね。とてもとても怪しい。

Pry.config.history_file の値を pry で確認すると、今書き込まれている history の path でした。

変数が特定できたので、まずは path を代入してみます。 弾かれないか心配でしたが特に問題無し。

pryrc で Pry.config.history_file を設定すると、指定した path に history が書き込まれました。これで解決。

なお、history_file 辺りを blame して commit を確認すると

`Pry.config.history.file` becomes `Pry.config.history_file`

とありました。なので調べた結論で正しそうです。

0.13.0 以前の history との互換性

さて、 pry 0.13.0 で history file の path を指定できました。

しかし bundler で gem を管理していると、バージョンが異なる pry が複数、なんてケースもあると思います。

幸い history file の中身は plain text なので、バージョン毎の違いは恐らくありません。
各 pry で同じ history の path を指定する事で、今まで通りバージョンに関わらず共通の history を参照できるはずです。
ということでバージョンが低い pry も考慮に入れた pryrc が以下。

	@history_path = File.expand_path('path/to/history')
	if Pry.config.respond_to?(:history_file=)
	Pry.config.history_file = @history_path.clone
	else
	Pry.config.history.file = @history_path.clone
	end
	remove_instance_variable(:@history_path)

view raw new_config.rb hosted with ❤ by GitHub

• respond_to? でバージョン確認
• path は instance variable で一時的に定義して最後は消す

といった感じにしました。今の所は問題無く動作しています。

neovim + deoplete で kebab-case の補完をする

kebab-case(単語をハイフンで区切る) は snake_case や camelCase に比べ、比較的使われていないと思います。
ですが、 apt-get や docker-compose を打っていると少し利点を感じました。

• 「Shift Key を押さなくて良い」

怠惰な私にとって採用理由として十分。なので zsh で使う function は kebab-case で記述しています。

さて、ここで小さな問題が発生しました。
neovim で利用している補完プラグインの deoplete が、default の設定では kebab-case を補完してくれない。
と、いうことで kebab-case も補完対象にするように設定したログです。

環境

• OS: macOS Mojave 10.14.6
• zsh: 5.7.1 (x86_64-apple-darwin18.2.0)
• neovim: v0.4.3
• deoplete: master(記事執筆時 6e01000280)
• Python: 3.7.6
• pynvim: 0.4.1

補完の設定

まず、補完の対象を設定する変数などが無いか、:help deoplete で探します。

ありました。keyword_patterns で filetype 別に正規表現を指定すれば良さそうです。
というか ruby の補完サンプルもありますね。末尾の ! や ? に対応している。便利そう。

話が逸れました。まず、kebab-case にマッチしそうな正規表現として

• 最初の文字は alphabet と '_'
• それ以降は alpabet と '_' と '-' が0回以上繰り返される

とします。これを具体的な正規表現にすると

• [a-zA-Z_][a-zA-Z_-]*

で良さそうです。これを filetype zsh の補完に設定します。
何故 sh でなく zsh かと言うと、 sh では kebab-case のfunction が定義できない為です。

設定後、きちんと補完されるようになりました。良し良し。

おまけ(他の定義とか)

これで deoplete の補完対象の設定ができるようになりました。
zsh 以外の普段良く使う filetype の補完設定もしておきます。

• ruby: 先程発見した ruby の補完設定で、先頭に '@' を加えたもの
• text: 英数字も含めて補完対象を広めにしたもの
• _: help にあった定義をそのまま利用。なお、この設定は全 filetype に適用されます

これらを鑑みて設定した、私用の具体的な keyword_patterns の設定はこんな感じ。以下抜粋。

	let s:keyword_patterns = {}
	let s:keyword_patterns['_'] = '[a-zA-Z_]\k*'
	let s:keyword_patterns['ruby'] = '[a-zA-Z_@]\w*[!?]?'
	let s:keyword_patterns['text'] = '[0-9a-zA-Z][0-9a-zA-Z_.-]*'
	let s:keyword_patterns['zsh'] = '[a-zA-Z_][a-zA-Z_-]*'
	call deoplete#custom#option('keyword_patterns', s:keyword_patterns)

view raw deoplete_keyword_patterns.vim hosted with ❤ by GitHub

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 パターンマッチに使う記号なので \ でエスケープします。

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

	~/.config/nvim/dein/repos/github.com $ egrep 'has\(.python.\)' -R .
	./atton/gundo.vim/autoload/gundo.vim:elseif has('python')"
	./Shougo/denite.nvim/test/.themisrc: call themis#log('has("python"): ' . has('python'))
	./tyru/open-browser.vim/autoload/vital/_openbrowser/Web/HTTP.vim: if !has('python')
	./gregsexton/VimCalc/plugin/vimcalc.vim:if has('python')
	./gregsexton/VimCalc/plugin/vimcalc.vim: if has('python') != 1
	./gregsexton/VimCalc/plugin/vimcalc.vim:if has('python')
	./haya14busa/dein-command.vim/autoload/vital/_dein_command/Web/HTTP.vim: if !has('python')

view raw egrep-result.txt hosted with ❤ by GitHub

前後のソースを読んではいないので、 現段階では対応が必要かもしれない 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 を消したとしても、気付くのに時間がかかった可能性は十分にあります。

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