ぽよメモ

レガシーシステム考古学専攻

Python開発環境メモ（2019）

ぷよぐやみんぐ python Mac

これは何

2019/3現在における，Pythonとそれを取り巻くツールを活用した開発における，個人的プラクティスをまとめたものです．主にpuddingが人に教える時に自分で参考にするためのものです．
正確性にはできるだけ万全を期していますが，間違っていたらコメントして欲しいです．

言いたいこと

無駄に長い記事を読みたくない人向けに簡潔にまとめておきます

  • 自分の環境をできるだけ把握しておく
  • Python 2.xを使うな．Python 3.5未満を使うな．
  • Pyenvで複数バージョンを導入
  • Pipenvで仮想環境とパッケージを管理
  • エディタはPyCharmかVSCodeがおすすめ

Pythonとは

スクリプト言語であり，コンパイルによって実行ファイルを作成するのではなく，インタプリタと呼ばれるプログラムによってソースコードを読み取り，順次実行する形式を取ります．
大きく分けて以下の2つのバージョンが現在でも使われており，環境によって色々かわって来ます．

  • 2.7.x：早く滅びろ
  • 3.x：3.5以下は早く滅びろ

これらにはある程度の文法の互換性が存在しますが，だいたいSyntax Errorで落ちるので，注意してください．今から使うならPython 3.6以降以外の選択肢はありません．もし職場等でPython 2.xを使うことを強制されたなら，落ち着いてハラスメント窓口に駆け込むか，退職願いを書いて転職した方が良いでしょう．

python というコマンド

まず，Python初学者（というかプログラム初学者）に知っていて欲しい事があります．それは

python や python3 というコマンドは魔法ではなく，
単にそのシステムのどこかにある実行可能なバイナリファイルを指しているだけ

ということです．つまり，pythonという実行ファイルが存在していなければ当然Not foundみたいなことを言われてしまうし，pythonコマンドの指す実体がPython 2.xかもしれないしPython 3.xかもしれません．当たり前のことですが，Python 2.xに対してPython 3.xの文法で書いたPythonスクリプトを渡しても，Syntax Errorにより実行できない場合がほとんどでなので，自分の今の環境における python コマンドとは一体どこを指しているものなのか常に意識した方が良いでしょう．

複数バージョンの共存

さて，前節においてpythonというコマンドは，どこかにある実行ファイルを指していると言いましたが，これはつまり，pythonというコマンドのさす場所を変えれば，同じpythonというコマンドで全く別のバージョンのPythonを実行できるということを意味しています．これにより自分の環境で任意のPythonバージョンを共存させることを目指したのがPyenvです．

github.com

残念ながらWindowsでは利用できませんが，WSLやMac，Linuxなどでは簡単に利用できるため，多少ちゃんと開発をするならばぜひ導入してほしいツールです． Pythonしか開発しない！なんて人はたぶんいないので，このpyenvのような~~env系を簡単に扱えるラッパーであるanyenvをインストールするのがおすすめです．以下のURLを参考にインストールしてください（まだ古いリポジトリの話がネット上には散見されるので注意してください）．

qiita.com

# pyenvをインストール
$ anyenv install pyenv
# シェルを再起動
$ exec $SHELL -l
# Pyenvコマンドが使えるようになっていれば成功
$ pyenv versions
* system

このsystemというのは，そのOSにインストールされている（macならデフォルトで入っているものや，brewでインストールした）Pythonを指しています．

バージョンを指定してインストール

Pyenvは任意のバージョンのPythonのインストールと，python（またはpython3）コマンドの指す実体を変えるだけのものであるので，まずはPythonをインストールする必要があります．インストール時にビルドするため，依存ライブラリが必要となることに注意が必要です．macOSでは少し厄介になることが多く，特に最新のバージョンのmacOSにアップグレードすると大抵死ぬので，そういうときはpyenvのリポジトリのIssueやWik*1を読むと良いでしょう．

# インストールできるバージョンの一覧
$ pyenv install --list
# とりあえずPython 3.7.2をインストールする
# 依存関係をインストール
$ brew install openssl readline sqlite3 xz zlib
# Macでは以下の様にする
$ CONFIGURE_OPTS="--with-openssl=$(brew --prefix openssl)" pyenv install 3.7.2

