注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

トラブルシューティングガイド

このガイドの手順に従って、Python 環境作成の最も一般的な問題をデバッグします。

トラブルシューティングガイド

パッケージ解決中にチェックが失敗する

以下のチェックの失敗については、「チェック」タブ内のコードリポジトリでチェックログを表示することができます。これらのログを使用して、チェックが失敗した理由を特定できます。

新しい Mamba エラーメッセージ

Palantir は、環境の初期化エラーメッセージの書式を改善することで、オープンソースの Mamba コミュニティに貢献しました。2023年2月以降、Foundry サービスは、環境の失敗によって侵害される依存関係ツリーをより正確に表現するエラーの恩恵を受けることができます。

依存関係ツリー

次の例では：

packageA
   ├─ packageB  // パッケージB
   └─ packageC  // パッケージC
        └─ packageD  // パッケージD

packageB と packageC は、packageA の直接の依存関係です。packageD は packageC の直接の依存関係ですが、packageA の間接的な依存関係です。packageA は packageD に対して直接的な制約を持っていませんが、packageA の packageC に対する直接的な要求は、間接的に packageD に制約を強制します。以下に、そのような概念の実例を示します：

statsmodels
├─ numpy  # 数値計算ライブラリ
├─ scipy  # 科学計算ライブラリ
├─ matplotlib  # グラフ描画ライブラリ
│  │  ├─ libpng  # PNG形式の画像の読み書きをサポートするライブラリ
│  │  ├─ setuptools  # Pythonパッケージのインストール・管理ツール
│  │  ├─ cycler  # カラーや線のスタイルを繰り返し適用するためのツール
│  │  ├─ dateutil  # 日付・時刻の操作を支援するライブラリ
│  │  └─ kiwisolver  # 制約ベースのレイアウトソルバー

statsmodelsがlibpngに制約を課すことが最初は明らかでないかもしれませんが、それはmatplotlibに制約を持つことで間接的にそうしています。

直接的な競合

直接的な競合は、同じ環境で同じパッケージの異なるバージョンがリクエストされたときに発生します。例えば、python 3.7とpython 3.8の両方を含むシンプルな環境をリクエストすることを想像してみてください。これは環境が失敗する原因となる直接的な競合です。新しいエラーメッセージは以下の情報を提供します：

  環境仕様を解決できませんでした
  次のパッケージは互換性がありません
  ├─ python 3.7**  が要求され、インストール可能です；
  └─ python 3.8**  は、以前に報告されたインストール可能な
   バージョンと競合するため、アンインストールできません。

上記のメッセージは、python 3.7 を確かにインストールできることを正確に説明しています。ただし、そのバージョンがインストールされた場合、追加の異なるバージョンをインストールしようとすると、競合が発生します。この環境は、環境から python のバージョン制約のいずれかを削除することで解決できます。

ただし、直接的な競合は、依存関係と推移的依存関係により生じる競合に比べて非常にまれです。

直接的な依存関係の競合

NumPy のドキュメンテーションは、numpy >=1.22.0 が python >=3.8 を必要とすることを特に指摘しています。結果として、python 3.7.* と numpy 1.22.0 の両方を要求する環境を作成しようとすると、直接的な依存関係の競合が生じます。次にエラーメッセージが表示されます：

