Python

Last-modified: 2024-10-06 (日) 22:41:26

Webサイト

 

https://www.python.org/
https://www.python.org/downloads/

github
https://github.com/python/
https://github.com/python/cpython/

 

概要

  • 「パイソン」と読む
  • プログラミング言語の一つ。
    AUTOMATIC1111はこれで書かれているからAUTOMATIC1111より先にインストールする。
    Pythonはバージョンによって動作に差があるので新しくても古くてもダメで、指定のバージョンをインストールするように。

関連ページ

 

pythonの更新とA1111内venv仮想環境pythonの更新

例えば現在windowsにpython3.10.6をインストールしてあって、
それを3.10.11に更新したい場合、
windowsにインストールしたpythonを更新するやり方は2通り。

  • OSの機能を使ってpythonアンインストール、もしくはpython3.10.6のインストーラーを使って一旦
    pythonをアンインストールし、そののちpython3.10.11のインストーラーでインストールをおこなう
  • pythonをアンインストールせずpython3.10.11のインストーラーを使ってアップグレードインストール

これらどちらの方法であってもwindowsにインストールされたpythonは更新される。

ところが、
A1111などのAIアプリではpythonをvenv仮想環境に構築しているため、
アプリ内のvenv仮想環境のpythonは更新されずに古いままである。
A1111を新規にインストールしなおせば当然venv仮想環境のpythonも新しいものになるのだけれども、
ただそれだと旧環境のA1111から引き継ぎをする手間がある。
対象のpythonはvenv仮想環境内にあるのだから、A1111をインストールし直さなくてもvenv仮想環境を
構築し直せばvenv内のpythonが更新されるので、venvを再構築するのが楽。
再構築するには、フォルダvenvを中身ごとゴッソリ削除し、A1111などを起動して、再構築をおこなう。
これでA1111などの設定はそのままでvenv仮想環境pythonが更新される。

ではここで、venv仮想環境の再構築をしないとどうなるのか。
A1111などは、venv仮想環境を再構築せずにそのままでも動く。特に不具合はおこらない。
なのでそのまま使うという手もあるけれども、それはpythonを更新した理由次第だろう。
セキュリティが理由なら、venv仮想環境内のpythonもちゃんと更新したほうがよい。
なお、webブラウザのアプリUIに表示されているpythonのバージョンが新しいものに代わって
しまうものがあり、そういうアプリだと一見更新されているように見えてしまうが、それは
まやかし(アプリのバグ)である。
venv再構築しないかぎりvenv\Scripts内にある仮想環境pythonのバージョンは古いままであり、
これはvenv\Scripts内python.exeのファイルのプロパティをみてみればバージョンを確認できる。

それではvenv仮想環境を再構築する場合、
venv仮想環境を再構築する際、python以外のさまざまなモジュールがダウンロードされvenv内に構築
されていくのだが、それらモジュールのなかには以前のインストールしたときと比べてバージョン
アップされていたりするので、以前と全く同じにはならない。
そしてそれが原因でA1111などが動かなくなることがある。これは実際によくある。A1111などの
githubサイトのIssuesやDiscussionsで話題になる。
https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues

そしてpython更新時にこのようなことが起こると、その原因を、pythonを更新したからだと
決めつけてこのpythonは動かないなとど思いこんでしまいがちだ。
実際はpythonを更新していなくてもvenv仮想環境を再構築すると起こるわけだ。
前回venv仮想環境を(再)構築したのが最近なら問題なかろうが、2,3か月前だと起こるかもしれない。
まして半年も前となれば、起こってもなんら不思議ではない。

なので、venv仮想環境の再構築の際は、元に戻せるようにアプリ全体のバックアップを取っておく。
＃そもそもバックアップは普段からやっておけ。venvだけでなく拡張機能の更新などで動かなくなるぞ。

また問題の切り分けをしやすくするためにも、一手間かけておくのもよい。venv再構築手順としては、

1. 作業前にA1111をまるごとアーカイブしてバックアップしておく

  (バックアップは普段からやっておけ)

