1 minute read

TL;DR

  • システムの Python と普段開発に使う Python を分けたいなら Homebrew/Linuxbrew でいいじゃん
  • 3.5 と 3.6 とかの違いを気にするのはローカルマシンじゃなく CI とか Docker でやろう

Pyenv と Anaconda の環境を消した

入社したあとに「俺もよくわかんないけどこれを入れろ」とか言われて Pyenv と Anaconda を入れさせられた。あとで知ったがその人は Linux を使ったことがなくて、その場でググった Qiita の記事の内容をそのままわたしに伝えただけだった。それ以来惰性に惰性を重ねて Pyenv と Anaconda の併用を続けてきたが、さすがに意義を見いだせなくなってやめた。

個人の PC から Pyenv を取り去ったのは結構前。会社の PC からも最近取り去った。 rm -rf ~/.pyenv をしてOSを再起動したらとりあえず大丈夫だった。

Python2 と Python3 をひとつのマシンで共存させたいなら別に OS 標準のパッケージマネージャーでも可能だし、Homebrew や Linuxbrew で Python3 だけインストールしてもいい(もちろん両方インストールしてもいい)。

たまに pip3 install と打つべきときに pip install としてしまって、 Python3 から使おうとするとモジュールのインストールができていないと言われることがあるが、それ以外のトラブルはない。それも python3 -m pip install とすればいい話だし。

なぜやめられなかったのか

  • 惰性
  • 怠慢

正直なところなぜ今までやめなかったのかわからない。会社では基本 Python3.5 以降しか使わないし、単一の Python のバージョンしか必要としていない。CI などがコケて複数のバージョンをサポートするためには都度 Docker コンテナか Vagrant を準備すれば十分だし。

なぜやめたかったのか

環境変数関連の不具合

きっかけになったのが、 Vim が参照している Python とシェルが参照している Python が違う問題。おかげでシェルからは使えるものが Vim からは使えないとかいうことが起き、それを機にやめようかと考え始めた。

結局 Anaconda も Pyenv も環境変数をどういじっているのかよくわからないし、上述のように 3.5 と 3.6 とを共存させたいというモチベーションもほとんどなかったので、余計なことせず単一のバージョンを普通にインストールしようと思い始めた次第。

conda コマンド使わない

弊社ではパッケージ管理を conda でやっている人がわりといるが、わたしは pip を使うことにこだわっている。 conda は基本使わないようにしていたので、移行後も特に困ることはなかった。

Windows ではたまにふつうに pip install ができないものもあって、ちょっと面倒だが、わりと有名なモジュールなら親切なのでドキュメントが整備されていたりする(xgboost とか)。今のところ大きく困っては居ない。

どのようにバージョンごとの差異を確認しているか

今までは conda で仮想環境を作って 3.5 とか 3.6 とかやっていたが、今は virtualenv venv を各プロジェクトごとに作っている。これだとホストマシンにインストールされている Python のバージョン1の仮想環境しか作ることができないんだけど、別に困っていない。

3.5 と 3.6 の両方で動くことを確認するとかは、基本的に「諦めて単一のバージョンのみ保証する」か、「CI でチェック」するようにしている。

単一のバージョンのみ保証するのは、たとえば環境ごと Docker に閉じ込めてしまって開発もテストも本番もバージョンは「ぜったいにコレ」と言えるものに固定するのはいまや難しい話ではない。

複数の処理系をマシンに用意して実行する必要はなくて、ほげほげ CI みたいなサービスのおかげで複数のバージョンでテストをすることなんて結構簡単。複数のバージョンをサポートしないといけないスクリプトはそのようにする。

結論

  • 使う必要がないものを無意味に使わない。
    • 大は小を兼ねるかもしれないが大きすぎて不都合なこともある。
  • 「やめたいとき」がやめどき

  1. 基本3.6 [return]