独自のコードをインストールする#

conda 環境があります。それは動作します。おそらく、GDAL、HDF5、またはその他のコンパイルされた科学的依存関係など、インストールが困難なパッケージが含まれている可能性があります。

ローカルで記述しているコードもあります。おそらくスクリプトとして始まったか、すでに Python パッケージとして編成されているのかもしれません。そのコードを、GDAL、HDF5、およびすでにインストールされている他のツールと同じ環境内で使用したいと考えています。

コードを conda 環境にインストールする手順は、まず conda 環境をアクティブ化して「conda activate your_env_name」、次にこれを実行します: python -m pip install -e 。 --no-deps。これが「pip install -e .」と書かれていることもあります。このコマンドの詳細については、以下の完全なコマンドセクションを参照してください。

pip install コマンドを初めて見る場合は、ここで何が起こっているのかよくわからないかもしれません。 Conda が環境を作成したのに、なぜ今インストールに pip を使用しているのでしょうか?一般的に conda と pip を混合しないようにするというガイダンスを聞いたことがあるかもしれません。すでに conda と pip を混合しているかもしれませんが、まったく問題ありません。また、pip install -e . は問題なく動作しているようで、実際にやろうとしていることに戻ることができるので、まったく気にしないかもしれません。 (最後の人があなたなら、おそらくこのページも読んでいないでしょう)。いずれにせよ、これらの状況はすべて完全に理解できるものであり、あなたが経験してもまったく問題ありません。

それで...なぜピップ?簡単に言うと、ここでは conda と pip が異なる仕事をしているということです。

少し長く、ほとんど謝罪的な答えですが、これは Python のパッケージ化がどのように機能するかについての現在の人間工学のようなもので、正直に言って?私たちのほとんどは、このわかりにくい痛みのポイントを筋肉の記憶に変えています。しかし、あなたはそうではありません。あなたはここに来たのは初めてです。そしてあなたは...何ですか？そして、あなたがそのように感じるのも当然です。

それで、ここで何が起こっているのでしょうか？ conda は、Python ランタイム、コンパイルされたライブラリ、コマンドラインツール、プロジェクトが依存するパッケージなどの環境を管理します。これはあなたがすでに行っており、慣れている（または少なくとも慣れている）ことです。 pip は、ローカルパッケージをアクティブな環境にインストールするという、Python パッケージング固有のジョブを 1 つ実行します。

編集可能モードでは、「-e」フラグ、「pip」により、アクティブな環境が編集中のソースファイルに接続されます。そして...なぜそれが役立つのでしょうか?

これは非常に迅速な開発ループを提供するので便利です。

エディターでコードを編集します。
ターミナル、テストスイート、または Jupyter ノートブックから実行します。
コードを再度編集します。
パッケージを再インストールせずに再度実行します。

したがって、目標は conda から pip に切り替えることではありません。目標は、conda 環境を使用し続けながら、その環境内でローカルパッケージをインポートできるようにすることです。

今度はすべてに pip を使用する必要がありますか?#

おそらくそうではないでしょうか？

conda がすでにプロジェクトでうまく機能している場合は、引き続き conda を使用して環境を管理してください。 pip は、ローカルパッケージを編集可能モードでインストールするというこの 1 つのタスクにのみ使用してください。

uv、pixi、Hatch、pip のみのワークフローなどの他のツールに興味がある場合は、環境マネージャーを参照してください。これらのツールは素晴らしい選択肢になる可能性があります。ただし、conda 環境内でローカルパッケージを開発するためだけにツールを切り替える必要はありません。

最後になりますが、conda エコシステムの人々は conda/pip の相互運用性の向上に積極的に取り組んでいます。将来的には、このワークフローはそれほど面倒ではなくなるかもしれません。現時点では、 python -m pip install -e です。 --no-deps は標準のブリッジです。

完全なコマンド#

python -m pip install -e 。 --no-deps は一口です。私はそれを知っている。あなたはそれを知っています。なぜこのようなことをするのでしょうか?

これの最も単純なバージョンは次のとおりです。

pip install -e .

ただし、conda 環境では 2 つの理由から長いバージョンをお勧めします。

python -m pip 部分は、アクティブな conda 環境から pip を使用していることを保証します。場合によっては、これにより「pip not found」というエラーが発生することがありますが、これはデバッグに煩わしい障害モードを回避したことを意味するため、実際には発生しても良いエラーです。この問題が発生した場合は、「conda install pip」を実行して再試行してください。それで、なぜですか？場合によっては、別の Python 環境の pip が PATH 上に存在することがあります。これは、コードを誤って無関係な Python 環境にインストールしてしまうことを意味します。これはデバッグが混乱する可能性があります。これは私たちのほとんど（全員？）に起こったことです。通常、デバッグと修正の準備が整っていないときに発生します。したがって、これが起こらないようにするために、先頭に「python -m」を付けることをお勧めします。ただし、コマンドの長さは長くなります。

--no-deps フラグは、プロジェクトにパッケージの依存関係がリストされている場合に、パッケージの依存関係をインストールしないように pip に指示します。おそらく pyproject.toml ファイルにそれらがリストされている場合、pip install -e . はそのファイルにリストされている依存関係をインストールしようとします。 conda 環境では、「ほとんど問題ありません」から「環境が壊れており、回復方法がわかりません」までさまざまです。

--no-deps を指定すると、pip はローカルパッケージのみをインストールします。 conda を使用して環境の依存関係を管理するのは引き続きお客様の責任です。