Pythonの環境構築をマスターする(pyenv,venv)(WSL2,Ubuntu利用)(poetry追記)
マスターするとは何か
完全に理解して、人に説明できることである。
とりあえずできればいい、ではなく、ちゃんと応用の効く形で理解することである。
でなければ、忘れてしまうからね。
目次
- マスターするとは何か
- 目次
- 一次情報
- Python環境構築におけるpyenvとvenv
- venvの仮想開発環境で作る
- Pythonの通常のインストール(今回は非推奨とする)
- pyenvを利用したPythonのインストール
- WSL2のUbuntuのインストール
- pyenvのPythonを利用して、venvで仮想開発環境を作る(実践編)
- まとめ
- 追記:poetryの解説
一次情報
一次情報が一番正確。
Python環境構築ガイド
pyenv
venv
あとは構造を理解するためにChatGPTに質問攻めをする。
Python環境構築におけるpyenvとvenv
pyenvとvenvを利用すると、一番綺麗にPython環境が構築できるらしい。
ざっくりと図でまとめるとこんな感じ
pyenv内にPythonをインストールして、pyenv上のPythonを利用してvenvで開発環境を用意する、のが一番最適のよう。
(Dockerで環境構築する場合もあるようだけど、これは今回考えない)
venvの仮想開発環境で作る
venvのメリット
- 1つの仮想開発環境に、一つのPythonと必要なパッケージがインストール可能。
- それによりプロジェクトごとに開発環境を作ることができる。
- ディレクトリを削除すれば開発環境を削除できる。
- PC内のPythonにパッケージをインストールしないため、PC内のPython環境が汚れず、競合や不具合なども起きにくい。
開発環境構築するための前提
- PythonがPCやpyenvにインストールされていて、PCで利用することができる。
- CLI上で仮想開発環境を作成したいディレクトリへ移動している。
手順
venvで仮想開発環境を作る方法を教えてください。
Pythonの標準ライブラリであるvenvを使用して仮想環境を作成する手順は以下のとおりです。
まず、Pythonがインストールされていることを確認します。ターミナルで以下のコマンドを実行します:
python --version
次に、新しい仮想環境を作成します。これは任意の名前(この例ではmyenv)を持つ新しいディレクトリを作成し、その中に仮想環境を設定します:
python -m venv myenv
新しく作成した仮想環境をアクティブにするには、以下のコマンドを実行します:
Windows:
myenv\Scripts\activate
macOS / Linux:
source myenv/bin/activate
アクティブな仮想環境では、pythonとpipコマンドは仮想環境のPythonインタープリタとパッケージを対象とします。つまり、パッケージをインストールすると、それらは仮想環境にのみインストールされ、システム全体のPython環境には影響を与えません。
pip install <package-name>
仮想環境から抜けるには、以下のコマンドを実行します:
deactivate
このコマンドは、仮想環境を非アクティブにし、元のシステム環境に戻します。
以上が基本的なvenvを使用したPythonの仮想環境の作成と管理の手順です。
venvで作る仮想環境は、ディレクトリですか?またそうであった場合、そのディレクトリを削除したら仮想環境が全て削除できると考えていいですか?
はい、その通りです。Pythonのvenvは特定のディレクトリを仮想環境として扱い、そのディレクトリ内にPythonのインタープリタやパッケージなどの環境を構築します。
したがって、そのディレクトリを削除すれば、その仮想環境とそれに関連するすべてのパッケージや設定も削除されます。ただし、この操作は取り扱いに注意が必要です。間違えて重要なデータを含むディレクトリを削除しないように注意してください。
venvまとめ
開発プロジェクト1つにつき、開発環境が1つ用意できて便利。
Pythonの通常のインストール(今回は非推奨とする)
通常のPythonのインストール方法を教えてください。
Pythonのインストール方法は、使用しているオペレーティングシステム(OS)によって異なります。以下に、一般的なOSごとのPythonのインストール方法を説明します。
Windows:
- Pythonの公式サイト(https://www.python.org/downloads/ )にアクセスし、最新のPythonインストーラをダウンロードします。インストーラは、通常、Python 3.x.xという名前で表示されます(xはバージョン番号)。
- ダウンロードしたインストーラを実行し、インストールウィザードに従ってインストールを完了させます。インストール時に、「Add Python to PATH」オプションを選択することをお勧めします。これにより、Pythonがシステムの環境変数に追加され、コマンドプロンプトから利用できるようになります。
- インストールが完了したら、コマンドプロンプトを開いてpython --versionを実行し、Pythonが正しくインストールされたことを確認します。
macOS:
macOSでは、Homebrewというパッケージマネージャを使用してPythonを簡単にインストールできます。
- Homebrewがインストールされていない場合は、公式サイト(https://brew.sh/ )の指示に従ってインストールします。
- ターミナルを開いて、以下のコマンドを実行してPythonをインストールします:
brew install python
- インストールが完了したら、ターミナルでpython --versionを実行し、Pythonが正しくインストールされたことを確認します。
Linux(Debian/Ubuntuベースのディストリビューション):
- ターミナルを開いて、以下のコマンドを実行してPythonをインストールします:
sudo apt update
sudo apt install python3
- インストールが完了したら、ターミナルでpython3 --versionを実行し、Pythonが正しくインストールされたことを確認します。
これらは一般的なPythonのインストール方法ですが、使用しているOSや環境によっては異なる手順が必要な場合があります。その場合は、公式ドキュメントやOSのドキュメントに従ってください。
通常インストールのデメリット
pyenvを利用せず直接PCにPythonをインストールする場合のデメリットを教えてください
pyenvを利用せずに直接PCにPythonをインストールする場合、以下のようなデメリットがあります:
-
複数バージョンの管理が困難: 一台のPC上で複数のPythonバージョンを使いたい場合、pyenvがないと管理が困難です。特定のPythonバージョンを使うためには、システムの環境変数を手動で管理するか、フルパスを指定してコマンドを実行する必要があります。
-
システムのPython環境を汚染する可能性: システムに直接Pythonをインストールすると、システム自体が依存しているPythonパッケージに影響を与える可能性があります。これは、特にLinuxのようなOSでは重要な問題となり得ます。
-
プロジェクト間での環境の切り替えが面倒: 各プロジェクトで異なるPythonバージョンやパッケージを使いたい場合、pyenvがないとその管理が手間になります。これは特に、古いプロジェクトと新しいプロジェクトを同時に扱う開発者にとって大きな問題になります。
-
Pythonバージョンの更新が手間: Pythonの新しいバージョンがリリースされたとき、システムのPythonを更新するのは手間がかかります。特に、新旧のバージョンを並行して使いたい場合、その管理は複雑になります。
これらの理由から、複数のPythonバージョンを管理したい場合や、異なるプロジェクト間でPythonの環境を切り替えたい場合には、pyenvのようなバージョン管理ツールの利用が推奨されます。
上記をプログラミングを始めたての中学生でも分かるように書き換えてくれませんか?
もちろんです!以下にその説明を簡単な言葉でまとめてみました。
-
色んな種類のPythonがある: Pythonには、バージョン2.7や3.6、3.7といった色々な種類があります。それぞれに特長があり、場合によっては違うバージョンのPythonを使いたくなることがあります。でも、これらを全部自分で管理しようとすると、とても大変です。
-
Pythonを使っている他のプログラムへの影響: あなたのPCはPythonを使っている他のプログラムも動かしています。あなたがPythonを直接PCにインストールすると、それが他のプログラムに影響を与えてしまうことがあります。
-
一つのPCで複数のプロジェクトを行う場合: たとえば、古いゲームを作るプロジェクトと、新しいAIロボットを作るプロジェクトの2つを同時にやっているとします。これらのプロジェクトでは、使うPythonのバージョンや、追加のツール(パッケージ)が違うかもしれません。それらを一つ一つ自分で管理しようとすると、大変です。
-
新しいPythonが出たときの更新: Pythonはよく新しいバージョンが出ます。新しいPythonが出たときに、それを使うようにするのは大変です。特に、新しいPythonと古いPythonを同時に使いたい場合、それを自分で管理するのは難しいです。
これらの理由から、Pythonを使うときには「pyenv」のようなツールを使うと、Pythonのバージョンやパッケージを管理するのがとても楽になります。それぞれのプロジェクトで必要なPythonの環境を簡単に作ることができます。だから、Pythonを学び始める時には、pyenvを使うことをおすすめします。
PCにPython3.8.1とPython3.8.2を直接インストールした場合、それぞれどのディレクトリにPythonやその関連パッケージがインストールされますか?
一般的に、Pythonを直接インストールすると、それぞれのPythonバージョンはシステムの特定のディレクトリにインストールされます。これは使用しているオペレーティングシステムによりますが、たとえばLinux系のシステムでは /usr/bin/ や /usr/local/bin/ にインストールされることが一般的です。
Pythonの関連パッケージ(モジュールやライブラリ)はPython自体とは別の場所、特に site-packages というディレクトリにインストールされます。このディレクトリはPythonのインストールディレクトリの下の lib/pythonX.X/ (X.X はPythonのバージョン)の下にあります。
しかし、Python 3.8.1とPython 3.8.2のようなマイナーバージョンが異なるPythonを直接インストールすると、古いバージョンのPythonが新しいバージョンのPythonで上書きされる可能性があります。このため、同じメジャーバージョン(ここでは3.8)の複数のPythonを同時に管理する場合、Pythonのバージョン管理ツール(例:pyenv)を使うことが推奨されます。
なお、Pythonのインストール場所やパッケージのインストール場所を具体的に確認するには、以下のようにPythonインタプリタで確認することができます。
Pythonの通常インストール時の仮想環境作成時のデメリット
pyenvを利用しないで複数pythonでの仮想環境を作ろうとした場合のデメリットは、下記の2つですか?他にもありますか?
- 仮想環境を作るためのpythonコマンドを利用するための環境変数の設定がpythonのバージョンごとに必要。
- 環境変数を設定しない場合は、毎回フルパスでpythonコマンドを利用する必要がある。
これらのやり方をするよりも、pyenv local 3.8.0コマンドでそのディレクトリで利用できるpythonを指定した方が簡単ということですかね?
はい、その理解で正確です。pyenvを使用する主な利点は、Pythonのバージョンを簡単に切り替えることができることです。それは次の2つの主な課題を解決します:
-
環境変数の設定: 各Pythonバージョンの実行ファイルへのパスを設定する必要があります。これは非常に手間がかかり、特に複数のPythonバージョンを頻繁に切り替える場合にはエラーが発生しやすいです。
-
フルパスの使用: 環境変数を設定しない場合、Pythonのバージョンを指定して実行するたびにフルパスを指定する必要があります。これも非常に面倒で、コマンドラインからの操作が複雑になります。
これらの問題を解決するために、pyenvはPythonのバージョンを簡単に切り替えることができます。たとえば、pyenv local 3.8.0というコマンドを実行すると、現在のディレクトリに.python-versionというファイルが作成され、その中に3.8.0と記述されます。これにより、そのディレクトリ(およびそのサブディレクトリ)ではPython 3.8.0がデフォルトで使用されるようになります。
したがって、Pythonのバージョン管理にpyenvを使用することは、Pythonの複数バージョンを効率的に管理し、エラーを最小限に抑えるための良い手段です。
pyenvを利用したPythonのインストール
これはChatGPTに聞いても間違ったこと言いそうなので、公式ドキュメントを参考におこなうべき。
google検索でも公式ドキュメントに書かれていないことをやってる人が散見される。(みんな二次情報を見て記事を書いているからどの記事も正確ではないのでは?もしくはやり方が古いとか。)
- ホームディレクトリに.pyenvディレクトリを作って、そこにpyenvをインストールするのが基本的な流れのよう。
- その後、シェル(bash)が正しくpyenvを認識し利用できるようにするため設定を追加する。
(詳細はドキュメント参照)
下記ざっくり解説。
Gitからpyenvをインストールするやり方
git clone https://github.com/pyenv/pyenv.git ~/.pyenv
について教えてください
git clone https://github.com/pyenv/pyenv.git ~/.pyenv
このコマンドは、Gitというバージョン管理システムを使用して、pyenvというツールのソースコードをダウンロード(クローン)します。
それぞれの部分について詳しく説明します:
-
git clone:これはGitのコマンドの一つで、リモートのGitリポジトリ(ソースコードが保存されている場所)からローカルマシンにコピーを作成するために使用します。
-
https://github.com/pyenv/pyenv.git
:これはpyenvのソースコードが格納されているリモートのGitリポジトリのURLです。GitHubは、ソースコードをホストするためのウェブサービスで、Gitリポジトリを公開するための一般的な場所です。 -
~/.pyenv:これはリポジトリのコピーが保存されるローカルマシン上の場所を指定します。~はホームディレクトリを示し、.pyenvはホームディレクトリ内に作成される新しいディレクトリの名前です。このコマンドを実行すると、~/.pyenvディレクトリが作成され、その中にpyenvのソースコードがダウンロードされます。
このコマンドを実行することで、pyenvというツールを自身のマシンにダウンロードし、使えるようにする準備を行うことができます。
pyenvの環境設定
ubuntuのシェルを調べるにはどのようなコマンドを利用すればよいですか
echo $SHELL
pyenvをインストールした後に、シェルが正しくpyenvを認識し、利用できるようにするための設定手順を示しています。以下、各項目の説明を詳しく行います。
公式ドキュメント参照
-
export PYENV_ROOT="$HOME/.pyenv"
: この行は環境変数PYENV_ROOTを定義し、その値を$HOME/.pyenv
(ホームディレクトリ内の.pyenvフォルダ)に設定します。これにより、pyenvはどこに自身のデータを保存すべきか知ることができます。 -
command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"
: この行は、pyenvコマンドが利用可能かチェックし、利用可能でない場合(command -v pyenvが失敗すると)、pyenvのバイナリが存在するディレクトリ($PYENV_ROOT/bin
)をPATH環境変数に追加します。PATH環境変数はシェルがコマンドを探すディレクトリのリストを保持しており、ここにディレクトリを追加することで、そのディレクトリに存在するコマンドが利用可能になります。 -
eval "$(pyenv init -)"
: この行は、pyenvの初期化スクリプトを実行します。このスクリプトは、pyenvが正しく動作するために必要な環境設定を行います。evalコマンドは、その引数をシェルコマンドとして評価・実行します。
それぞれのコマンドは >> ~/.bashrc や >> ~/.profile などの形で終わっています。これは、そのコマンドの出力を指定したファイル(ここではホームディレクトリ内の.bashrcや.profile)に追記することを示しています。つまり、これらのコマンドは、各設定行をそれぞれのシェル設定ファイルの末尾に追加します。
シェル設定ファイル(.bashrcや.profileなど)は、新しいシェルセッションが開始されるときに自動的に読み込まれ、その中に記述されたコマンドが実行されます。したがって、これらの設定行をシェル設定ファイルに追加することで、新しいシェルセッションが開始されるたびに自動的にpyenvが設定され、利用可能になります。
WSL2のUbuntuのインストール
Windows上のLinux環境でPythonをインストールしてみるための準備。
公式ドキュメント参照。
WSL2のUbuntuは、windowsのどこのフォルダに存在するのですか?
WSL 2 (Windows Subsystem for Linux 2)は、Windows上でLinuxの環境を提供する仕組みで、実際のLinuxのファイルシステムは仮想マシンのような形式で格納され、直接Windowsのエクスプローラーなどからアクセスすることは基本的には推奨されていません。
しかし、WSL 2を使用しているとき、Windows側からWSL 2のファイルシステムにアクセスすることは可能です。\\wsl$
というパスをエクスプローラーのアドレスバーに入力すると、インストールされているWSL 2のディストリビューションのリストを見ることができます。ここから、特定のディストリビューション(例えば、Ubuntu)を選択すると、そのディストリビューションのルートディレクトリが表示されます。
ただし、この方法でアクセスしたWSL 2のファイルシステムに対して、Windows側から直接ファイルの作成や編集を行うことは推奨されていません。なぜなら、LinuxとWindowsではファイルシステムの管理の仕組みが異なるため、Windows側から直接操作を行うと、意図しない問題を引き起こす可能性があるからです。ファイルの作成や編集は、WSL 2の環境内(つまり、WSL 2のターミナルから)で行うべきです。
pyenvのPythonを利用して、venvで仮想開発環境を作る(実践編)
Ubuntuを動かす
公式ドキュメント参照
今回はスタートメニューらからUbuntuターミナルを開いてCLIで動かす。
pyenvのインストール
でUbuntuの/root/.pyenvにpyenvをインストール
git clone https://github.com/pyenv/pyenv.git ~/.pyenv
シェルの設定
echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
echo 'command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(pyenv init -)"' >> ~/.bashrc
echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.profile
echo 'command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.profile
echo 'eval "$(pyenv init -)"' >> ~/.profile
exec "$SHELL"
Pythonビルドの依存関係をインストール
sudo apt update
sudo apt install -y build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev curl libncursesw5-dev xz-utils tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev
Pythonビルドの依存関係をインストール
とはどういう意味ですか
"Pythonビルドの依存関係をインストール"とは、Pythonをソースコードからコンパイル(ビルド)するために必要なソフトウェアやライブラリをインストールすることを指します。
Pythonをソースコードからビルドするには、コンパイラ(ソースコードを実行可能なバイナリに変換するソフトウェア)やライブラリ(特定の機能を提供するソフトウェアの一部)が必要です。これらはPythonのビルドに必要な「依存関係」であり、これらがないとPythonのビルドは成功しません。
例えば、Ubuntuの場合、Pythonをビルドするためには上記のパッケージが必要となります。
pyenvのインストール確認
ここまでできれば、pyenvの準備ができ、Pythonのインストールが可能になる。
pyenv上へPythonのインストール
下記コマンドを1行ずつ実行。
詳細は公式ドキュメント参照。
# pyenvにインストールできるPython一覧を取得(1ページごと)
pyenv install -l | less
>>
・・・略・・・
3.10.8
3.10.9
3.10.10
3.11.0
3.11-dev
3.11.1
3.11.2
# pyenvコマンドでpyenv内にPython 3.11.0をインストール
pyenv install 3.11.0
# pyenvにインストールされたPython一覧を表示)
pyenv versions
>>
* system
3.11.0 (set by /home/XXXX/.pyenv/version)
# システム上で利用するPythonを設定
pyenv global 3.11.0
# 現在利用されているPythonバージョンの確認
python -V
>>
Python 3.11.0
pyenv install -l | less
について教えてください
pyenv install -l コマンドは、pyenvによってインストール可能なPythonのバージョン一覧を表示します。
その出力は通常かなり長いリストになるため、そのままだと全てを表示するのにスクロールが必要となります。
そのため、| less を付けることで、出力をページ単位で見ることができます。less コマンドは、LinuxやUnix系OSで用いられるテキストビューアの一つで、大量のテキストデータをページ単位で読み進めることができます。
具体的には、lessを用いると以下の操作が可能です:
- 矢印キーまたはPage Up/Page Downキーで上下にスクロール
- b キーで前のページに、space キーで次のページに進む
- / キーで検索を行う(検索ワードを入力後Enterキーで検索開始)
- q キーで less を終了
このように、pyenv install -l | less コマンドは、pyenvでインストール可能なPythonのバージョン一覧をページ単位で閲覧するためのコマンドです。
pyenv versionsコマンドについて教えてください
pyenv versions コマンドは、システムにインストールされている Python のバージョンを全て表示するためのコマンドです。
このコマンドを実行すると、pyenv を通じてインストールした全ての Python バージョンがリスト形式で表示されます。また、現在アクティブな(つまり、python コマンドを打った時に使用される)Python バージョンの前にはアスタリスク (*) が表示されます。
例えば、以下のような出力が得られるかもしれません:
$ pyenv versions
3.6.8
3.7.2
* 3.8.0 (set by /home/user/.pyenv/version)
3.9.0
この例では、Python 3.6.8、3.7.2、3.8.0、3.9.0 の四つのバージョンがインストールされており、現在アクティブなバージョンは 3.8.0 であることが示されています。
pyenv global 3.11.0コマンドについて教えてください
pyenv global コマンドは、システム全体でデフォルトに使う Python のバージョンを設定するためのコマンドです。
例えば、pyenv global 3.11.0 というコマンドを実行すると、システム全体のデフォルトの Python バージョンが 3.11.0 に設定されます。これは python コマンドを実行した時にどのバージョンの Python が使用されるかを決定します。
このコマンドはユーザーレベルで設定されます。つまり、異なるユーザーが同じシステムで作業している場合、それぞれのユーザーはそれぞれ異なる Python のバージョンをデフォルトに設定することができます。
さらに、この設定は新しいシェルセッションを開始するたびに維持されます。つまり、一度 pyenv global 3.11.0 を実行すると、その後の新しいターミナルウィンドウや新しいシェルセッションでもデフォルトの Python バージョンは 3.11.0 に設定されたままとなります。
なお、pyenv global コマンドに引数を指定しないで実行すると、現在のデフォルト Python バージョンが表示されます。
venvでの仮想環境構築
# workディレクトリを作り、そこへ移動
cd ~/
mkdir work
cd work
# 念のため利用するpythonを指定、pythonのバージョン確認
pyenv local 3.11.0
python -V
# プロジェクト名で仮想環境を作る
python -m venv <project_name>
# 仮想環境をアクティベート
source <project_name>/bin/activate
# この状態で開発を進める
# この状態で開発を進める
pip install pandas
pip install selenium
git checkout
# 開発が済んだらデアクティベート
deactivate
# 開発環境を削除する場合(ディレクトリ削除)
rm -rf <project_name>
おまけ(requirements.txtやPoetry)
requirements.txtやPoetry(pyproject.toml)を使ってパッケージやそれに伴う依存関係の管理ができる。
Poetry自体が仮想開発環境も作れるようなので、実はvenv利用しなくていいらしい。
まとめ
pyenvを利用してPythonのバージョン管理をするといろいろメリットがある。
pyenv上にインストールしたPythonで、venvで仮想環境を作り開発するとメリットがある。
追記:poetryの解説
poetryの一次情報
バチバチ英語である。
最新のインストール方法やPATHの設定などはこちらを参照するのが一番正確。
poetryってなんだ
poetryって何ですか?
poetry
はPythonの依存関係管理とパッケージングを目的としたツールです。pip
とsetuptools
が提供する機能に加え、より使いやすく、統一されたインターフェースでこれらを処理します。
主な機能としては以下があります:
-
依存関係の管理:
pyproject.toml
ファイルを用いて、プロジェクトの依存関係を明示的に管理します。 -
パッケージインストール:
poetry add
コマンドで新たな依存パッケージを追加できます。 -
仮想環境の管理:
poetry
は自動的に仮想環境を作成し、その環境内でパッケージのインストールや管理を行います。 -
プロジェクトの雛形作成:
poetry new
コマンドで新しいプロジェクトのベースとなるディレクトリ構造とファイルを生成できます。 -
パッケージのビルドと公開:
poetry build
でパッケージをビルドし、poetry publish
でPython Package Index(PyPI)などに公開できます。
このように、poetry
はPythonプロジェクトにおいて多くの作業を効率的に行えるよう設計されています。また、pyproject.toml
一つで全ての設定が完結するため、プロジェクトの設定が非常にシンプルになります。
特に依存関係の管理においては、poetry.lock
というファイルを用いて依存パッケージの厳密なバージョンを記録、管理するため、他の環境でも同じバージョンのパッケージを用いた開発やデプロイが可能です。これにより、「うまく動作するコードが他の環境で動かない」といった問題を大いに減らすことができます。
poetryの使い方
poetryの使い方を教えてください
poetry
はPythonプロジェクトの依存関係管理とパッケージングを効率的に行うためのツールです。以下はpoetry
の基本的な使い方です。
インストール
まずはpoetry
をインストールします。公式のインストール方法は次のようになります。
curl -sSL https://install.python-poetry.org | python3 -
PATHの設定
poetryコマンドをどのディレクトリからでも利用できるようにPATHの設定を行います。
(後述)
プロジェクトの初期化
新しいプロジェクトを作成する場合は、以下のコマンドでプロジェクトを初期化できます。
poetry new my_project
このコマンドでmy_project
という名前の新しいプロジェクトが作成されます。
依存関係の追加
依存関係を追加する場合は、add
コマンドを使用します。
poetry add requests
このコマンドでrequests
ライブラリがプロジェクトに追加されます。
依存関係のインストール
poetry.lock
とpyproject.toml
にリストされている依存関係をインストールする場合は、以下のコマンドを実行します。
poetry install
仮想環境
poetry
は自動で仮想環境を作成してくれます。仮想環境に入るには、以下のコマンドを使用します。
poetry shell
パッケージのビルドと公開
パッケージをビルドする場合は、以下のコマンドを実行します。
poetry build
パッケージをPyPIに公開する場合は、次のコマンドを使用します。
poetry publish
以上がpoetry
の基本的な使い方です。依存関係の管理からパッケージのビルド・公開まで一通りの作業をこのツール一つで完結できるため、非常に便利です。
PATHの設定について教えてください
WSL2上のUbuntuでPoetryをインストールした場合、以下のようにしてPATH
環境変数にPoetryの実行可能ファイルのパスを追加できます。
-
シェルの設定ファイルを開きます。bashを使っている場合は
~/.bashrc
、zshを使っている場合は~/.zshrc
です。以下はbashの場合のコマンド例です。nano ~/.bashrc
-
設定ファイルの末尾に次の行を追加します。
export PATH="$HOME/.local/bin:$PATH"
-
設定ファイルを保存して閉じ、シェルを再起動するか、以下のコマンドを実行して変更を反映させます。
source ~/.bashrc
-
正しく設定されているか確認するために、新しいターミナルセッションで
poetry --version
を実行します。
以上の手順で、Poetryがシステム全体で使えるようになるはずです。注意点として、シェルの設定ファイル名や編集に使うエディタ(上記ではnano
を使用)は環境によって異なる場合があります。その点を考慮に入れてください。
poetry shell
はどのようなときに利用しますか?
poetry shell
コマンドは、プロジェクトの依存関係を含む専用の仮想環境(Virtual Environment)にシェルアクセスを提供します。この仮想環境内では、プロジェクトで必要とされる特定のPythonバージョンやライブラリが使用されるため、環境ごとの依存関係の問題を防ぎます。
以下はpoetry shell
を使用する一般的なシナリオです:
-
依存関係のテスト: 仮想環境内でコードを実行することで、依存関係が正しく解決されているか確認できます。
-
デバッグとトラブルシューティング: プロジェクト専用の環境でコードを実行することで、他のプロジェクトやシステム全体の設定と干渉することなくデバッグやトラブルシューティングが行えます。
-
スクリプトの実行: プロジェクトに特有のスクリプトやツールを、そのプロジェクトの依存関係条件下で安全に実行できます。
-
マイグレーションやバッチ処理: データベースのマイグレーションやバッチ処理など、一時的に実行する必要がある処理をプロジェクトの環境で確実に実行できます。
-
プロジェクトの切り替え: 複数のプロジェクトを並行して作業する際、
poetry shell
を用いることで、各プロジェクトの仮想環境に簡単に切り替えることができます。
poetry shell
は、プロジェクトに依存する特定の作業を行う際に非常に便利です。仮想環境を明示的にアクティベートすることで、その環境特有の問題を解決したり、新しい機能を安全に試すことができます。
poetry new my_project
は新しいディレクトリを作っただけで、このディレクトリ自体が仮想環境というわけではないですか?
poetry shell
コマンドを流したときのみ、このディレクトリが仮想環境になりますか?
poetry new my_project
は、新しいPythonプロジェクトの雛形(テンプレート)を作成しますが、このディレクトリ自体は仮想環境ではありません。このコマンドは基本的にmy_project
という名前の新しいディレクトリを作成し、その中にpyproject.toml
、README.rst
、tests/
ディレクトリなど、Pythonプロジェクトの基本的な構造を生成します。
仮想環境はpoetry install
やpoetry add
を初めて実行したときに、裏側で自動的に作成されます。この仮想環境はプロジェクトディレクトリ内にあるわけではなく、通常はユーザーのホームディレクトリの下や特定の管理ディレクトリに格納されます。
poetry shell
を実行すると、この仮想環境がアクティベートされ、シェルセッションがその環境内で実行されるようになります。この状態でPythonスクリプトを実行したりパッケージをインストールすると、それらはこの仮想環境内で行われます。
つまり、poetry shell
コマンドを流すことで仮想環境がアクティベートされますが、my_project
ディレクトリ自体が仮想環境になるわけではありません。仮想環境は別の場所に格納されていて、poetry shell
でその環境を利用できるようになる、という流れです。
poetryでプロジェクトを作り、poetry addやpoetry installなどをしたときに、別の場所に仮想環境が作られるということですか?今後このディレクトリでpoetry addなどをしたときには、自動で対応する仮想環境にパッケージがインストールされますか?
はい、その通りです。poetry
でプロジェクトを作成し、poetry add
やpoetry install
を実行すると、そのプロジェクトに関連付けられた仮想環境が別の場所に作成されます。この仮想環境は通常、ユーザーのホームディレクトリや特定の管理ディレクトリに格納されることが多いです。
その後、そのプロジェクトディレクトリ内でpoetry add
やpoetry install
を再度実行すると、自動的にそのプロジェクトに関連付けられた仮想環境に対して操作が行われます。すなわち、新しいパッケージがインストールされたり、既存のパッケージが更新されたりします。
このようにpoetry
はプロジェクトと仮想環境をスマートに関連付けて管理するので、手動で仮想環境を切り替えたりする必要がありません。プロジェクトディレクトリでpoetry
コマンドを実行するだけで、対応する仮想環境に適切にパッケージがインストールまたは管理されます。これがpoetry
を使う大きな利点の一つです。
poetryの使い方をまとめると
- PCにpoetryをインストールする
- poetryを使って開発用のディレクトリを作る
- そのディレクトリでpoetry add <パッケージ> を行うと、そのディレクトリの仮想環境にそのパッケージがインストールされる
- poetry install を行うと、インストールしたパッケージの依存関係もインストールする
- この状態で開発を行う
ということで正しいですか?
はい、その説明は基本的に正確です。具体的なステップに分けると以下のようになります。
-
PCにpoetryをインストール: 最初に
poetry
をインストールする必要があります。通常はcurl
やpip
を用いてインストールします。curl -sSL https://install.python-poetry.org | python -
または
pip install poetry
-
新規プロジェクトを作成:
poetry new <プロジェクト名>
で新しいプロジェクトを作成します。poetry new my_project
-
ディレクトリに移動して依存関係を追加: 新しく作成したプロジェクトのディレクトリに移動して、必要なパッケージを追加します。
cd my_project poetry add requests
このコマンドを実行すると、自動的に仮想環境が作成され、
requests
パッケージがその環境にインストールされます。 -
依存関係をインストール: 既存の
pyproject.toml
とpoetry.lock
がある場合、poetry install
でそれらの依存関係を一括でインストールします。poetry install
-
開発を行う: 以上のステップが完了したら、プロジェクトの開発を行います。
poetry run
を使って仮想環境内のスクリプトを実行することも可能です。poetry run python my_script.py
このようにして、poetry
を使うことでPythonのプロジェクト管理が効率的に行えます。特に、poetry.lock
による依存関係の厳密な管理は、プロジェクトが大きくなるにつれて非常に役立つ機能です。
poetryでのパッケージ管理
poetry add した後は基本的にpoetry install しておいた方がいいですか?
poetry add <パッケージ名>
コマンドを実行すると、指定したパッケージがプロジェクトの仮想環境にインストールされ、同時に pyproject.toml
と poetry.lock
ファイルも更新されます。この時点で、実質的には poetry install
を実行しなくても、新しい依存関係は既に反映されているわけです。
ただし、以下のようなケースで poetry install
を実行することが有用です。
-
新しい環境でセットアップ: 別のマシンや新しい仮想環境でプロジェクトをセットアップする際には、
poetry install
でpoetry.lock
ファイルに基づいて依存関係を一括でインストールできます。 -
依存関係の整合性:
poetry.lock
ファイルが更新された場合(例:他の開発者が新しいパッケージを追加してリモートリポジトリを更新した)、poetry install
を実行することで、全ての依存関係を整合性のある状態に保つことができます。 -
明示的なインストール:
pyproject.toml
ファイルを手動で編集した場合、その変更を適用するためにpoetry install
を実行する必要があります。 -
プロジェクトの初回セットアップ: プロジェクトを初めてクローンまたはダウンロードした場合、
poetry install
を実行して依存関係をインストールする必要があります。
基本的には、poetry add
の後にわざわざ poetry install
を実行する必要はありませんが、上記のような特定の状況で実行すると有用です。
poetryで作ったプロジェクトディレクトリはvenvのようにアクティベートして利用したりしなくてよいのですか?
poetry
で作成したプロジェクトディレクトリは、venv
のように明示的にアクティベートする必要は基本的にありません。poetry
は自動的に仮想環境を管理してくれるため、特別な手続きなくその環境で作業ができます。
ただし、仮想環境を明示的にアクティベートしたい場合は、poetry shell
コマンドを使うことができます。
poetry shell
このコマンドを実行すると、新しいシェルセッションが開始され、そのセッション内ではpoetry
が管理する仮想環境がアクティベートされます。これはvenv
のsource <venv>/bin/activate
に似た動作をします。
poetry shell
は主に以下のようなケースで便利です:
- プロジェクトに関連する複数のコマンドを連続して実行する場合。
- IDEやエディタが仮想環境を自動で検出しない場合。
このように、poetry
では明示的なアクティベーションはオプションですが、必要なケースに応じて行うことができます。それ以外の作業では、poetry run <コマンド>
やpoetry add <パッケージ>
などのpoetry
のコマンドをそのまま使用することで、適切な仮想環境で作業が行われます。
venv + pipと比べてpoetryを使うべき理由を教えてください
venv
とpip
も非常に便利なツールですが、poetry
は以下のような点で優れている場合があります。
1. 依存関係の管理
-
poetry
はpyproject.toml
とpoetry.lock
ファイルで依存関係を厳密に管理します。これにより、開発とデプロイメントがより簡単になります。
2. 簡潔なコマンド
- パッケージの追加、削除、アップデートなどが簡潔なコマンドで行えます。例えば、
poetry add <パッケージ名>
ですぐに依存関係を追加できます。
3. 仮想環境の自動管理
-
poetry
は仮想環境を自動的に作成し、管理します。これにより、手動で環境をセットアップする手間が省けます。
4. 複数バージョンのPythonサポート
-
poetry
ではpyproject.toml
でPythonのバージョンを指定することができます。これにより、異なるプロジェクトで異なるPythonバージョンを簡単に管理できます。
5. 依存関係の解決
-
poetry
は依存関係の解決が高度であり、互換性のないパッケージが導入されるリスクを低減します。
6. パッケージの公開
-
poetry
を使うと、PyPIにパッケージを簡単に公開することができます。これにはpoetry publish
コマンドを使用します。
7. スクリプトのサポート
-
pyproject.toml
内でスクリプトを定義でき、poetry run
で実行できます。これにより、プロジェクト固有の作業を簡単に自動化できます。
8. 一貫性
-
poetry
は依存関係、仮想環境、パッケージビルド、公開までのワークフローを一元化します。これにより、他のツールを組み合わせて使用するよりも一貫性があります。
これらはpoetry
が有用なケースをいくつか示していますが、すべてのプロジェクトやチームに適しているわけではありません。既存のツールとの互換性やチームメンバーの習熟度、プロジェクトの要件に応じて最適なツールを選ぶことが重要です。
poetry
を利用する場合はvenv
を利用する必要はないですか?
poetry
を利用する場合、venv
(Pythonの仮想環境)を明示的に作成・管理する必要は基本的にありません。poetry
自体がプロジェクトごとの依存関係と仮想環境の管理を行ってくれるので、その機能に依存することが一般的です。
具体的には、poetry
で新しいPythonプロジェクトを始めると、自動的にそのプロジェクト専用の仮想環境が作成されます。poetry add
やpoetry install
を使用すると、この仮想環境に依存パッケージがインストールされます。また、poetry shell
コマンドを使えば、その仮想環境内でシェルを起動できます。
したがって、poetry
を使用する際には、venv
を手動で管理する必要は通常はありません。ただし、何らかの特別な理由でvenv
のような手動での仮想環境管理が必要な場合もあるかもしれませんが、そのようなケースは少ないでしょう。
チーム開発をする場合でも同様ですか?
はい、チーム開発の場面でもpoetry
は非常に有用です。実際、多人数での開発が行われる環境では、依存関係の管理が特に重要になるため、poetry
のようなツールが役立ちます。以下に、チーム開発におけるpoetry
の利点をいくつか挙げてみましょう。
-
依存関係の整合性:
poetry.lock
ファイルによって、全チームメンバーが同じバージョンの依存関係を持つことが保証されます。 -
簡単なセットアップ: 新しいチームメンバーは、リポジトリをクローンして
poetry install
を一回実行するだけで、必要な全ての依存関係をインストールできます。 -
依存関係の更新が容易: 一元管理された
pyproject.toml
とpoetry.lock
ファイルを更新することで、依存関係の追加や更新が簡単に行えます。 -
仮想環境の自動管理: 各メンバーが手動で仮想環境を作成・管理する必要がなく、
poetry
がその役割を担ってくれます。 -
互換性と移植性:
poetry
は多くのプラットフォームとPythonバージョンで動作するため、チームメンバー間での環境差異を最小限に抑えられます。
以上のように、poetry
は依存関係の管理や仮想環境のハンドリングを効率的に行えるため、チーム開発においても高い有用性があります。したがって、チーム開発においてもvenv
を明示的に使用する必要はありません。
pyproject.toml
とpoetry.lock
がプロジェクトディレクトリに存在していれば、それで開発環境の同一化ができると考えてよいですか?
はい、その考え方は基本的に正しいです。pyproject.toml
とpoetry.lock
がプロジェクトディレクトリに存在している場合、これらのファイルによってプロジェクトの依存関係とそのバージョンが一元管理されます。
-
pyproject.toml
: このファイルにはプロジェクトで使用するパッケージとそのバージョン範囲が定義されています。これにより、プロジェクトに何が必要かが明示されます。 -
poetry.lock
: このファイルには、実際にインストールされた依存関係の具体的なバージョンが記録されています。これにより、全ての開発者が同じバージョンの依存関係を使用できるようになります。
チームメンバーがプロジェクトをクローンした後、poetry install
コマンドを実行すると、poetry.lock
に基づいて同じ依存関係がインストールされます。これにより、開発環境が同一化されるわけです。
ただし、以下のような点にも注意が必要です。
-
Pythonバージョン: 使うPythonのバージョンも一致している必要があります。これは
pyproject.toml
で指定できますが、Python自体のインストールは手動で行うか、pyenv
などを使って管理することが多いです。 -
システムレベルの依存関係: OSレベルで必要なライブラリやツールは、
poetry
では管理されません。これについては、README
やドキュメントで明示することが一般的です。 -
環境変数: 環境変数に依存する設定(APIキーなど)は、別途管理する必要があります。
-
データベースなどの外部サービス: データベースやキュー、キャッシュなど、外部のサービスとの接続情報も一致している必要があります。
これらに注意して環境を整えれば、pyproject.toml
とpoetry.lock
を使って効率よく開発環境を同一化できます。
プロジェクトをクローンしてくる場合は、
poetry new my_project
は不要で、クローンしてきたディレクトリにpyproject.toml
とpoetry.lock
が存在していれば自動的にpoetryで作られたディレクトリと判断されますか?
はい、その通りです。poetry new my_project
は新しいプロジェクトを始めるときに使用するコマンドですが、既に存在するプロジェクトをクローンする場合には必要ありません。
プロジェクトディレクトリにpyproject.toml
とpoetry.lock
が存在していれば、そのディレクトリはPoetryで管理されているとみなされます。この状態でpoetry install
を実行すると、poetry.lock
またはpyproject.toml
に基づいて依存関係がインストールされます。
簡単にまとめると、既存のPoetryプロジェクトをクローンした場合の手順は以下のようになります。
- プロジェクトをクローンします。
- クローンしたプロジェクトディレクトリに移動します。
-
poetry install
コマンドを実行して依存関係をインストールします。
これで、プロジェクトで必要な依存関係がインストールされ、開発を始められる状態になります。
poetryの仮想環境
poetry shell
した状態で例えばDjango
のコマンドdjango-admin startproject config .
する必要がありますか?
はい、poetry shell
で仮想環境に入った状態でdjango-admin startproject config .
を実行するのが一般的です。これによって、poetry
で管理されている仮想環境内のPythonとDjangoを使って新しいプロジェクトを作成します。
仮想環境内で作業を行う理由は以下の通りです:
-
依存関係の分離: 仮想環境を使用すると、プロジェクトごとに依存関係を分離できます。これにより、異なるプロジェクトで異なるバージョンのライブラリを使用することができます。
-
環境の一貫性: 仮想環境を使用することで、開発環境と本番環境での一貫性を保ちやすくなります。
-
コマンドの可用性: 仮想環境内では、
poetry add
などでインストールしたパッケージに関連するコマンド(この場合はdjango-admin
)が簡単に使用できます。
したがって、poetry shell
で仮想環境に入ってからdjango-admin startproject config .
を実行することをお勧めします。
poetry addなどはpoetry shellしてからやらなくていいのですか?
poetry add
などの依存関係に関する操作は、poetry shell
で仮想環境に入っていなくても実行できます。これらのコマンドはプロジェクトの pyproject.toml
ファイルと poetry.lock
ファイルを更新し、指定された依存関係を仮想環境にインストールします。
具体的には:
-
poetry add <パッケージ名>
: パッケージを仮想環境に追加し、pyproject.toml
とpoetry.lock
ファイルを更新します。 -
poetry remove <パッケージ名>
: パッケージを仮想環境から削除し、pyproject.toml
とpoetry.lock
ファイルを更新します。 -
poetry update
: すべて、または指定された依存関係のパッケージを最新バージョンに更新します。
これらのコマンドは、poetry shell
で仮想環境に入っていない状態でも正しく動作するように設計されています。
一方で、django-admin startproject
や python manage.py runserver
などのコマンドは、インストールしたDjangoを使って具体的な作業を行うため、これらは通常 poetry shell
で仮想環境に入った後に実行します。
つまりパッケージのインストールなどはディレクトリでおこなえばいいけれど、djangoコマンドを使う場合は仮想環境に入らないといけないのですね?なぜですか?
そうです、基本的にパッケージのインストール(poetry add
など)は仮想環境に入らなくても大丈夫ですが、Djangoのようなフレームワークやライブラリが提供するコマンドを使う場合(django-admin startproject
など)は、仮想環境内で実行するのが一般的です。
これにはいくつか理由があります:
-
依存関係の隔離: 仮想環境はプロジェクトごとに独立した環境を提供します。これにより、プロジェクトで必要な特定のバージョンのパッケージを使用することができ、他のプロジェクトやシステム全体の設定と干渉しないようになります。
-
コマンドの可用性:
poetry add
で追加したパッケージが提供するコマンドは、通常、仮想環境内で簡単に使用できるようになります。このことが、特定のプロジェクトで必要なツールやコマンドを簡単に管理できるようにします。 -
環境の一貫性: 仮想環境内で開発作業を行うことで、開発環境と本番環境の一貫性を保ちやすくなります。これは、将来的にデプロイメントや他のメンバーとの協力をスムーズにするために重要です。
仮想環境外でコマンドを実行すると、システム全体にインストールされたパッケージやPythonバージョンが使用される可能性があります。これは、予期しない問題やバージョンの不整合を引き起こすリスクがあります。したがって、仮想環境内でコマンドを実行するのが一般的なベストプラクティスです。
以上の点を考慮して、具体的な作業を行う場合は仮想環境に入ることが推奨されます。
仮想環境に入ってからpoetry addなどを行っても問題ないのですか?だとしたらまずpoetry shellで仮想環境に入ってから作業をした方がいいですかね?
poetry add
や他のPoetryコマンドを仮想環境(poetry shell
)内で実行しても全く問題ありません。実際、一部の開発者はまずpoetry shell
で仮想環境に入ってから全ての作業(依存関係の管理、開発、テスト等)を行うことを好む場合もあります。
以下はそのように作業するメリットです:
-
環境の一貫性: 仮想環境内で全ての作業を行うことで、依存関係やPythonのバージョンが一貫した状態を保ちやすくなります。
-
シンプルなワークフロー: 仮想環境内で全てを行うことで、作業フローが単純になり、何がどの環境で実行されているのかを容易に把握できます。
-
少ないコンテキストスイッチ: 仮想環境を頻繁に有効化・無効化する必要がなく、集中して作業できます。
一方で、仮想環境外でpoetry add
やpoetry update
を行っても問題はありません。このような依存関係の管理コマンドは、Poetryが管理する仮想環境に対して操作を行いますので、仮想環境内であろうと外であろうと、結果は同じです。
どちらの方法が良いかは、個々の開発者やプロジェクトの要件による部分もありますので、自分がどの方法で作業がしやすいか試してみることをお勧めします。
Discussion