差分
このページの2つのバージョン間の差分を表示します。
両方とも前のリビジョン前のリビジョン次のリビジョン | 前のリビジョン | ||
programming:python:install [2019/01/08] – ikatakos | programming:python:install [2021/04/23] (現在) – [時事的な話題] ikatakos | ||
---|---|---|---|
行 1: | 行 1: | ||
======Pythonインストール(Anaconda)====== | ======Pythonインストール(Anaconda)====== | ||
- | Pythonのインストールには、WindowsではAnacondaを使うのが手っ取り早い。 | + | ===== 時事的な話題 ===== |
- | =====概要===== | + | <WRAP center round box> |
+ | 2021年くらい(? | ||
+ | |||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | |||
+ | より厳密には、「Anacondaの公式リポジトリ(repo.anaconda.com)を使う」ことに対する有償化のようなので、それを使わなければOK。 | ||
+ | |||
+ | 具体的には、MiniCondaをインストール→デフォルトリポジトリを例えばconda-forgeに設定すると大丈夫という見解を、公式では無いものの、Anaconda共同創立者の一人 Peter Wang (pwang99)氏がコミュニティのやりとりで語っている。 | ||
+ | |||
+ | * [[https:// | ||
+ | |||
+ | これを機にAnacondaから別のツールに移行するのも自由。 | ||
+ | |||
+ | </ | ||
+ | |||
+ | |||
+ | =====環境構築手法の選択===== | ||
+ | |||
+ | まず、環境構築にはAnaconda以外の選択肢があることを述べる。 | ||
+ | |||
+ | Pythonの環境構築手法はいろいろあり、以下の記事が、判断根拠がまとまっていてわかりやすい。 | ||
+ | |||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | |||
+ | ポイントは、主に以下の3点に分けられる。 | ||
+ | |||
+ | * Python自身のバージョン(3.7, | ||
+ | * パッケージ(Numpy, | ||
+ | * 独自のパッケージ管理ツールがあるかどうか? | ||
+ | |||
+ | 実際使う分の、個人的なそれぞれの必要性と所感は、 | ||
+ | |||
+ | * Python自身(インタプリタ) | ||
+ | * 日常ではほぼ最新版さえあればよいので、その時々の最新版にアップデートしていけば共存の必要性はそこまで感じにくい | ||
+ | * が、長期的にPythonを使うのであれば、古いコードがいざという時に動かなくなるのはリスク | ||
+ | * インタプリタ本体の後方互換性はそこまで大きく失われることは無いが、パッケージの後方互換性は突然失われることがあり、そのバージョンはインタプリタのバージョンに依存するため、いずれにしろ環境を確実に保全しようと思えばインタプリタのバージョンも据え置かざるを得ない。古いプロジェクトのためにいつまでもインタプリタ本体のバージョンが上げられないのも困る | ||
+ | * メジャーバージョンごとにインストール先フォルダを分けて環境変数をその都度書き換えても対応できるっちゃできるが、ツールがあると楽 | ||
+ | * パッケージ | ||
+ | * 必要 | ||
+ | * 様々なプロジェクトで必要になったパッケージを全て1環境にインストールするのは、競合して環境が壊れる率が上がる | ||
+ | * また上記の通り、後方互換性の無いアップデートで古いコードが動かなくなるリスクがある | ||
+ | * パッケージ管理ツール | ||
+ | * 必要。Pythonはパッケージを大量に追加して利便性を高める言語なので、無いと困る | ||
+ | * 現状、複数のツールがあるが、それぞれのツールでそれぞれの問題をはらむ | ||
+ | |||
+ | Anacondaは、上記の3点の全てを行えるのが利点。 | ||
+ | 一方、代わりにブラックボックス化して「全部をAnacondaにゆだねなければならない」「壊れたら二進も三進もいかなくなりがち」というところがデメリットでもある。 | ||
+ | < | ||
+ | |||
+ | ただ、やはり1つのツールで環境を分離・切り替えできるというのは楽である。 | ||
+ | |||
+ | 環境が壊れたら諦めてさっさと再構築する、という、火事の多かった江戸の町の家屋くらいの心持ちで運用するのが精神衛生上いい。 | ||
+ | その場合、Anacondaより、余計なパッケージの入っていないMiniCondaの方が再構築にかかる時間が減って使いやすいかも知れない。 | ||
+ | |||
+ | |||
+ | =====Anacondaの概要===== | ||
Anacondaの説明はいいから[[# | Anacondaの説明はいいから[[# | ||
行 13: | 行 70: | ||
* パッケージ管理ツール | * パッケージ管理ツール | ||
* 複数環境管理・切り替えツール | * 複数環境管理・切り替えツール | ||
- | * [[http:// | ||
の複合みたいなもの。 | の複合みたいなもの。 | ||
行 22: | 行 78: | ||
* [[https:// | * [[https:// | ||
* [[https:// | * [[https:// | ||
+ | |||
+ | Minicondaは、このうちパッケージ詰め合わせセットを除いたもの。 | ||
====利点==== | ====利点==== | ||
- | Pythonは、NumPy・SciPyなどの豊富で強力なパッケージが魅力だが、いくつかの問題をはらむ。 | + | 冒頭の通り、これらを1つ1つ行えるツールはあるが、それを、Anacondaひとつインストールするだけでそこそこ使えるようにできるところ。 |
- | * パッケージ同士の依存関係が複雑になりがち | + | 中でもパッケージ管理システムはバイナリで提供してくれるので、特にWindowsではエラーが発生しにくくなっている。(ただ、注意すべき点もある。『留意点』で後述) |
- | * 特にWindowsでは、パッケージのインストールに失敗することがある(後述) | + | |
- | * 標準では1つのバージョンしかインストールできないが、提供されているパッケージの互換性やプロジェクト要件などで複数バージョンを切り替えたい場合がある | + | |
- | Anacondaでは、魔法のようにとはいかないが、そこそこ便利にこれらに対する対策を与えてくれる。 | + | Anacondaでなくとも、Pythonではpipという管理ツールがデフォで使える。 |
- | + | しかしpipは「ソースの状態で提供するからビルドはローカルでやってね」的なインストール方法がとられるパッケージもあり、Windowsではその環境を別に整える必要がある。 | |
- | ==管理ツール== | + | それらのツールを整えても、ソースがLinux前提で書かれていることによるビルドエラー(多分……ファイル開くときのデフォルトエンコードの違いなど)もあり、 |
- | + | ソースから修正しないと入らないことも稀にある。 | |
- | condaというパッケージ管理ツールが付属し、複雑な依存関係を管理してくれる。 | + | condaはビルド済みで提供してくれるので失敗が少ない。 |
- | + | ||
- | condaでなくとも、Pythonではpipという管理ツールがデフォで使える。しかしpipは「ソースの状態で提供するからビルドはローカルでやってね」的なインストール方法がとられるパッケージもあり、Windowsではその環境を別に整える必要がある。それらのツールも基本的にLinux向けなので、ややこしい。整えても、ソースがLinux前提で書かれていることによるビルドエラー(多分……ファイル開くときのデフォルトエンコードの違いなど)もあり、ソースから修正しないと入らないことも稀にある。condaはビルド済みで提供してくれるので失敗が少ない。 | + | |
* [[https:// | * [[https:// | ||
- | また、Anacondaのレポジトリで提供されていないパッケージをpip経由でインストールすることも可能。インストールしたパッケージはAnacondaからは依存関係の解決や更新などの対象にはならないが、ひとまず「インストールされている」という事実は保持してくれる。最後の手段ではあるが。 | + | また、Anacondaのレポジトリで提供されていないパッケージをpip経由でインストールすることも可能。 |
- | + | インストールしたパッケージはAnacondaからは依存関係の解決や更新などの対象にはならないが、 | |
- | ※pipでも、wheelというバイナリ化済みのファイルをダウンロードして、そのファイルからインストールすることも出来る。/ | + | ひとまず「インストールされている」という事実は保持してくれる。最後の手段ではあるが。 |
- | ==複数環境を共存できる== | + | ※pipでも、一部はwheelというバイナリ化済みのファイルでの提供も行われるようになり、エラーは発生しづらくなっている。 |
- | 異なるバージョンを両方インストールして切り替える使い方が出来る。 | ||
- | /* | ||
- | * 事例1 - 継続プロジェクト | ||
- | * Ver.3.4で作成して継続的に動かしているプロジェクトがある | ||
- | * 新規プロジェクトはVer.3.6で行いたい | ||
- | * 全体の環境を変えるとVer.3.4のが動かなくなる可能性がある | ||
- | * →3.4と3.6を共存させられる | ||
- | * 事例2 - バージョン互換 | ||
- | * 更新が止まっているパッケージ(A)を使いたい | ||
- | * 更新は止まっているが、普通に使える | ||
- | * (A)は別のパッケージ(B)に依存している | ||
- | * パッケージ(B)は更新が続いていて、最新Ver.を使っている | ||
- | * (A)はレポジトリの互換関係も更新されてないので、(B)も1つ前のVer.を要求され、競合で入れられない | ||
- | * (B)は他のプロジェクトでも使っており、Ver.を落とすと影響を与えかねない | ||
- | * →(A)のために(B)のバージョンを落とした専用の環境を作り、共存させられる | ||
- | */ | ||
====Anacondaの留意点==== | ====Anacondaの留意点==== | ||
==容量は肥大化しがち== | ==容量は肥大化しがち== | ||
- | NumPyなど、よく使うパッケージをデフォルトで入れてくれる。便利な反面、最小公倍数的にあれこれ入っているので、容量はそれなりに食う。複数環境を構築したらその分だけ重複して食う。 | + | NumPyなど、よく使うパッケージをデフォルトで入れてくれる反面、最小公倍数的にあれこれ入っているので、容量はそれなりに食う。 |
+ | 複数環境を構築したらその分だけ重複して食う。 | ||
+ | |||
+ | Minicondaを使うことで、この点は軽減される。 | ||
==LinuxやMacなどでは、システムとの競合も== | ==LinuxやMacなどでは、システムとの競合も== | ||
- | あまりOSを使わないので詳細は不明だが、LinuxではシステムとしてPython(2.x)が入っており、システムから利用されることもある。Anacondaを不用意にインストール・設定することでシステムのPythonより優先的に使用されるようになり、特にPython3を入れた場合など、トラブルの原因となることもあるようだ。 | + | LinuxではシステムとしてPython(2.x)が入っており、システムから利用されることもある。 |
+ | Anacondaをインストールする際は、その点に注意しないと(どのようにしたらいいか、は調べていないが)AnacondaがシステムのPythonより優先的に使用されるようになり、トラブルの原因となることもあるようだ。 | ||
また、Anacondaの持つ各種ツールが、openssl, | また、Anacondaの持つ各種ツールが、openssl, | ||
行 78: | 行 120: | ||
Linuxでは上記のビルドエラーの失敗も起こりづらいため、Windowsと比較すると、Anacondaを採用する積極的理由は薄くなる。 | Linuxでは上記のビルドエラーの失敗も起こりづらいため、Windowsと比較すると、Anacondaを採用する積極的理由は薄くなる。 | ||
- | ==Anaconda独自のパッケージ管理による手間・エラー== | + | ==pipは基本使えなくなると考える== |
+ | |||
+ | Anacondaでは、パッケージ管理を専用の「conda」で行う。「pip」とも併用できるとはいえ、環境の不整合が発生しやすくなる。 | ||
+ | |||
+ | * [[https:// | ||
+ | |||
+ | ==condaによるパッケージ管理の手間・エラー== | ||
+ | |||
+ | condaでは、依存関係が解消しきれないことによると思われるエラーがたまに発生する。 | ||
+ | |||
+ | * 提供者がWindows環境や日本語環境を考慮しきれてないことによるエラー | ||
+ | * チャンネルを混在させたときの上書き合戦 | ||
+ | * よくわからん、「おま環」的な現象 | ||
+ | |||
+ | 2番目の問題について、condaのリポジトリにはよく使うものは一通り揃っているが、少し用途特化なパッケージはpipほどは充実していない。 | ||
+ | Windows向けに限定すると、選べるバージョンは更に限定される。 | ||
+ | |||
+ | そこで、Anaconda Cloud という、第三者がパッケージを提供してくれているものを利用する。 | ||
+ | インストール時に「チャンネル」を切り替えることで、既定以外のチャンネルからインストール可能となる。 | ||
+ | |||
+ | しかし、様々なチャンネルから掻い摘まんだパッケージが混在し、それらが依存する共通のパッケージがあった場合、 | ||
+ | どのチャンネルも依存関係の解決は自身のチャンネル内で行おうとするので、 | ||
+ | インストールやアップデート時に上書き合戦が起こったりして、その分だけ時間がかかる。 | ||
+ | |||
+ | 例えば、チャンネルAからインストールしたパッケージと、Bからインストールしたパッケージが、ともにNumPyに依存する場合、いずれも自身のチャンネルのNumPyを使おうとする。 | ||
+ | 最終的にはいずれかが使われるが、AのNumPyを使っている状態でBをupdateした場合、BのNumPyに置き換わったりする。 | ||
- | Pythonにはデフォルトで「pip」という管理ツールが付属しているが、Anacondaでのパッケージ管理は専用の「conda」で行うことが推奨される。しかし、condaのレポジトリでは、依存関係情報がおかしい?ことによると思われるエラーがたまに発生する。 | + | ==トラブル時の情報の少なさ== |
- | condaのリポジトリにはよく使うものは一通り揃っているが、少し用途特化なパッケージはpipほどは充実してないので、様々なチャンネルから掻い摘まんでインストールすることもある。どのチャンネルも依存関係の解決は自身のチャンネル内のパッケージで行おうとするので、よく依存されるNumPyなどのパッケージはインストールやアップデート時に上書き合戦が起こったりして、その分だけ時間がかかる。 | + | 相対的なものではあるが、condaはあくまで第三機関のツールのため、エラーが発生してもWeb上に転がっている情報が少ない。 |
- | 有名なツールとはいえあくまで第三機関なので、情報量も相対的には少ない。エラーに遭遇したら解決策を探すより一旦破壊して作り直した方が速いこともあるが、再構築にもそれなりに時間がかかる。 | ||
====Windowsでの他の手段==== | ====Windowsでの他の手段==== | ||
- | * 直接インストール | + | ==VirtualBox, Dockerなどの仮想マシン上のLinuxに、直接インストール== |
- | * pipでも一部パッケージはwheelでバイナリ化しての提供も行われるようになり(全てでは無いが)、失敗も起こりづらくなっている | + | |
- | * 仮想環境にはvenvが使える | + | OSごと環境を用意してしまう力業。やはりLinuxでのインストールはエラーが発生しづらい。 |
- | * これは、あくまでインストールしたPython上で動くツールなので、Python自身のバージョンの切り替えはできない | + | |
- | * インストールしたパッケージなどは、環境毎に保持される | + | 実行環境はLinuxだが、pyファイルはWindowsのファイルシステム上で管理したい場合、仮想マシンとの共有フォルダ設定など、ツール周りの設定がちょっと煩雑になるかも。 |
- | * 依存関係の不整合などのエラーが万一発生したとき、直接インストールした1環境しかないとどうしようも無くなるので、venvは使っておいた方がよい | + | |
- | * VirtualBox, Dockerなどの仮想マシン上のLinuxに、直接インストール | + | |
- | * 複数バージョンも、OS環境ごと用意してしまえる | + | |
- | * 仮想マシンの立て方やLinuxについて、必要な勉強量は増える | + | |
- | * ツールの設定が少し複雑になる | + | |
- | | + | |
- | * IDEから呼び出して実行させたい場合などは、IDEでのssh経由でのコマンド実行の設定など | + | |
行 109: | 行 168: | ||
普通にインストーラを落として実行。特に理由が無ければ最新のPython3.xでいい。 | 普通にインストーラを落として実行。特に理由が無ければ最新のPython3.xでいい。 | ||
- | * [[https:// | + | * [[https:// |
+ | |||
+ | Minicondaの場合は | ||
+ | |||
+ | * [[https:// | ||
+ | |||
+ | ==ウイルス対策ソフトからの監視除外== | ||
+ | |||
+ | あくまで任意。 | ||
+ | |||
+ | Anacondaはパッケージのインストール・アップデートに伴う書き換えファイル数が多いので、 | ||
+ | ウイルス対策ソフトなどの監視対象となっていると、アホみたいに時間がかかる。 | ||
+ | |||
+ | インストール時やアップデート前だけでも、'' | ||
====環境変数==== | ====環境変数==== | ||
行 115: | 行 187: | ||
環境変数は自分で指定する。 | 環境変数は自分で指定する。 | ||
- | インストール時に特に何も変えないと、Anacondaのコアは「'' | + | インストール時に特に何も変えないと、Anacondaのコアは「'' |
+ | つまり、ユーザ毎にインストールされるということ。 | ||
+ | なので環境変数もユーザ環境変数を使うのがいいだろう。 | ||
ANACONDA_HOME = C:/ | ANACONDA_HOME = C:/ | ||
- | | + | Path = (既存のPath); |
- | | + | |
別に変数名とかこの通りで無くてもいい。あくまで一例。 | 別に変数名とかこの通りで無くてもいい。あくまで一例。 | ||
- | '' | + | '' |
+ | 通常状態でコマンドプロンプトで「python」とした時に、base環境のpython.exeが呼ばれる。 | ||
'' | '' | ||
- | '' | + | <del>もし他の環境を呼ばれるようにしたい場合は、追加した環境は '' |
+ | |||
+ | 追加した環境は、''> | ||
+ | その際に環境変数などがその環境向けにセットしなおされる。 | ||
+ | |||
+ | 毎回有効化するのは面倒なので、単に'' | ||
+ | 本来はbase環境も ''> | ||
行 138: | 行 218: | ||
などと表示されればOK。 | などと表示されればOK。 | ||
+ | |||
====アップデート==== | ====アップデート==== | ||
- | Anacondaのインストール時点で、主要なパッケージも付随してインストールされている。これをアップデートしておく。 | + | Anacondaのインストール時点で、主要なパッケージも付随してインストールされている。まずはconda本体と、これをアップデートしておく。 |
+ | > conda update conda | ||
> conda update --all | > conda update --all | ||
行 151: | 行 233: | ||
=====環境の構築===== | =====環境の構築===== | ||
- | インストール時点で、rootに環境は1つ用意される。 | + | インストール時点で、baseに環境は1つ用意される。 |
他に環境を用意したい時、 | 他に環境を用意したい時、 | ||
行 163: | 行 245: | ||
> conda create -n env_name python=3.5 package1 package2 package3... | > conda create -n env_name python=3.5 package1 package2 package3... | ||
- | これだとpython3.5で用意される。同時にpackage1, | + | これだとpython3.5で用意される。同時に、既定の詰め合わせセットに加え、package1, |
- | <WRAP center round important> | ||
- | パッケージ名に" | ||
- | |||
- | それはそれで便利とも言えるが、容量を食うし、IDEを使っている場合、起動時のキャッシュの構築に時間がかかったりするので、お好みで。 | ||
- | </ | ||
- | |||
- | なおインストール時のrootのpythonには勝手に入る模様。 | ||
=====環境の切り替え===== | =====環境の切り替え===== | ||
行 190: | 行 265: | ||
python {環境env_name上で実行したいスクリプト} | python {環境env_name上で実行したいスクリプト} | ||
call deactivate | call deactivate | ||
+ | |||
+ | ==はじめから特定の環境でコマンドプロンプトを起動== | ||
+ | |||
+ | Anacondaインストール時点で、スタートメニューに「Anaconda3 > Anaconda Prompt」が出来ている。これを選択すると、base環境でactivateされた状態でcmdが起動する。 | ||
+ | |||
+ | これはcmd.exeのショートカットにオプションを付けて起動しているだけなので、それを倣うと、任意の環境でactivateされた状態でcmdを起動できるショートカットを作成できる。 | ||
+ | |||
+ | Anaconda Prompt(デフォルト) | ||
+ | %windir%\System32\cmd.exe "/ | ||
+ | ↓ | ||
+ | %windir%\System32\cmd.exe "/ | ||
+ | |||
=====パッケージのインストール===== | =====パッケージのインストール===== | ||
行 201: | 行 288: | ||
でどんなものがあるか検索できる。 | でどんなものがあるか検索できる。 | ||
- | デフォルトのチャンネルにパッケージが無い場合、別のチャンネルからインストールすることもできる。[[https:// | + | デフォルトのチャンネルにパッケージが無い場合、別のチャンネルからインストールすることもできる。 |
+ | [[https:// | ||
+ | ご丁寧にコマンドが記載されているので、そのままコマンドプロンプトに貼り付けると、インストールされる。 | ||
+ | |||
+ | ただ、『留意点』の項でも述べたとおり、なるべくなら同一のチャンネルで環境を統一した方がよい。 | ||
- | ==チャンネルはなるべく統一したい== | + | ===Miniconda導入時の個人用初回インストールパッケージ=== |
- | 複数のチャンネルを使うとチャンネルの依存関係が混在してしまうので、デフォルトにあるならなるべくそちらを使った方がよい。 | + | なるべく、最終的なインストール元がデフォルトチャンネルである状態を保ちたいので、「デフォルトチャンネル以外にしか無いパッケージ」→「デフォルトチャンネルに存在するパッケージ」の順で入れる。 |
- | 留意点の項でも述べたが、例えば、デフォルトチャンネルからNumPyをインストールした環境に、別のチャンネル(Aとする)から「NumPyに依存する、別のパッケージ」をインストールすると、NumPyはチャンネルAのものに置き換わってしまう。基本的にはどのチャンネルでも最新版が保たれていて同じように動作することを期待してしまうが、なかなかそうでも無いので、競合が発生してインストールできなかったり、「デフォルトチャンネルから過去にインストール済みの、NumPyに依存する第3のパッケージ」に影響が出ることも稀にある。 | + | 必要なパッケージは人それぞれだが、とりあえず自分が入れるなら以下。 |
- | また、NumPyがチャンネルAのものに置き換わった状態で、デフォルトチャンネルのNumPyに依存するパッケージをinstallまたはupdateすると、当然同じようにNumPyはデフォルトチャンネルのものに置き換わる。NumPy以外の他の被依存パッケージでも同様なことが起こると、常に上書き合戦が行われ、いちいち時間がかかってしまう。 | + | conda update |
+ | conda install -c conda-forge simplekml | ||
+ | conda install numpy scipy pandas matplotlib seaborn pyproj python-dateutil | ||
=====環境の掃除===== | =====環境の掃除===== |