pyenvには「global」と「local」という考え方があります．globalは，そのシステム内でpythonコマンドを使ったときに基本的に呼ばれるPythonのバージョンを指定し，localは特定のディレクトリ以下でpythonコマンドのバージョンを上書きすることができます．

# python -> システムにインストールされているPython 2.7.x
# python3 -> Python 3.7.2
# になるようにグローバルを設定する
$ pyenv global system 3.7.2
$ python -V
Python 2.7.14
$ python3 -V
Python 3.7.2
# local-testディレクトリ以下で使うバージョンを変える
$ mkdir local-test
$ cd local-test
# .python-versionというファイルが作られる
$ pyenv local 3.7.2
$ ls -a | grep python-version
.python-version
$ python -V
Python 3.7.2

これは個人的な考えですが，基本的にglobalはsystemのPythonを参照するようにし，pyenvはあくまで任意のバージョンのPythonを簡単に導入するためのもの，と割り切った方が何かとトラブルが少なく済むと思います．

$ pyenv global system

実際に呼ばれるPythonのパス

pyenvはPyenvのインストールされたディレクトリ以下にあるshimsディレクトリ以下に，インストールされた各バージョンのPythonインタプリタに対してシンボリックリンクを張ります．そのため，pythonコマンドで呼ばれるPythonがどこにあるかを調べようとしても，すべてそのシンボリックリンクを指してしまいます．本当のパスを知りたいときはpyenv whichを使います．

$ which python3
{{ pyenvのルートディレクトリ }}/shims/python3
# 本当のパスを調べたいとき
$ pyenv which python3
{{ pyenvのルートディレクトリ }}/versions/3.7.2/bin/python

仮想環境

さて，複数バージョンの共存は出来るようになりました．次は，各プロジェクトごとにPython環境を分けましょう．プロジェクトとは，例えばあるWebアプリケーションなど一つの機能のまとまりを指します．GitHubのリポジトリ==プロジェクトと考えて良いです．そして仮想環境とは，まぁ要するに各プロジェクトごとにそれぞれPythonインタプリタを用意する，ということを指します．プロジェクトごとに新しくPythonをインストールするというイメージです．これには以下の様なメリットが上げられます．

  • 問題の切り分けを簡単にできる
    • モジュールの依存関係，バージョン違いによる挙動の変更など
  • 必要なモジュールのみから構成されるため，IDE等への負荷軽減になる
  • 自分以外のメンバーも同じ環境を再現しやすい

そのため，本当に簡単なスニペットレベルのコードを除いてほぼ必須だと思っています．僕個人は使ったことのないモジュールを試用するとき，標準ライブラリだけでは足りないレベルの使い捨てスニペットを作るときなど比較的軽い用途でもどんどん環境を切り分けています．
Pythonでは非常にややこしいことにこれを実現する方法が複数存在し，どれがベストかは人によると思いますが，個人的な見解を以下に書いておきます．

Pyenv + Pyenv-virtualenv

github.com

pyenv-virtualenvというプラグインを導入しPyenvで仮想環境を作る．

  • 良いところ
    • 操作をPyenv系のコマンドに集約できる
    • Pythonのバージョンを変更できる
  • 微妙なところ
    • pyenv versionsコマンドの一覧がどんどん圧迫される
    • 結局パッケージの管理はpip
    • Windowsでは使えない
# pyenv-virtualenvをインストールする
$  git clone https://github.com/pyenv/pyenv-virtualenv.git $(pyenv root)/plugins/pyenv-virtualenv
# `pyenv virtualenv {{ バージョン }} {{ 環境名 }}`で作成できる
$ pyenv virtualenv 3.7.2 test
$ mkdir test-pyenv && cd test-pyenv
# test環境のpythonが呼ばれるようになる．
$ pyenv local test
(test) $ pyenv which python
{{ pyenvのルートディレクトリ }}/versions/test/bin/python
# パッケージのインストール
(test) $ pip install {{ パッケージ名 }}

Venv（or virtualenv）

Python3.3から標準化された（virtualenvはそれまでpipで導入できた）仮想環境作成モジュール

  • 良いところ
    • Python公式であり，（venvなら）大抵最初から使えてお手軽
  • 微妙なところ
    • 結局パッケージの管理はpip
    • たまにVenvが有効化されていない場合がある
    • Python2と3で使い勝手が変わるのがつらい（とはいえもう2.xは死んだ）
    • VenvはあるバージョンのPythonに付属するモジュールであり，そのバージョン以外の仮想環境を構築出来ない．