環境の仕様を解決できませんでした
次のパッケージが互換性がありません
├─ numpy 1.22.0** は以下の可能なオプションでインストール可能です
│  ├─ numpy 1.22.0 が必要とするもの
│  │  ├─ python >=3.9,<3.10.0a0 、これはインストール可能です；
│  │  └─ python_abi 3.9.* *_cp39、これはインストール可能です；
│  ├─ numpy 1.22.0 が必要とするもの
│  │  ├─ python >=3.10,<3.11.0a0 、これはインストール可能です；
│  │  └─ python_abi 3.10.* *_cp310、これはインストール可能です；
│  └─ numpy 1.22.0 が必要とするもの
│     ├─ python >=3.8,<3.9.0a0 、これはインストール可能です；
│     └─ python_abi 3.8.* *_cp38、これはインストール可能です；
└─ python 3.7** は適切なオプションがないためアンインストールできません
   ├─ python [3.7.10|3.7.11|...|3.7.9] は先に報告された任意のインストール可能なバージョンと競合します；
   ├─ python [3.7.0|3.7.1|3.7.2|3.7.3|3.7.6] が必要とするもの
   │  └─ python_abi * *_cp37m、これは先に報告された任意のインストール可能なバージョンと競合します；
   └─ python [3.7.10|3.7.12|...|3.7.9] が必要とするもの
      └─ python_abi 3.7.* *_cp37m、これは先に報告された任意のインストール可能なバージョンと競合します。

このエラーメッセージは、numpy 1.22.0がPython 3.8、3.9、または3.10と互換性があり、要求された3.7.*バージョンと競合することを示しています。この環境は、PythonまたはNumPyの制約を緩和することで解決できます。たとえば、python 3.8.*とnumpy 1.22.0、またはpython 3.7.*とnumpy 1.*の組み合わせはどちらも成功する環境になります。

環境のトラブルシューティングを行う際には、pythonとpython_abiのバージョンが連動していると仮定して構いません。環境でpython_abiを指定する代わりに、pythonバージョンを調整してpython_abiバージョンを調整できます。

トランジティブな依存関係の競合

同様に、トランジティブな依存関係が原因でパッケージの競合が発生することがあります。トランジティブな依存関係の性質上、いくつかのパッケージの要求だけで、環境解決操作に何百もの制約が追加されることがあります。statsmodelsパッケージを考えてみましょう：

statsmodels
├─ numpy
├─ scipy
├─ matplotlib
│  │  ├─ libpng          # libpng: PNG画像の読み書きのためのライブラリ
│  │  ├─ setuptools      # setuptools: パッケージインストール・管理のためのツール
│  │  ├─ cycler          # cycler: グラフスタイルの設定のためのライブラリ
│  │  ├─ dateutil        # dateutil: 日付・時刻の処理のための拡張モジュール
│  │  └─ kiwisolver      # kiwisolver: 制約ベースのレイアウトソルバー

特定の statsmodels バージョンのリクエストは、matplotlib に依存するパッケージのため、許可される setuptools のバージョンに制約を課します。その結果、環境が互換性のない statsmodels と setuptools のバージョンをリクエストする場合、statsmodels 自体が setuptools に制約を課すため、推移的な依存関係の競合が発生する可能性があります。

例として、以下の環境で huggingface-adapter 0.1.1* と transforms 1.645.0 をリクエストする場合を考えてみましょう: 次のパッケージは互換性がありません ├─ huggingface-adapter 0.1.1** * はインストール可能で、次のものが必要です │ └─ palantir_models >=0.551.0 *, これは以下が必要です │ └─ pyspark-src >=3.2.1,<3.3.0a0 *, これはインストールできます; └─ transforms 1.645.0 * はアンインストールできません。これは次のものが必要です └─ pyspark-src 3.2.1_palantir.36 *, これは前に報告されたインストール可能なバージョンと競合しますそれらの2つのパッケージがなぜ互換性がないのかは、最初には明らかでないかもしれません。エラーメッセージは、問題が huggingface-adapter の推移的な依存関係が transforms の直接的な依存関係 pyspark-src と衝突していることから生じていることを特定するのに役立ちます。この環境は、Mambaが互換性のある pyspark-src 要件につながるバージョンのペアを特定できるように、transforms または huggingface-adapter の制約を緩和することで解決できます。

新しいエラーメッセージの解釈

以下に、新しい mamba エラーメッセージが提供する可能性のある全ての表現、それらの解釈、およびそれらを修正するための一部のガイダンスのリストを示します：