2. pythonを更新する前に一度A1111のvenv仮想環境の再構築をして正常に動くか確認する

3. windowsにインストールされているpythonを更新する

4. A1111のvenv仮想環境を再度再構築

venv仮想環境の再構築の際は各種モジュールをダウンロードするので時間がかかるわけだが、一度ダウン
ロードするとキャッシュされるので、2回目以降は時間はかからない。なのでそれほど手間はかからない。

でもやはり可能であれば、pythonを更新するのを機会に、A1111などは新規フォルダ造って最新版を
インストールしてしまうのが良いと思う。

 

pythonのwindows用バイナリーをgithubにビルドしてもらって最新版を入手しよう

 

ビルドは初心者向けではないが、ここに記すやりかたは脱初心者の初級者向けといったところ。
中級者や上級者はこの手はつかわないけど、逆にgithub配布元はこのやり方がとても多い。だってgithubだし。

 

そもそもなぜpythonをビルド?

A1111をはじめ、いくつものアプリがpythonを使っているのでpythonをインストールするわけだけど、
そのpython、まずpythonのサイトを見ると、

https://www.python.org

いま2024年秋の主バージョンは、3.12。
それより古い3.11や3.10などは、サポート対象ではあるけどbugfixはおこなわれておらず、security対応だけである。
一方、一番新しい3.13はまだprereleaseなのと、あとgithubにある3.14はalphaなので、これらは新しすぎる。
https://github.com/python/cpython
なので通常であれば、pythonは3.12をインストールしてつかうものである。

ところが、、、
A1111は公式サイトで

https://github.com/AUTOMATIC1111/stable-diffusion-webui
Install Python 3.10.6 (Newer version of Python does not support torch), checking "Add Python to PATH".

と明記しており、Python3.12ではA1111はそのままでは動かない。なぜならPyTorchがサポートしていないからだ。
さらに、 Newer version と書かれていては、これでは3.10.6よりあとの3.10.7などでは動かないかもしれないと
思ってしまっても仕方がない。(実際は3.10.11でも動く)
なのでサイトの指示どおりに3.10.6をインストールしてつかうわけだけど、
でもセキュリティ面で3.10.6は大丈夫なのか？
という不安がある。
いちおう3.10の Maintenance status は security となっており、また End of support も 2026-10となっていて、
https://www.python.org/downloads/
現在もちゃんとsecurity更新はされているので、3.10の最新を使えばsecurity面はクリアできる。
でもここでまた別の問題があり、

https://peps.python.org/pep-0619/
3.10.11: Wednesday, 2023-04-05 (final regular bugfix release with binary installers)

バイナリーのwindowsインストーラーのリリースは3.10.11で お わ り 。

その後の3.10.12以降はバイナリーはなく、ソースコードでしか提供されていない。
そのためかアプリによっては指定versionがバイナリ配布最終の3.10.11になっていたりする。
A1111が古い3.10.6のままの理由はよくわからないが、A1111は3.10.11で問題なく動くので、
windowsでは3.10.11をインストールして使っている人がgithub見てると多いように思われる。
＃ちなみにlinux勢は2024年秋は3.10.14か3.10.15だ。

それでまた先と同じだけど、3.10.11にしたところで、
セキュリティ面で3.10.11で大丈夫なのか？ security対応された最新版(2024年秋)は3.10.15だぞ、
という不安がある。

その答えとしては、セキュリティ上問題があるので、対策された最新のソースコードはリリース
されているのだから、ビルドする。

 

github action で workflow ymlを編集してpythonビルト

ビルドする、と言われても、
pythonのビルドはwindowsにvisual studioをインストールしてビルドするわけだけど、
それが出来る人は既にやっているからわざわざやりかたを書くこともないだろう。
一方、やってない人は、やりかたを書いたところで自ビルドするかというとそうとも思えず。

そこで、githubにビルドしてもらってwindows用インストーラーを手に入れる方法を書くことにする。
githubに3.10の最新版をつくってもらう。なんと無料だ。githubの無料プランの範囲内で出来る。
再度書くが、ここに記すやりかたは初心者向けではないが、脱初心者の初級者向けといったところ。
中級者や上級者はこの手はつかわないけど、逆にgithub配布元はこのやり方がとても多い。だってgithubだし。

 