$ python3 -V
Python 3.7.2
$ mkdir test-venv && cd test-venv
# `python3 -m venv {{ 環境名 }}`でカレントディレクトリ以下に
# その環境名で仮想環境のディレクトリを作成する．
$ python3 -m venv .venv
$ ls -a | grep venv
.venv
# 仮想環境をアクティベート
$ source .venv/bin/activate
(.venv) $ which python
{{ カレントディレクトリ }}/.venv/bin/python
# パッケージのインストール
(.venv) $ pip install {{ パッケージ名 }}
# 仮想環境から抜ける
(.venv) $ deactivate

Conda

Anaconda/Minicondaのパッケージマネージャ兼環境管理ツール．ビルド済みの様々なモジュール・ライブラリを内包する一つのPythonディストリビューション．科学計算ライブラリ系にかなり特化しており，依存ライブラリの用意が難しいWindowsでは非常に便利．

  • 良いところ
    • パッケージ管理と環境構築が同じコマンド体系
    • Pythonのバージョンも一つのモジュールのバージョンのように変更できる
  • 微妙なところ
    • Anacondaの場合容量がびっくりするほどデカい
    • condaでインストールできないパッケージはpipでインストールすることになり，パッケージの管理が分散してしまう
    • 仮想環境のアクティベーションのためにトリッキーな小技が必要になることが多い
    • データ分析界隈で使われることが多いが，初心者のやってみた記事が多すぎて検索結果が大抵地獄
# pyenvでMinicondaをインストールする．
$ pyenv install miniconda3-4.3.30
# Minicondaが仮想環境を作成するディレクトリを`/Users/{{ ユーザ名 }}/.conda/envs`にする
$ echo -e "envs_dirs:\n  - $HOME/.conda/envs" >> $HOME/.condarc
# 検証用のディレクトリを作る
$ mkdir test-conda && cd test-conda
$ pyenv local miniconda3-4.3.30
# `conda env create -n {{ 環境名 }}`で作成する
$ conda create -n test
# 作成した環境には何もないのでPythonからインストールする
$ conda install -n test "python==3.7"
# 仮想環境をアクティベートするconda activateコマンドを有効にする
$ source $(conda info --root)/etc/peofile.d/conda.sh
$ conda activate test
(test) $ which python
/Users/{{ ユーザ名 }}/.conda/envs/test-env/bin/python
# パッケージのインストール
(test) $ conda install {{ パッケージ名 }}
# condaで見つからない場合は
(test) $ pip install {{ パッケージ名 }}
# 仮想環境から抜ける
(test) $ conda deactivate

Pipenv

pipenv-ja.readthedocs.io

requestsモジュールを作ったKenneth Reitz氏が開発されたpipとvirtualenv，そしてpyenvのラッパー．Rubyを書いている人にはPython版のbundlerだと思って貰えるとよい．

  • 良いところ
    • パッケージの管理と仮想環境の作成が同一のコマンド体系で扱える
    • pipenv runを使うことで，いちいち仮想環境をアクティベートする必要がない
    • pythonへのパスを指定するとそのバージョンをベースにした環境を作れる
  • 微妙なところ
    • これ一つでだいたい片が付くが，pipでインストールするライブラリを書く時はpipがPipfileを認識できないので，setup.pyを書いて自分で依存関係を記述しなければならない．
# pipを使ってpipenvをインストール
$ pip install pipenv
$ mkdir test-pipenv && cd test-pipenv
# 仮想環境を`~/.virtualenvs`ではなく，`pipenv install`したディレクトリの直下に作る場合，以下を指定
# $ export PIPENV_VENV_IN_PROJECT=true
# Python 3.7の仮想環境を作る
$ pipenv install --python 3.7
# または直接Pythonへのパスを参照しても良い
# $ pipenv install --python $(pyenv which python3)
# カレントディレクトリに`.venv`ディレクトリができる
$ ls -a | grep .venv
.venv
# PipfileとPipfile.lockによって管理されている
$ cat Pipfile
[[source]]
name ="pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]

[packages]