以下のパッケージは互換性がありません または 以下のパッケージをインストールできませんでした：これらのどちらかは通常、詳細なエラーメッセージの最初の文となります。これは、全体的な問題が互換性のないバージョンによって引き起こされるパッケージの競合であるか、または必要なパッケージのインストール自体の問題であるかを示します。
- 対策：その文の直下の必要な情報を読む。
インストールできます：この文は通常、依存関係のツリーの上部に表示され、パッケージ自体は追加の制約なしでインストールできることを意味します。しかし、この特定のバージョンがインストールされたと仮定すると、他のパッケージ依存関係がそのインストールされたバージョンと競合する可能性があります。たとえば、python 3.7** が要求され、インストールできます は、Python 3.7 が環境にインストールできることを意味します。この文の直下に記載されている他の全ての競合は、Python 3.7 が環境にインストールされていると仮定しています。
実行可能なオプションがありません：インストール可能なバージョンのどれも、要求された環境の他の仕様によって課された制約に収まることができません。たとえば、メッセージ python 3.7** は実行可能なオプションがないため、アンインストール可能です は、python 3.7.* のバージョンが他のパッケージや制約が特定の Python バージョンを要求していなければインストールできることを示しています。
- 対策：このパッケージの実行可能なオプションの範囲外に許容バージョン範囲を引き起こすパッケージの制約を緩和する。
存在しない、あるいは(タイプミスまたは)チャネルが欠落している可能性があります：インストールするパッケージが見つかりませんでした。これは、パッケージが正しく指定されていないか、設定されたチャネル（設定 > ライブラリ in Code Repositories または Code Workbook の環境設定）のいずれにもパッケージが含まれていない可能性が高いです。たとえば、python 3.423.*（存在しないバージョン）と pthon 3.8.*（明らかなタイプミス）を含む環境を要求すると、次のエラーメッセージが表示されます：

 環境仕様を解決できませんでした
 以下のパッケージは互換性がありません
  ├─ pthon 3.8** は存在しません（タイプミスかチャンネルが欠けているかもしれません）；
  └─ python 3.423** は存在しません（タイプミスかチャンネルが欠けているかもしれません）。

修正方法: パッケージに誤字がないことを確認するか、要求されたすべてのパッケージが環境で使用可能であることを確認します。Foundry でパッケージの存在を検索する方法については、Discover Python libraries を参照してください。
is installable and it requires: パッケージとそのバージョンは環境にインストールできますが、環境に追加の制約が導入されます。
is uninstallable because it requires: パッケージとそのバージョンは、依存関係の一部が環境の競合を引き起こすためインストールできません。
- 修正方法: 依存関係のうち、メッセージの下にリストされている要件を調査し、制約を緩和するか、この特定のパッケージの制約を緩和します。
is installable with the potential options: パッケージには、環境にインストール可能な非競合のバージョンがいくつか用意されています。これらのバージョンのいずれかを選択すると、さらなる制約が発生する可能性があります。
conflicts with any installable versions previously reported: 通常、上記の行で言及されたバージョンと対比されることが多いですが、このパッケージの「インストール可能」なバージョンが別の場所で決定されたため、このバージョンは満足できないことを示しています。
- 修正方法: 同じ環境で、同じパッケージの異なるバージョンが直接的または間接的に要求されないようにします。
is missing on the system: これは、特に欠けている virtual package を指します。一部のパッケージは特定の OS 環境でのみ実行できます。例えば、cudatoolkit パッケージは、__cuda というシステムレベルの機能の特定のバージョンが、仮想パッケージとして環境に存在することを要求しています。これにより、パッケージが既存のアーキテクチャで実行できることが保証されます。
which cannot be installed (as previously explained): パッケージは、以前に説明された競合のためにインストールできないか、または別のパッケージが以前に説明された同じ制約を持っているためインストールできません。

レガシー Mamba エラーメッセージ

以下に、新しい Mamba エラーメッセージが導入される前の、レガシーエラーメッセージの一般的なエラーメッセージのリストを示します。

