2021年くらい(?)から、200人規模以上の会社でAnacondaを使う場合は有償になったみたい。（細かな条件は公式を要確認）
より厳密には、「Anacondaの公式リポジトリ（repo.anaconda.com）を使う」ことに対する有償化のようなので、それを使わなければOK。
具体的には、MiniCondaをインストール→デフォルトリポジトリを例えばconda-forgeに設定すると大丈夫という見解を、公式では無いものの、Anaconda共同創立者の一人 Peter Wang (pwang99)氏がコミュニティのやりとりで語っている。
これを機にAnacondaから別のツールに移行するのも自由。
まず、環境構築にはAnaconda以外の選択肢があることを述べる。
Pythonの環境構築手法はいろいろあり、以下の記事が、判断根拠がまとまっていてわかりやすい。
ポイントは、主に以下の3点に分けられる。
実際使う分の、個人的なそれぞれの必要性と所感は、
Anacondaは、上記の3点の全てを行えるのが利点。
一方、代わりにブラックボックス化して「全部をAnacondaにゆだねなければならない」「壊れたら二進も三進もいかなくなりがち」というところがデメリットでもある。
そしてその割りに、いまいち安定してない
ただ、やはり1つのツールで環境を分離・切り替えできるというのは楽である。
環境が壊れたら諦めてさっさと再構築する、という、火事の多かった江戸の町の家屋くらいの心持ちで運用するのが精神衛生上いい。 その場合、Anacondaより、余計なパッケージの入っていないMiniCondaの方が再構築にかかる時間が減って使いやすいかも知れない。
Anacondaの説明はいいからインストールだけしたい人はこちら。
の複合みたいなもの。
Minicondaは、このうちパッケージ詰め合わせセットを除いたもの。
冒頭の通り、これらを1つ1つ行えるツールはあるが、それを、Anacondaひとつインストールするだけでそこそこ使えるようにできるところ。
中でもパッケージ管理システムはバイナリで提供してくれるので、特にWindowsではエラーが発生しにくくなっている。（ただ、注意すべき点もある。『留意点』で後述）
Anacondaでなくとも、Pythonではpipという管理ツールがデフォで使える。 しかしpipは「ソースの状態で提供するからビルドはローカルでやってね」的なインストール方法がとられるパッケージもあり、Windowsではその環境を別に整える必要がある。 それらのツールを整えても、ソースがLinux前提で書かれていることによるビルドエラー（多分……ファイル開くときのデフォルトエンコードの違いなど）もあり、 ソースから修正しないと入らないことも稀にある。 condaはビルド済みで提供してくれるので失敗が少ない。
また、Anacondaのレポジトリで提供されていないパッケージをpip経由でインストールすることも可能。 インストールしたパッケージはAnacondaからは依存関係の解決や更新などの対象にはならないが、 ひとまず「インストールされている」という事実は保持してくれる。最後の手段ではあるが。
※pipでも、一部はwheelというバイナリ化済みのファイルでの提供も行われるようになり、エラーは発生しづらくなっている。
NumPyなど、よく使うパッケージをデフォルトで入れてくれる反面、最小公倍数的にあれこれ入っているので、容量はそれなりに食う。 複数環境を構築したらその分だけ重複して食う。
Minicondaを使うことで、この点は軽減される。
LinuxではシステムとしてPython(2.x)が入っており、システムから利用されることもある。 Anacondaをインストールする際は、その点に注意しないと（どのようにしたらいいか、は調べていないが）AnacondaがシステムのPythonより優先的に使用されるようになり、トラブルの原因となることもあるようだ。
また、Anacondaの持つ各種ツールが、openssl, curlなどLinuxのシステムと同名なものもあるようで、それも競合してしまう。
Linuxでは上記のビルドエラーの失敗も起こりづらいため、Windowsと比較すると、Anacondaを採用する積極的理由は薄くなる。
Anacondaでは、パッケージ管理を専用の「conda」で行う。「pip」とも併用できるとはいえ、環境の不整合が発生しやすくなる。
condaでは、依存関係が解消しきれないことによると思われるエラーがたまに発生する。
2番目の問題について、condaのリポジトリにはよく使うものは一通り揃っているが、少し用途特化なパッケージはpipほどは充実していない。 Windows向けに限定すると、選べるバージョンは更に限定される。
そこで、Anaconda Cloud という、第三者がパッケージを提供してくれているものを利用する。 インストール時に「チャンネル」を切り替えることで、既定以外のチャンネルからインストール可能となる。
しかし、様々なチャンネルから掻い摘まんだパッケージが混在し、それらが依存する共通のパッケージがあった場合、 どのチャンネルも依存関係の解決は自身のチャンネル内で行おうとするので、 インストールやアップデート時に上書き合戦が起こったりして、その分だけ時間がかかる。
例えば、チャンネルAからインストールしたパッケージと、Bからインストールしたパッケージが、ともにNumPyに依存する場合、いずれも自身のチャンネルのNumPyを使おうとする。 最終的にはいずれかが使われるが、AのNumPyを使っている状態でBをupdateした場合、BのNumPyに置き換わったりする。
相対的なものではあるが、condaはあくまで第三機関のツールのため、エラーが発生してもWeb上に転がっている情報が少ない。
OSごと環境を用意してしまう力業。やはりLinuxでのインストールはエラーが発生しづらい。
実行環境はLinuxだが、pyファイルはWindowsのファイルシステム上で管理したい場合、仮想マシンとの共有フォルダ設定など、ツール周りの設定がちょっと煩雑になるかも。
Pythonが既にインストール済みなら前もってアンインストール
普通にインストーラを落として実行。特に理由が無ければ最新のPython3.xでいい。
Minicondaの場合は
あくまで任意。
Anacondaはパッケージのインストール・アップデートに伴う書き換えファイル数が多いので、 ウイルス対策ソフトなどの監視対象となっていると、アホみたいに時間がかかる。
インストール時やアップデート前だけでも、C:/Users/(user)/Anaconda3 フォルダを監視から除外すると、高速になる可能性がある。
環境変数は自分で指定する。
インストール時に特に何も変えないと、Anacondaのコアは「C:/Users/(ユーザ名)/Anaconda3」にインストールされる。
つまり、ユーザ毎にインストールされるということ。
なので環境変数もユーザ環境変数を使うのがいいだろう。
ANACONDA_HOME = C:/Users/(ユーザ名)/Anaconda3 Path = (既存のPath);%ANACONDA_HOME%;%ANACONDA_HOME%\Scripts
別に変数名とかこの通りで無くてもいい。あくまで一例。
%ANACONDA_HOME% にはpython.exeがあり、最初にデフォルトで作られている環境(base)である。
通常状態でコマンドプロンプトで「python」とした時に、base環境のpython.exeが呼ばれる。
%ANACONDA_HOME%\Scripts にはconda.exeやactivate.batなど、Anacondaのツールがある。Pathに追加すると、これらをどこからでも使えるようになる。
もし他の環境を呼ばれるようにしたい場合は、追加した環境は
C:/Users/(ユーザ名)/Anaconda3/envs/(環境名) に作成されるので、そこを指定する。
追加した環境は、> activate {envname} で有効化してから使う。
その際に環境変数などがその環境向けにセットしなおされる。
毎回有効化するのは面倒なので、単にpythonを呼んだときにとりあえずデフォルト環境で実行してくれるようにするため、%ANACONDA_HOME%をパス指定しているが、
本来はbase環境も > activate base としてから使った方がよい。
コマンドプロンプトから、
> conda --version conda 4.3.30
などと表示されればOK。
Anacondaのインストール時点で、主要なパッケージも付随してインストールされている。まずはconda本体と、これをアップデートしておく。
> conda update conda > conda update --all
時間はかかるので、任意で。
NumPyとMKL周りで、環境によってupdateして最新版にすると逆にNumPyが動かなくなることがある。（参考: NumPy）
インストール時点で、baseに環境は1つ用意される。
他に環境を用意したい時、
> conda create -n env_name(任意)
で“env_name”という名前の環境が用意される。
同時にPythonのバージョンや、最初から入れておくパッケージも指定できる。
> conda create -n env_name python=3.5 package1 package2 package3...
これだとpython3.5で用意される。同時に、既定の詰め合わせセットに加え、package1,2,3（仮称）というパッケージをインストールする。
> activate env_name
これで、このセッションに限り、環境がenv_nameになる。
> deactivate
で元に戻る。
バッチファイルまたは外部プログラムからの呼び出しで特定の環境を使いたい場合は、callを付ける必要がある。
call activate {env_name}
python {環境env_name上で実行したいスクリプト}
call deactivate
Anacondaインストール時点で、スタートメニューに「Anaconda3 > Anaconda Prompt」が出来ている。これを選択すると、base環境でactivateされた状態でcmdが起動する。
これはcmd.exeのショートカットにオプションを付けて起動しているだけなので、それを倣うと、任意の環境でactivateされた状態でcmdを起動できるショートカットを作成できる。
Anaconda Prompt(デフォルト) %windir%\System32\cmd.exe "/K" C:\Users\(user)\Anaconda3\Scripts\activate.bat C:\Users\(user)\Anaconda3 ↓ %windir%\System32\cmd.exe "/K" C:\Users\(user)\Anaconda3\Scripts\activate.bat C:\Users\(user)\Anaconda3\envs\(env_name)
> conda install (package_name)
でインストール。
> conda search (package_name)
でどんなものがあるか検索できる。
デフォルトのチャンネルにパッケージが無い場合、別のチャンネルからインストールすることもできる。 :: Anaconda Cloud の上の検索ボックスにパッケージ名の一部を入れると、提供しているチャンネルとバージョンがリスト表示される。 ご丁寧にコマンドが記載されているので、そのままコマンドプロンプトに貼り付けると、インストールされる。
ただ、『留意点』の項でも述べたとおり、なるべくなら同一のチャンネルで環境を統一した方がよい。
なるべく、最終的なインストール元がデフォルトチャンネルである状態を保ちたいので、「デフォルトチャンネル以外にしか無いパッケージ」→「デフォルトチャンネルに存在するパッケージ」の順で入れる。
必要なパッケージは人それぞれだが、とりあえず自分が入れるなら以下。
conda update --all conda install -c conda-forge simplekml conda install numpy scipy pandas matplotlib seaborn pyproj python-dateutil
しばらく使ってると、ゴミが溜まってくる。特に一度インストールしたパッケージ（の圧縮ファイル）は、アンインストールしたり新しいバージョンに更新したりしても、キャッシュとして残り続けるため、容量を食う。
> conda clean --all
掃除しないと、気がつけばAnacondaのフォルダが数十GB超えてたとかいうことにもなりかねない。別にこまめにする必要は無いが、たまにはすることを覚えておく。