[requires]
python_version = "3.7"
# `pipenv run`で仮想環境下のコマンドを呼べる
$ pipenv run python -V
Python 3.7.2
# パッケージのインストール
$ pipenv install {{ パッケージ名 }}
# 従来通り仮想環境をアクティベートすることもできる
$ pipenv shell
(.venv) $ python -V
Python 3.7.2
# 仮想環境から抜ける
(.venv) $ exit

Poetry

poetry.eustace.io

最近標準化されたpyproject.tomlを使って管理します．Pipenvと違い，パッケージングまで面倒を見てくれるため，setup.pyを別で記述したり，細かいパッケージング処理を自分で書く必要が無いというのが最も大きな違いです．他にも色々と利点が挙げられているようです．

  • 良いところ
    • pipでインストールするようなモジュールを書きたい場合にパッケージングの面倒を見てくれる
    • どうも依存関係の解消がPipenvより上手く出来ているらしい
  • 微妙なところ
    • モジュールではなくアプリケーションを作る場合，ほとんどの機能が必要ない
    • 2019/03/18現在，まだVSCodeでサポートされていない*2
      • ただしpoetry config settings.virtualenvs.in-project trueでプロジェクト直下に仮想環境を作ると認識してくれる
    • バージョンを自動で解決してくれないので，まずpyenvで使うバージョンを指定，poetry installで仮想環境を作成という手順になり少し面倒臭い
$ curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python
# Poetryのコマンドにパスを通す
$ echo "export PATH=$PATH:$HOME/.poetry/bin" >> ~/.bashrc
$ source ~/.bashrc
# 仮想環境をプロジェクト直下に作る
$ poetry config settings.virtualenvs.in-project true
# 新しいプロジェクトを作る
$ poetry new test-poetry
$ cd test-poetry
# 以下の様なファイル群が自動生成される
$ tree -L 2
.
├── README.rst
├── poetry.lock
├── pyproject.toml
├── test_poetry
│   └── __init__.py
├── test_poetry.egg-info
│   ├── PKG-INFO
│   ├── SOURCES.txt
│   ├── dependency_links.txt
│   └── top_level.txt
└── tests
    ├── __init__.py
    └── test_test_poetry.py
# このプロジェクトで使うPythonのバージョンを指定する
$ pyenv local 3.7.2
# このプロジェクトで使うPythonのバージョンをpyproject.tomlに設定する．今回は3.7．
$ sed -i '' 's/^python = "\^[0-9]\.[0-9]"/python = "^3.7"/g' pyproject.toml
# 仮想環境を構築する
$ poetry install
# pipenv runと同等のコマンド
$ poetry run python -V
Python 3.7.2
# 仮想環境をアクティベート
# 僕の環境では上手く仮想環境のpythonへパスが通らず，正常に動作しませんでした……
$ poetry shell

参考

kk6.hateblo.jp

まとめ

Pyenv+pyenv-virtualenvで作った環境が結局今どのバージョンを使っているのか分からなくなったり，venvを素のまま使っていてこの環境はバージョン何だったっけとなったりしていい加減嫌になったので，

  1. Pyenvで任意のバージョンをインストール（インストールするだけ）
  2. Pipenvで仮想環境作成

が一番しっくりきました．今のところ，これで困るようなフェーズはほとんど遭遇していません．pipenv runで大抵うまくいくという安心感が良いです．が，Poetryの網羅する範囲が非常に広いため，今後Poetryに移行していく可能性はあります．

パッケージの管理

ここでパッケージとは，pipコマンド等でインストールできる，何らかの機能が実装されたPythonモジュール群を指しています．かつてはeasy_installなどもありましたが，現状ではpip一択です．Pipは，PyPI（Python Package Index）というサードパーティー製ライブラリを管理するサーバから，指定したパッケージ名を検索，取得してインストールしてくれます． 前述のPipenv，Poetryはパッケージの管理まで面倒を見てくれるため，これらのどれかを使うことをオススメします．これらは裏側でpipを使用してパッケージをインストールしてくれます．PipenvとPoetryはそれぞれ，インストールするパッケージやそのバージョンについての情報が含まれたPipfile（Poetryならばpyproject.toml）が自動的に作られるため，ユーザ自身がそれらの管理について気にする必要はほとんど有りません．

# Pipのみの場合
$ pip install requests

# Pipenvの場合
# パッケージをインストールすると勝手にPipfileとPipfile.lockが更新される
$ pipenv install requests
# 開発用パッケージの追加
$ pipenv install --dev pytest