githubにアカウントを作成

https://github.com

A1111を使っているならgithubのことは既におなじみだろう。
ただ、アカウントを作成しているかというとそうでもないかもしれない。
いちおうGitHub社はマイクロソフトに買収されてマイクロソフト傘下になっているので、
windowsを使っているのならマイクロソフトアカウントを作成しているだろうから、
GitHubのアカウントを作成するのに抵抗はないと思う。
なんならビルドが済んだらGitHubアカウントを閉じとけ。

 

pythonのcpythonをFork

pythonのcpythonのgithub
https://github.com/python/cpython

右上にある Fork をクリックして自分のアカウントにコピー(fork)する。
このとき、

Copy the main branch only

との具合で mainブランチだけforkする にチェックが入っていて、そのままだと3.10が
含まれないので、このチェックは外してから、緑色の Create fork。
すると自分のgithubアカウントのrepositoriesにpythonのcpythonがコピー(Fork)される。

 

cpython repositoriesのActionsを有効化

ビルドなどを自動化するためにgithub Actionsを有効化する。
自分のgithubアカウントのrepositoriesにあるcpythonに移ると、
そこに Actions タブがあるので、Actionsに移動する。
すると中央に緑色でworkflow有効化の enable them と出るので、有効化する。
これでworkflowに書かれた処理が自動的に実行されるようになる。

 

branchをmainから3.10に切り替え

自分のgithubアカウントのrepositoriesにあるcpythonの、Codeに移動。
移った直後はmainブランチになっている。
mainをブルダウンして、3.10ブランチに切り替える。

なお、この切り替えは何度も行うことになる。なにかとmainに戻ってしまうから。

 

github action の workflowファイル build_msi.ymlを編集しインストーラーを入手

3.10ブランチにて、

.github/workflows/ にあるbuild_msi.ymlを編集。
webブラウザ上で、.github, workflows, とたどっていくと build_msi.yml があるのでクリック。
右上のペンの形のボタンをクリックするとEdit編集モードになる。
1カ所編集し、そして1ブロック追記する。

まず一番最後の行の

      run: .\Tools\msi\build.bat --doc -x64

これこのままだと dev 版を debug ビルドする。まぁそれでよいのならそのままでもよいのだけど、
release版をビルドするようにbuildrelease.batを使うべくここを下記に書き換える。

      run: .\Tools\msi\buildrelease.bat -x64

続いて build_msi.yml の最後尾に下記を追記する。

    - name: Upload artifacts
      uses: actions/upload-artifact@v3
      with:
        name: build-artifacts
        path: |
          PCbuild/amd64/

よって最後の数行はこうなる。

    - name: Build CPython installer
      run: .\Tools\msi\buildrelease.bat -x64
    - name: Upload artifacts
      uses: actions/upload-artifact@v3
      with:
        name: build-artifacts
        path: |
          PCbuild/amd64/

編集したら、右上の緑のボタンCommmit changesを押す。
確認画面が出るので、Commit changesを押す。

＃この追記した Upload artifacts はビルド結果を取り出す定番コマンド。
＃ちなみに最後の PCbuild/amd64/ の部分を ./ にすると全体像がわかるのだが、ファイルサイズが大きくなる。
＃なおgithubでコードを自動ビルド自動バイナリー配布していることろは上記に加えて自動リリース用コマンドも
＃追記して全自動化している。この全自動化手法はわりとよく知られているgithub定番。

Commmit changesを押すと自動的にgithub actionが動き出すので、
先のActionsタブに移動する。
Update build_msi.ymlが2つ、オレンジ色になってグルグル回っていれば実行中。
(クリックすると実行の様子を見ることが出来る。)
完了すると緑色に変わる。所要時間は混雑具合によるのだが、30分はかからないと思うけど、
長いと1時間とかそれ以上かかるかも。まぁgithub無料コースだから優先度は低いだろうし仕方ないね。

