conda環境で発生した問題
python環境設定、及び各種解析のためのアプリケーションの管理のためにmimiconda3
& conda-forge
channelを使用しているが、しばらく前からなかなか解決しない依存性の問題を抱えてしまい、困っていた。症状としては、conda
をアップデートすることも、新しく環境をcreateして必要なpackageをインストールすることもできず、現存する環境のみ使用できるような状況にほぼ近い感じになっていた。conda update -n base -c conda-forge conda
をしようとしても、An unexpected error has occurred.
でレポートが作成されて、updateができない状態であり、下のリンクに近い。
- anacondaをアップデートできない
- stackoverflow: An uxexpected error has occured. Conda has created the above report. Upload/ Report not sent
- stackoverflow: The environment is inconsistent, please check the package plan carefully
調査していくと、condaをアンインストールしてまた再インストールする手順等が比較的出てくるような気がした。万が一バックアップやレストアに失敗すると影響が甚大なので、手をつけるのが億劫になっていたが、conda周りの解析環境整理と再構築を実施することにした。
以下の手順が最適なものかは分からないが、依存性でcondaが問題を抱えてしまいアップデートも新規導入もできなくなってしまった際の再構築した記録として記載したい。
解決のための手順
上述したように、問題はupdateをかけた時に、unexpected errorでアップデートも新規package installもcreate environmentも期待通りに実施できないことである。condaを一度uninstallして、再度installし、バックアップしておいた旧環境のenvを再構築すれば良いかもしれないが、万が一レストアできない状況になることを考え、極力uninstallのステップは踏みたくない。これに対して、大まかには以下の手順で問題の解決を試みた。
- 現在のenv含めcondaの環境、.condarc、.bashrcの記述、その他condaに関連するファイルのバックアップを実施する。
conda install --revision=REVNUM
によるロールバックを実施し、問題がなかった頃のrevisionに戻る。conda install conda=VERSION
により、condaのバージョンを上げる。- condaによる環境設定が再び可能になったかを確認。
- 今回の問題を引き起こしたと考えられる(base)環境での依存性に関係した問題(?)を引き起こさないために、baseは新しいpackage等を導入しないようにして、analysis用の別の環境を構築する。
1. バックアップ
ホーム下でcondaに関連する.condarc
の記述、隠しディレクトリ.conda
下の内容、等々をbackup dir
に保存したほか、ymlファイル等をそれぞれの環境で作成して保管した。HOME下にある.condarc
には、
channels:
- conda-forge
pkgs_dirs:
- /path/to/modified/package/dirs/pkgs
また、フォルダ.conda
下には、entironments.txt
があり、構築してある環境のpathが格納されている。.bashrc
には、conda
initializeの記載がインストール時に記載されている。特にバックアップする必要はないと思ったが、現状の記録のために保存した。
Revision情報
パッケージの導入、アップデート、削除等の情報をconda list -n ENV --revisions
で見ることができる。今回のinconsistencyの検証のために閲覧し、今後問題を見返したくなった時のために、環境ごとにテキストファイルで保存した。
# For each environment, save revision information
conda list -n base --revisions > check_revisions_base.txt
...
YML file
conda document
に記載があるように、現在の環境を.yml
ファイルとして出力することができる。
# For each environment, save YML files for future rebuild of the environment
conda env export -n base > environment_base.yml
このようにして出力したり、自ら編集したりした.yml
ファイルは、将来的に環境をrebuildするのに使用できる。
Explicit specification file
同一の環境を同じプラットフォーム上に構築するための情報をexportすることができるようだ。
Building identical conda environments – conda documentation
You can use explicit specification files to build an identical conda environment on the same operating system platform, either on the same machine or on a different machine.
これで、何か起こった際に一から再構築するための準備を一応できたと考え、condaのロールバックを実施することにした。
2. 以前のrevisionにロールバック
現在起こっている依存性の問題と、そのせいでcondaがアップデートできなくなっていることを解消するために、問題が起きていなかった時期の状態までロールバックして過去の環境をレストアし、そこから再度最新のcondaにアップデートすることを考えた。ロールバックすることで、それまでに導入したパッケージはbase環境から失われてしまうが、その前にbase環境をコピーして新しい環境を作っておくことで、一応現状の環境が使いたくなった時のバックアップを確保した上でbase環境に手を入れることができる。
Cloning an environment – conda documentation
# You can make an exact copy of an environment by creating a clone of it: conda create --name myclone --clone myenv
実際の実行では、HOME下のminiconda3ではなく別のディレクトリに環境をクローンするために-p
を使用した。
conda create -p /path/to/project/dir/env/base_2 --clone base
これでbaseをいじって万が一変なことをしてしまったとしても、base_2
を使って以前の解析ができる。
準備ができたところで、上述のrevisionの情報と、そこで導入されているパッケージ、不具合がみられ出した時期を照合して、どこまでロールバックしてやれば良いかにあたりをつけた。その上で、以下の要領でレストアを実施した。
Restoring an environment – conda documentation
conda install --revision=REVNUM
# rollback to the previous revision
conda install -n base --revision={int}
不具合が生じた時にロールバックして環境をレストアすることについては、調べていてあまり第一の選択肢として上がっていなかったような気がする。以下のサイトでコメントしている人がいた。
The environment is inconsistent, please check the package plan carefully – stacjoverflow
If the other solutions don’t work, reverting the environment can fix this.
Use conda list –revisions, pick a revision number, and use conda install –revision [#] going back step-by-step until everything works again.
上の解決方法のいくつかは実際に実施したが、自分が経験ではうまくいかず、ロールバックして綺麗にする方法がうまく行った。ロールバック実行後、conda
updateを実施できる状態になり、unexpected error
でエラーレポートを吐いて先に進めない状態から脱することができた。conda -V
により確認すると、ロールバック直後には、指定したrevisionのところに記載されていたconda
versionまで巻き戻っていた。
ここで生じた問題点
そこからconda update conda -n base -c conda-forge
を実行すると、revisionデータで見た時の、ロールバックした状態の一つ上のバージョンまでupdateされた。期待していたこととしては、現在一番最新のconda(実施時には23.11.0)までアップデートされると思ったが、そのずいぶん手前までしかアップデートされなかった。
3. condaのversion up
上述のように、ロールバックして依存問題のない環境まで巻き戻ることはできたのだが、別の問題として、condaのバージョンを最新のものまでアップデートすることができない状態が生じた。それ以外のパッケージはアップデートすることができた。
# 抜粋
==> WARNING: A newer version of conda exists. <==
current version: 22.11.1
latest version: 23.11.0
Please update conda by running
$ conda update -n base -c conda-forge conda
Or to minimize the number of packages updated during conda update use
conda install conda=23.11.0
# All requested packages already installed.
メッセージ通りにconda updateを実施しても、同じメッセージが出力されるだけでどうしても23.11にアップデートされなかった。どうしてこのような状態になっているのかはよく分からなかった。解決方法としては、最新のcondaのインストーラーをダウンロードしてきて再インストールすることだと思われたが、同じくメッセージに書かれているバージョン指定したインストールを実施してみることにした。
conda install conda=23.10
condaのバージョンは最新のものや戻ったrevisionでのバージョンに近いものなどいくつかを試してみたが、時間がかかりすぎるものもあり、結果的に23.10に指定した時にうまく行った。これによって、v23.10.0までjump upできた。
続けて、ここから最新のversionにアップデートできるのかを試行した。
conda update conda -n base -c conda-forge
今度はうまく行って、最新の23.11.0にcondaをアップデートすることができた。
これで、base環境に生じていた依存性の不具合を解消し、condaを最新のバージョンまでjump upさせることができたと考えられる。続けて、condaにより解析用の環境を別途再構築することにした。
4. .condarcの設定
conda
createの際に便利なように、create_default_packages
を.condarc
に設定し、新しい環境を作る際にデフォルトでインストールするパッケージを記載しておくことにした。
# Set create_default_packages on .condarc
# Frequently used python packages:
conda config --add create_default_packages ipython
conda config --add create_default_packages jupyterlab
conda config --add create_default_packages pandas
conda config --add create_default_packages numpy
conda config --add create_default_packages scipy
5. 解析環境の構築
(base)
に変わる解析環境として、(ana)
を構築する。
-
Status key
feature:
new features, bugfixes, and security fixes are accepted.prerelease:
feature fixes, bugfixes, and security fixes are accepted for the upcoming feature release.bugfix:
bugfixes and security fixes are accepted, new binaries are still released. (Also called maintenance mode or stable release)security:
only security fixes are accepted and no more binaries are released, but new source-only versions can be releasedend-of-life:
release cycle is frozen; no further changes can be pushed to it.
上記のpython.orgで確認すると、現在のstable最新版は3.12ということで、python=3.12
にして環境構築することにした。これまで3.9でずっといたので、だいぶ上げることになった。
# Generate ana environment
# For this environment, python 3.12 was specified.
conda create -p /path/to/my/private/miniconda3/envs/ana python=3.12
継続して、解析時に頻度高く使用しているものとして、以下のパッケージを導入することにした。
- seaborn
- matplotlib
- scikit-learn
- openpyxl
- xlrd
markdown関係に必要なもの
nbconvert: Convert Notebooks to other formats
Using
nbconvert
enables:presentation of information in familiar formats, such as PDF.
publishing of research using LaTeX and opens the door for embedding notebooks in papers.
collaboration with others who may not use the notebook in their work.
sharing contents with many people via the web using HTML.
documentationのインストールチュートリアルに従い、必要なパッケージ等の導入を実施した。
# nbconvertとpandocの導入
conda install nbconvert pandoc
# TexLiveのインストール
# 以下、TeXLiveサイトの通り。
# サイズが大きいので、余裕のある場所を選んで指定した。
# documentationを見るに、htmlへの変換はTeXなしでも可能だが、pdfへはTex導入が必要のようだ。
# TexLiveに必要なものがまとめられているようだが、condaで検索したところtexlive-coreしか
# インストールすることができないようだったので、本家サイトにそってインストールした。
#
# Make install location dir
cd /path/to/install/applications
mkdir Tex
mkdir Tex/personal
# Download installer
cd /path/to/installer/downloaded/dir
wget https://mirror.ctan.org/systems/texlive/tlnet/install-tl-unx.tar.gz
zcat < install-tl-unx.tar.gz | tar xf -
cd install-tl-*
# Execute installation
perl ./install-tl --texdir=/path/to/install/applications/Tex --texuserdir=/path/to/install/applications/Tex/personal
# Add path
export PATH="/path/to/install/application/Tex/bin/{architecture}:$PATH"
export MANPATH="/path/to/install/application/Tex/texmf-dist/doc/man:$MANPATH"
export INFOPATH="/path/to/install/application/Tex/texmf-dist/doc/info:$INFOPATH"
終わりに
condaの環境に問題が生じる要因としては、環境に新しいパッケージが野放図に追加されていくことにより依存性の問題が生じて、アップデート等含めて様々な操作の障害になっていくことが考えられる。特に、base環境は他の環境とは異なり削除することが難しいため、baseは実質的には汚さずに置いておき、実際の解析環境や、特殊な用途のパッケージを導入する環境を個別に作成する方が良いのかもしれない。問題が起きたときに個別の環境をremoveすることで対応することができる。
依存性の問題を生じさせないためには、コンフリクトを生じさせないように用途に応じて個別に環境構築していくことが良いように思われるが、ホーム下にcondaを置いてしまっている場合は、たくさん環境を作っているとdisk
usageを圧迫してしまう可能性がある。プロジェクトごとの環境はプロジェクトディレクトリに格納したり、余裕がある場所に環境格納用のディレクトリを指定し、conda create
の際に-p
でpath指定で構築するというのが良いかもしれない。