# Poetryの場合
# パッケージをインストールすると勝手にpyproject.tomlとpoetry.lockが更新される
$ poetry add requests
# 開発用パッケージのインストール
$ poetry add --dev pytest

開発環境を再構築するために

再構築という作業を可能にしておくことは色々な意味で有用です．

  • 自分のため
    • 急にマシンがぶっ壊れる，環境が壊れたのでやりなおすなど，再構築は大抵ハプニングのときに生じる．すぐに開発を再開できるようにしておく
    • 環境を整理し，常にクリーンに保てるように注意しておくことができる
  • 一緒に開発してくれるメンバーのため
    • 全員が同じPCで編集していては仕事が進まない．メンバーが同等の環境を再現できる様にしておく．
  • バグや実験の再現性
    • 研究でも開発でも再現性は重要です．

READMEにちゃんと構築の仕方を簡単で良いので書いておきましょう．

pip freeze > requirements.txt

pipしか使えない場合です．これまでのPython開発（少なくとも3年くらい前まで）では，requirements.txtというファイルが多く使われていました．以下の様な非常に単純な形式を取っています．

# パッケージ名とバージョン制約から成る
requests==2.21.0
pipenv==2018.11.26

これはpip freezeという，pipでインストールしたモジュールの一覧を吐き出すコマンドの出力とフォーマットが一致しており，以下の様に保存・再構築ができます．

# 今インストールされているパッケージを出力して保存
$ pip freeze > requirements.txt
# 一覧からインストール
$ pip install -r requirements.txt

しかし，この方法にはいくつかの欠点があり，現状あまりオススメはしません（pipenv等を使えない場合は仕方有りません…）

  • pip freezeはインストールしたものを全て出力するため，インストールしたライブラリの依存先まで全て表示されてしまい，どれが本当に必要なものか分かりづらい
  • pip install -U {{ パッケージ名 }}でバージョンをアップグレードした際にrequirements.txtを更新するのを忘れがちになる
  • 開発時のみに必要なパッケージ（テスト用のライブラリなど）を別で列挙したrequirements-dev.txtのようなファイルを作ることになる
  • そもそも指定したバージョンをインストールするだけなので，本当に依存関係の解消をしているわけではない

より詳細なバージョンコントロールについては参考のリンク*3を見てみてください．

conda env export

ドキュメントにそのまま載っている方法*4です．

# 環境の情報を出力
$ conda env export -n {{ 環境名 }} > environment.yml
# 出力された情報から環境を作る
$ conda env create -f environment.yml

environment.ymlは以下の様になります．

# 環境名
name: test-env
channels:
  - defaults
# 必要な依存関係
dependencies:
  # "パッケージ名=バージョン=ビルド"の形式
  - numpy=1.16.2=py37hacdab7b_0
  - python=3.7.0=hc167b69_0
# 仮想環境へのパス
prefix: /Users/ユーザ名/.conda/envs/test-env

この方法は，同じOS，同じプラットフォーム，同じアーキテクチャのマシン間で環境を共有するには良い方法です．ビルド番号まで含めて再現されるためです．しかし，環境特有のビルドを含むもの[^mkl]をインストールしていると他の環境ではエラーになる場合があります．これを解決する手段は公式からは提供されていないので，もし必要な場合は主要なモジュールのみを書いて，バージョン番号のみ指定する事が出来ます．

name: test-env-generic
channels:
  - defaults
dependencies:
  # "パッケージ名=バージョン"の形式で書く
   - numpy=1.16.2
   - python=3.7.0
# 省略

pipenv install or poetry install

Pipenvで管理している場合，PipfileとPipfile.lockをリポジトリに含めておけば大抵上手くいきます．Poetryの場合もpyproject.ymlとpoetry.lockを含めておけば良いです．

# Pipfileのあるディレクトリで実行する
$ pipenv sync
# 開発用パッケージを含める場合
$ pipenv sync --dev

エディタ

何でコードを書くかはしばしば宗教戦争となりがちですが，僕個人は

という棲み分け（？）をしています．この記事を参考にする人の多くはVimは慣れていないと思いますので，代わりにVSCodeを推していきます（実際たまに使っています）

PyCharm

www.jetbrains.com

JetBrains製のPython用IDEです．Windows，Mac，Linuxをサポートしており，3つのエディションがあります．