パッケージが見つかりません

この場合、設定されたチャンネルのいずれも、パッケージ A の依存関係を提供していません。

Copied!1
問題: 要求された A.a.a.a を提供するものがありません

これは、指定したバージョンのパッケージが存在しない場合に発生します。このような場合は、meta.yml内のパッケージからバージョン管理を緩和するか、削除してみてください。例えば、matplotlib 1.1.1をmatplotlibに変更します。

このエラーが表示された場合は、以下のアプリケーション固有の手順に従ってパッケージを追加できます。

foundry-add-dependencies

依存関係が見つからない

この場合、パッケージAには、どのチャンネルからも提供されていない必須の依存関係Bが含まれています。

Copied!1
問題: A-a.a.aに必要なB-b.b.bを提供するものがありません:

Bはユーザーが明示的に要求したパッケージ（meta.yml/foundry-ml/vectorプロファイル内）であるか、またはそれが推移的な依存関係である可能性があります。

これは、Bがユーザーのエンロールメントでインストール可能ではない場合に発生する可能性があります。たとえば、Bがリコールされたためにインストールできない場合などです。

そのような場合は、すべての依存関係が利用可能なAのバージョンがあるかどうかを確認するために、Aのピン留めされたバージョンを削除するか、または必要なパッケージをFoundryにインポートするためにPalantirの担当者に連絡してみてください。

重複したパッケージエラー

Copied!1
2
// X.a.b.c と X.d.e.f の両方をインストールすることはできません
cannot install both X.a.b.c and X.d.e.f

このエラーは、同じパッケージ X をインストールしようとして、両方に対して異なるバージョンピンニングを持っている場合に発生します。たとえば、meta.yml で python 3.9.* と python 3.10.* の両方をピン留めしようとした場合にこのエラーが発生する可能性があります。この問題は、重複するパッケージピンニングのうち1つを削除することで解決できます。

パーミッションエラーのデバッグ

Copied!1
2
CondaService:ReadRepositoryPermissionDenied
// CondaService：リポジトリの読み取り権限が拒否されました

このエラーが表示された場合、必要な全てのアセットとパッケージがユーザーのエンロールメントに利用可能でない可能性があります。全てがエンロールメントにインストールされたら、再デプロイを確認してください。

パッケージの競合

このケースでは、パッケージ A がパッケージ B のバージョンに要求を持っていますが、この B のバージョンは他のパッケージと競合しています：

Copied!1
問題: パッケージ A-a.a.a は B >=2.2.5,<2.3.0a0 を必要としますが、プロバイダのいずれもインストールできません

Bパッケージは、meta.yamlファイルに明示的に要件としてリストされていないAの推移的依存関係を指す可能性があります。推移的依存関係の詳細については、環境作成の導入をご覧ください。

パッケージコンフリクトのデバッグ

失敗する解の最小例を作成します。環境が正常に解決するまでパッケージを削除し、ブロッカーとなるパッケージがどれであるかを決定するまでパッケージを追加します。
制約を緩和する（パッケージピンを削除する）試みます。
- このプロセスを速めるために、異なるウィンドウで複数のリポジトリを開いたり、同じリポジトリの異なるブランチを開いたりすることができます（Code Repositories内）またはプロフィールを使用します（Code Workbook内）。
Code Workbookでは、pandas=0、matplotlib=2、numpy<1.20にデフォルト設定されるのを防ぐために、pandas、matplotlib、numpyの最小バージョン管理を追加できます。これらのデフォルトよりも高いバージョンが必要な場合は、Environment > Customize Spark environment > Customize Profileに移動し、各パッケージのドロップダウンメニューからバージョンを選択し、バージョン要件を満たします。
- バイナリーサーチを使用して問題を発見することをお勧めします。1つのリポジトリのすべての制約を削除し、別のリポジトリの制約の半分を削除し、その後、別のリポジトリの残りの半分を削除するなどします。
Mambaが生成するログに余分な詳細を追加することもできます。これは、ツリー下部の推移的依存関係を追跡するのに役立ちます（注意: これによりチェックの遅延が発生します）。詳細を追加するには、CIログの中でチェックが失敗するタスクを見つけ、Execution failed for task ':transforms-python:<task-name>'.の行を探します。例えば、失敗したタスクがcondaPackRunであった場合、以下のブロックを内部のtransforms-python/build.gradleファイルの最下部に追加します：

