Python

Python が嫌いだ。だけど、そうもわがままを言ってるわけにもいかない場合がある。“最低限の作法"さえも覚えているのがいやなので、それを書いておく。

Python に限らず、違う言語の version で、違う version のライブラリがあった場合、その動作を確約できない。言語仕様自体も刻々と変わっていく。そこで、言語自体のバージョンとライブラリのバージョンをそれぞれ管理する必要がある。Rust では前者(言語の管理)は rustup、後者は cargo と言われる、別々のプログラムが用意されている。

Python はこれが酷い。pipenv, pyenv, venv, virtualenv, conda-env となにがいいのかわからないし、名前が似ている。ライブラリを入れるのは pip なので、普通に考えたら、pipenv がいいような気がする、だが、これはこれで、昔はカリスマとまで言われたメンテイナーが実は他人の労働を搾取するようなやなやつで干されたりとごたごたが多い。1

他の言語が完璧とまではいかなくてもこう言った機能を導入していく中で、相対的にパッケージマネージメントに対するインフラ整備が遅れ、輪にかけてなんかイマチュアな罵倒大会が繰り広げられていてその頃、丁度 python を作ったグイドもコミュニティの反発に愛想尽かして言語策定責任者から退くなど、なんかダセェな距離とっておこうみたいな感じになった。

こう言うと、初めての言語として python おすすめされたんだけどどうなんですか的になことを聞かれそうだけど、それでもやっぱりいいのではと思います。僕だってすごっくお世話になったし。

でそろそろ落ち着いたし、python2 何だか python3 何だかと言うのも python3 になったようだし、 今時点で python 自体の version に関しては pyenv を使う模様。

brew install pyenv
pyenv install 3.8.3
pyenv global 3.8.3
echo -e 'if command -v pyenv 1>/dev/null 2>&1; then\n  eval "$(pyenv init -)"\nfi' >> ~/.zshrc

これで、システムの python に手をつけず、僕が利用する時は python 3.8.3 が使われる。でライブラリの管理は python 3.5 から組み込まれている venv を使う。以前はプロジェクトごとに venv を作っておいたのだが、それも忘れるし、よっぽど大きなプロジェクトになった場合はそうするとして、なにも考えない場合の venv を考える。

python -m venv ~/.venv/py38
echo 'source ~/.venv/py38/bin/activate' >> ~/.zshrc

これで、 pip やるたびに、 py38 と言う仮想環境にパッケージを入れることになる。なんかミスったら、この venv ごと消せばいい。 もし他人のコードと合わせることがって、干渉したとしても、とりあえず干渉していると言う事実は示せる。venv をどこに入れればいいのかと言う慣習が見つからなかったので、適当に ~/.venv としたが、いいのだろうか。わからない。

あとは人に渡すときには、

pip freeze > requirements.txt

としておくことで、ライブラリレベルでなにを使ったかの一覧が出る。ただ、そのプロジェクトで実際に使っているかどうはは保証していない。ただ環境を一緒にするだけ。


  1. 1年半くらい放置されていたし、挙句、こう言った批判は喧嘩になったりしていて、それもなんかしょぼい。 ↩︎