バージョン 価格 特徴
Professional 有料・サブスクリプション制 リモートインタプリタを使用可能，各種フレームワークのサポートなど
Community 無料 -
Education 無料 機能はCommunityと同等．教育用で学習コースが付属．

ややこしいのですが，学生はアカデミックアカウントの登録を行うことで，Professionalを無料で使えます*5（Educationは元から無料です）．

良いところは

  • ほとんど設定無しにデフォルトのLinter，Formatterでそれなりに綺麗にコードを書ける
  • 補完候補表示の精度が良い
  • デバッグがめちゃくちゃやりやすい
  • 設定無しに型ヒントによる文法チェックと補完が有効
  • IDEらしくこれ一つで完結するため，ターミナルの出番が少ない

微妙なところ

  • やはり単純なエディタよりメモリの消費が激しい
  • 動作中は軽いが，仮想環境のモジュールに対するインデクシング処理が激しく重く，また，これが動いている間は補完やシンタックスハイライトが死ぬ
  • 慣れると他のものを使えなくなるので学生の間に慣れると将来の出費が確約されてしまう

VSCode

code.visualstudio.com

Microsoft製のOSS．Windows, Mac, Linuxで動く超人気テキストエディタ．実際とてもよく出来ているし，軽い．

良いところ

  • 豊富なツールサポート（Git，Linter，Formatter，仮想環境…etc）
  • InteliSenseがよく出来ている
  • 比較的軽い
  • 豊富な拡張機能

微妙なところ

  • 設定が見づらい上に量が多すぎて検索しないとやってられない
  • Formatterなどを毎回そのプロジェクトの仮想環境にインストールしないといけない．

正直そこまで弱点がない良いエディタだと思います．

コーディングの補助

Pythonにはコーディング規約としてPEP8というものがあります*6．コーディング規約というのは，複数人で開発する際に個人間で書き方に細かい違いが出てしまわないように，あらかじめ制定されたコーディングの際のルールです．これに従わなくてもPythonとしての文法が保たれていれば実行できますが，コードの保守性，クオリティを担保するため従っておくべきでしょう． 書いているといつの間にかある程度覚えてきますが，そのチェックを毎回人が行うことは容易ではありません．そういう退屈なことはPythonがやってくれます．

Linter

Lintとは文法チェックのことを指します．コードを読み取り．コーディング規約にちゃんと従っているかを検証してくれます． Pythonでは様々なLinterが実装されていますが，代表的なもののみ示します．

  • pycodestyle
    • 元々はpep8というモジュール名だったが，ややこしいため最近名前が変更された
    • blog.amedama.jp
  • flake8
    • pycodestyleとpyflakes，mccabeのラッパー．
    • pyflakesはエラー解析を行い，未使用の変数や使われていないimport文を検知する
    • mccabeはifやforなどの複雑さを評価する循環的複雑度を算出する
    • minus9d.hatenablog.com
  • pylint
    • VSCodeではデフォルトで設定されているLinter．
    • 上記2つより少し厳しい
  • mypy
    • Pythonは動的型付けですが，type hintsというPEP484で策定された型補完機能を活用し，引数などの型の一致不一致を検証してくれます
    • Python 3.5まででは専用の形式のコメントで，3.5以降では専用の構文によってPythonの構文に型を付けることが出来るようになりました
    • これは型チェックだけでなく，補完が有効になるという嬉しい特典もあります．
    • qiita.com

個人的にはいいかんじに文法チェックとコーディング規約のチェックをやってくれてうるさすぎないflake8 + 型チェックのためのmypyの組み合わせが，バランスも良いと思います．

VSCodeでの設定

PyCharmでは面倒臭がってデフォルトの設定から動かしていない*7ので，VSCodeの設定例だけ示しておきます．なお，前提としてVSCodeにはPythonの拡張機能がインストールされているものとします．

Cmd + ,で設定を開き，以下の項目を検索して値を変更します．

  • python.linting.pylintEnabled：チェックを外す
  • python.linting.flake8Enabled：チェックを入れる
  • python.linting.mypyEnabled：チェックを入れる
  • python.linting.lintOnSave：チェックを入れる

~~ is not installedみたいなエラーが出ると思うので，それぞれインストールします．

$ pipenv install --dev flake8 mypy