Copied!1
2
3
4
tasks.condaPackRun {
    // "-vvv"を追加引数として設定
    additionalArguments "-vvv"
}

バージョンの固定解除が解決に失敗する理由は何ですか？

完全に緩和された制約を持っていても、要件のリストに必要なパッケージやパッケージのバージョンが以下のような場合があります。

利用できない。利用可能なパッケージとバージョンは、パッケージタブを使用して確認できます。必要に応じて、これらのパッケージが追加されるように、あなたの Palantir の担当者に連絡してください。
互換性がない。これらのパッケージ定義は、すべての可能な公開バージョンにアクセスしていたとしても、互換性がないことがあります。例えば、あなたが依存している Conda のパッケージの 1 つが、新しいバージョンにアップグレードされ（アップグレード PR を参照）、そのバージョンが壊れている可能性があります。
meta.yml内の Python のバージョンと互換性がありません。

このシナリオを確認するためには、成功したチェックに関連する Conda ロックファイルを、失敗したチェックのものと比較します。Conda ロックファイルにアクセスするには、設定の歯車アイコンで「隠しファイルとフォルダを表示」を選択し、「transforms-python/conda-versions.run.linux-64.lock」に移動します。成功した実行と失敗した実行の間で変更されたライブラリのバージョンを、「meta.yaml」ファイル内の異なるバージョンに固定します。

パッケージの要求に変更がない場合の失敗

これが発生する主な理由は 2 つあります。

あなたの変換が外部のパッケージに依存している可能性があるため（公開されている Conda チャンネルを参照）、残念ながら、上流で何かが壊れた場合には失敗に対して脆弱になることがあります。
アップグレード PR をマージすると、チェックの実行時に環境の再解決がトリガーされ、特に環境が過剰に制約されている場合、パッケージ解決が失敗することがあります。これは、アップグレード PR が新しい依存関係をもたらし、環境の再計算が必要になるためです。アップグレード PR が原因であることを確認するには、アップグレード PR が適用されたコミットをリバートすると、チェックが通るかどうかをテストします。その後、上記のセクションを参照して、アップグレード PR を再適用します。

`meta.yml`への変更がない場合の遅さのデバッグ

Code Repositoriesで：

ブランチをアップグレードします（手動でのブランチアップグレードの詳細についてはこちらを参照してください）。
まだ遅さが続いていて、@transform_dfタグの外でコード変更を行った場合、このコードがチェックを遅くしている可能性があります。該当する場合は、このコードのパフォーマンスを評価してください。

`meta.yml`への変更があった場合のジョブのタイムアウト

長時間実行されるジョブでメモリ不足（OOM）エラーが発生している場合は、互換性のないパッケージのバージョンが、解決できない環境につながっている可能性があります。これを解決するためには、まずブランチをアップグレードし、次に上記のデバッグ手順を実行してください。

Conda エラーによるビルドの失敗

Copied!1
2
// CondaEnvironmentSetupError（Conda環境設定エラー）
CondaEnvironmentSetupError

ビルドエラーが発生した場合、解決手順は以下の通りです：