赤くなったのがあったらそれは後述するbuild.ymlで、macosでコケているだろうからいまは無視する。
緑になったUpdate build_msi.ymlをクリックすると、下のほうにArtifactsがあり、
出来上がったbuild-artifactsがダウンロードできるようになっている。
ダウンロードマークをクリックするとzipファイルでダウンロードされるので、
そのzipを展開して、en-usの中に

python-3.10.なんとか-amd64.exe

とあるのがpythonのwindows用バイナリーのインストーラー。
2024年秋なら3.10.15なので、

python-3.10.15-amd64.exe

コレ。
ダブルクリックするとインストーラーが起動する。
python新規インストールなら新規のインストール画面になるし、
既にpythonインストール済みならアップグレードインストール画面になる。

なお、アップグレードインストールした場合は、windowsのpythonは更新されるが、
A1111などアプリ内のvenv仮想環境内のpythonは更新されずに古いままなので、
それらpythonも更新するためにvenv仮想環境の再構築もする。

 

github action の workflowファイル build.ymlを編集しバイナリを入手

続いて同様にbuild.ymlも編集し、バイナリを入手する。
なおこのときブランチがmainになっていたら3.10ブランチに切り替えること。

3.10ブランチにて、

.github/workflows/
にあるbuild.ymlを編集
webブラウザ上で、.github, workflows, とたどっていくと build.ymlがあるのでクリック。
右上のペンの形のボタンをクリックするとEdit編集モードになる。

build_win_amd64:

のところの最後に下記を挿入する

    - name: Upload artifacts
      uses: actions/upload-artifact@v3
      with:
        name: build-artifacts
        path: |
          PCbuild/amd64/

いちおう build_win_amd64: のところの「最後」とは、この行のこと。

      run: .\PCbuild\rt.bat -p x64 -q -uall -u-cpu -rwW --slowest --timeout=1200 -j0

なおこの行の次は

  build_macos:

とあるように、mac用。
そしてここから下にあるのは

  build_macos:
  ...
  build_ubuntu:
  ...
  build_ubuntu_ssltests:
  ...

これら不要につきゴッソリ削除。結局、先に挿入した部分がbuild.ymlの最後尾となる。

編集したら、右上の緑のボタンCommmit changesを押す。
自動的にgithub actionが動き出すので、先のActionsタブに移動して、出来上がるのを待つ。
なお2つうごいているworkflowのうち片方はbuild.ymlのでもう片方はbuild_msi.ymlのだから、
build_msi.yml側は先と同じのが出来上がるので無駄なので止めてしまっても良い。

さて、インストーラーが既に手に入ったのにbuild.ymlやる意味あるのか、と言われるとそのとおりなのだが、
ネット上の情報だと、インストーラーではなくバイナリーのほうが主流というかそればかりで、
しかもbuildrelease.batではなくbuild.batでやっていて、なんでかというと付属のドキュメントが
そうなっているからだろう。なのでそれらと同じのが欲しい人向けにbuild.yml。

 

cpythonレポジトリの削除、アカウント閉鎖

インストーラーでちゃんと3.10の最新版がインストール出来たら、
念のため編集したbuild_msi.ymlとbuild.ymlをバックアップしたあと、
cpythonレポジトリの削除をする。
自分のgithubアカウントのrepositoriesにあるcpythonに移り、
上の右端のSettingsに移動。
一番下に Delete this repository があるのでここで削除できる。
削除にあたりパスワードなどいろいろと確認されるがそれに従う。

続いてgithubのアカウントを閉じてしまってもかまわない。
むしろ下手にアカウントを残しておくのはトラブルに巻き込まれる元になるのでやめておいたほうがよい。

＃githubで公開されているコードのうち、このようにworkflow ymlファイルが含まれているものは、
＃このようにgithub actionでworkflowを実行するのが、正しいビルド方法のうちのひとつ。
＃また workflow yml が含まれてなくても、自分で workflow を作成して github action 使う手法は
＃いろいろと応用が利く。
＃ただ、github actionは日本語コードまわりがイマイチなので、日本で使ってる人はあんまりいなさそう。