単純なFizzBuzzのコードですが，わざと汚く書いてみました．

f:id:pudding_info:20190319011122p:plain
FizzBuzz

問題のある箇所に赤の波線が引かれています．カーソルを合わせると内容が出ます．例えばimportしているけど使っていないosモジュールについての警告が以下です．Quick Fixを押すと修正……され…ません…*8

f:id:pudding_info:20190319011209p:plain
unused import

また，i % 5をi % "hoge"にわざと間違えてみると型チェックにより警告が出ます．

f:id:pudding_info:20190319011232p:plain
type error

なお，Quick Fixを押しても解決はされません…

Formatter

Linterがコードには手を加えない文法チェッカであったのに対して，Formatterは実際にコードを自動で書き換え，適合するスタイルに書き換えてくれます．これもまた複数の実装が存在します．

  • autopep8
    • PEP8に準拠するようにフォーマットしてくれる
    • おそらく最も有名
  • yapf
  • black
    • つい最近出てきた，比較的新しいFormatter．
    • 大変ストイックで，設定できるのが1行当たりの文字数しかない．
    • フォーマットの例：https://black.now.sh

ドキュメントの豊富さと，導入の簡単さからautopep8を推します．pycodestyleのチェックに通るようにしてくれる程度で過度なスタイルを強要してこないのもカジュアルに書けて嬉しいところです．

VSCodeでの設定

Cmd + ,で設定を開き，以下の項目を検索して値を変更します．

  • python.formatting.provider：autopep8を選択
  • editor.formatOnType：チェックを入れる
  • editor.formatOnSave：チェックを入れる

~~ is not installedみたいなエラーが出ると思うので，それぞれインストールします．

$ pipenv install --dev autopep8

Cmd + Shift + Pでコマンドパレットを開き，formatと検索して実行するとフォーマットされます．

f:id:pudding_info:20190319011449g:plain
vscode fmt

formatOnTypeを有効にしているので，打ち込みながら勝手に修正されていきます．

f:id:pudding_info:20190319011512g:plain
vscode fmt on type

GitとPython

近年，コードはGitで管理というのが当たり前です*9．Pythonで書かれるプロジェクトもよくGitで管理されますが，ときどき悲しくなるリポジトリを見かけます．それは

  • 仮想環境が丸々入っている
  • *.pycや__pycache__が含まれている
  • 環境を再構築するための情報が無い

などです．これらは簡単に避けることが出来ます．

Git監視下に置かない方が良いファイル

.gitignoreというファイルをプロジェクト直下に記述します．gitignoreすべきファイルの参考となるものが，GitHub公式に上がっています．基本はこれをコピペで良いでしょう．

github.com

面倒臭いときは以下のものを足しておけば十分かと思います

# 仮想環境の排除
.venv
venv/

# pyenvのバージョンファイル
.python-version

# キャッシュなど
__pycache__/
*.py[cod]
*$py.class

# mypyのキャッシュ
.mypy_cache/

追加しておくべきファイル

requirements.txt，Pipfile，Pipfile.lockなどパッケージにまつわるファイルは追加しておくべきです． また，

  • README.md
    • プロジェクトの説明や使い方，環境構築の仕方などを書く
  • LICENSE
    • GitHub等から追加できるのでOSSにする場合はライセンスを選択して追加しておく
    • qiita.com

などもあると良いでしょう．他に，.pylintrcなどのlintの設定なども共有のために含めておくことをオススメします．

開発開始までの流れ

  1. プロジェクトのディレクトリを作成し，pipenv install --python 3.7
  2. pipenv install --dev flake8 autopep8 mypy
  3. VSCodeかPyCharmで開く
  4. コードを書く

まとめ

長々と書いてしまって本当にすいませんという気持ちで一杯です． これはこうした方がいい，setup.pyについて書かなさすぎだろ等，様々な意見があると思いますのでコメント等頂ければ追記していきたいです．

*1:github.com

*2:Support Poetry depenedency manager · Issue #1871 · Microsoft/vscode-python · GitHub

*3:qiita.com

*4:docs.conda.io

*5:www.jetbrains.com

*6:pep8-ja.readthedocs.io

*7:PyCharmではデフォルトでPEP8準拠の警告，型チェック等がFormatterと共に装備されています．

*8:なんで？

*9:これはソフトウェア工学を学ぶ人間としての感想です