エラーのあるドライバーログをチェックします。
コード/meta.ymlを変更した場合（これを観察するためには、ジョブ比較ツールを使用します）、それらを元に戻してビルドが修正されるかどうかを確認します。meta.ymlの変更を元に戻すことで問題が修正された場合、おそらくパッケージの競合が原因であり、上記で説明されているようにデバッグできます。meta.ymlを変更していなかった場合、ビルドのPythonモジュールバージョンを確認します（次のステップで言及）。それがビルドを解決しない場合、ブランチのアップグレードまたは基本的なアップグレード（アップグレードPRを参照）による解決策が原因で環境が解決不能になっている可能性があります。その場合、上記で言及したデバッグ手順を確認する必要があります。
何も変更していない場合、成功したビルドを行ったPythonモジュールバージョンと失敗したビルドとでは異なるバージョンがありますか？ "Infra details"、"Environment"、次に "SparkModuleVersion" をチェックします。このバージョンに戻るについては、Palantirの担当者に連絡してください。

spark-module-version

複数ダウンロードの失敗

Copied!1
// RuntimeError: マルチダウンロードが失敗しました

このエラーは、パッケージがダウンロードされる artifacts channel へのアクセスがないか、作成物がエンロールメントに利用できないことを意味します。実際の失敗は driver logs で確認できます。

リポジトリをテンプレート化しようとしている場合は、Conda channels のリストに移動し、リストされたチャンネルに警告がないか確認してください。リストされたチャンネルに警告がある場合は、以下の手順を実行してください。

壊れたチャンネルを削除する（該当する場合は、Palantir の担当者に権限を依頼してください）。
チェックを再実行する。
ビルドを再実行する。

Entry Point Error でのビルド失敗

Copied!1
2
3
transforms._errors.EntryPointError: "キー{name}が見つかりませんでした、リポジトリのmeta.yamlおよびsetup.pyファイルを確認してください"
// transforms._errors.EntryPointError: "キー{name}が見つかりませんでした、リポジトリのmeta.yamlおよびsetup.pyファイルを確認してください"
// ここでのエラーメッセージは、特定のキーが見つからないことを意味します。使用者は自分のリポジトリ内の特定のファイル（ここではmeta.yamlとsetup.py）を確認するよう求められています。

このエラーは、ビルドをトリガーするために必要なルートファイルから何らかのものが欠けていることを意味します。データセットプレビューを使用できるかもしれませんが、ビルドは失敗します。

この問題をデバッグするには、meta.yaml や setup.py から必要な情報が欠けていないかどうかを確認してください。参考までに、新しい Python コードリポジトリを作成し、新しいリポジトリ内の meta.yaml と setup.py ファイルを調べることができます。

meta.yaml および/または setup.py に不足している情報を追加した後、変更をコミットし、チェックが成功するのを待ってから、ビルドを再トリガーしてください。

Conda パッケージと JAR の両方が必要なパッケージ

一部のパッケージは、Conda パッケージと JAR の両方が必要であることがあります。典型的な例は、graphframes パッケージです（Conda パッケージには Python API が含まれており、JAR には実際の実装が含まれています）。Conda パッケージを追加するだけで、必要な JAR を追加しない場合、次のエラーに遭遇する可能性があります。

o257.loadClass.: java.lang.ClassNotFoundException:<クラス> // クラスが見つからない例外

あるいは、次のエラーに遭遇するかもしれません：

Java クラスパス参照エラー - 使用している Python の依存関係が、クラスパスにない Java jar を参照しようとしています。最近追加した Python の依存関係を確認し、build.gradle ファイルに必要な Java パッケージ（JAR）の依存関係を追加してください。

そのようなパッケージを追加するには、次の2ステップのプロセスが必要です：

パッケージタブを通じて通常通りリポジトリに Conda パッケージを追加します。
設定の歯車アイコンで「隠しファイルとフォルダーを表示」を選択し、内側の「transforms-python/build.gradle」ファイルを選択します。ファイルの最後に、以下のブロックを追加します：

Copied!1
2
3
4
dependencies {
    // 以下のコードは、グループ名、名前、バージョンを指定してcondaJars依存関係を追加します
    condaJars '<group_name>:<name>:<version>'
}

これらのパッケージがユニットテストにも必要な場合は、テスト時に利用可能にする必要があります。そのために、次のブロックを gradle ファイルに追加してください（テストプラグインは、sparkJars 依存関係の前に宣言する必要があります）:

Copied!1
2
3
4
5
6
7
8
9
// テストプラグインを適用する
apply plugin: 'com.palantir.transforms.lang.pytest-defaults'

dependencies { 
    // condaJars 依存関係を追加する
    condaJars '<group_name>:<name>:<version>' 
    // sparkJars 依存関係を追加する
    sparkJars '<group_name>:<name>:<version>' 
}

外部ライブラリの別の例として、CondaパッケージとJARの両方が必要なのが、Spark-NLPパッケージです。Spark-NLPのJAR依存関係は、build.gradleファイルに追加する必要があることに注意してください。

まず、Spark-NLPを外部ライブラリとして追加します。

spark-nlp-conda-add-button

上記で追加したライブラリバージョンと互換性のあるJARをサブプロジェクト内のbuild.gradleファイルに追加します。通常は transforms-python/build.gradle です。例えば、上記のSpark-NLPのライブラリバージョンは5.0.2なので、以下の手順では、バージョン期待値を満たすJARを追加します。形式 <group_name>:<name>:<version> を使用して、以下のコードでJARをbuild.gradleスクリプトに追加できます：

dependencies {
     // 依存関係を追加します
     condaJars 'com.johnsnowlabs.nlp:spark-nlp_2.12:5.0.2'   
}

ターゲットバージョンが名前に指定されていて確認できない場合は、Maven（外部リンク）を訪れて、該当するライブラリを検索し、Foundryで確認したライブラリバージョンと互換性のあるターゲットバージョンを見つけてください。

依存性の競合を避けるためのベストプラクティス

上記のエラーから、最も頻繁に発生するエラーの原因は依存性の競合です。依存性の競合を減らすために、以下のベストプラクティスに従ってください。

依存性の競合を避けるためのベストプラクティス：Python

Pythonについてはmajor.minorのバージョン管理を維持します。

Code Repositoriesでは、3.8.*、3.9.*、3.10.*の中から選択できます。選択したバージョンはビルドセクションと実行セクションの両方でピン留めされるべきです。Python 3.6.*、3.7.*は現在非推奨で、まだ使用することはできますが、2024年の第1四半期以降は許可されません。

build-and-run-python-versions-same

ビルドセクションと実行セクションのPython依存性が同一であることを確認してください。Python依存性の間に不一致があると、望ましくない結果や失敗につながる可能性があります。

python >=3.9やpython >3.9,<=3.10.11のような範囲は、Pythonバージョンに対してサポートされていません。サポートされていないPythonバージョンが使用されると、Python 3.6.*にデフォルト設定します。Python 3.6.*は非推奨なので、meta.yamlにサポート対象のPythonバージョンに対する有効なピンがあることを確認してください。

Code Workbookでは、自動から必要なバージョン管理に切り替えることでバージョン管理を切り替えることができます。

code-workbooks-python-versioning

Pythonバージョンのサポート

Python 3.8から始まり、FoundryはPython End Of Lifeで定義されたタイムラインを追っていくことになります。つまり、Pythonのバージョンがライフエンドと宣言されていると、プラットフォームでのサポートがなくなります。詳細はPythonバージョンのページをご覧ください。

依存性の競合を避けるためのベストプラクティス：Python以外のパッケージ

明示的にバージョンをピン留めするのは避けてください。これは依存性の競合を引き起こす可能性があります。major.minorバージョンでさえ競合を引き起こすことがあります。

Code Workbookでは、pandas、matplotlib、numpyの最小バージョン管理を追加することができます。Code Workbookは自動設定でpandas=0、matplotlib=2、numpy<1.20にデフォルト設定します。

その他の問題

上記のガイドラインが問題の解決に十分でない場合、またはこのガイドの範囲外の問題に遭遇した場合は、Palantirの担当者に連絡し、試みたデバッグステップの詳細を含めてください。