<p>pip 19.0は、CWDからインストール予定のパッケージをインポートするパッケージのインストールに失敗します</p>

これは、pyinstallerがインストールのために自分自身をインポートする方法のいずれかに問題があるようです。

PyInstallerの人々に問題を提出するのは良い考えかもしれません。

現在18.1を使用していますが、19.0にアップグレードすると、この問題も発生します。 PyInstallerリポジトリに関連する問題があります。これは、pip ''がsys.pathにないためです。

https://github.com/pyinstaller/pyinstaller/issues/2730

これはかなり一般的なワークフローだと思います。 __version__ = "1.2.3"をfoo/__init__.pyから、 import fooをsetup.py入れるので、2か所でバージョンを指定する必要はありません。 また、ライブラリのすべてのユーザーは、 PEP396に従ってバージョンを検査できます。

# foo/__init__.py
__version__ = "1.2.3"

# setup.py
from setuptools import setup

import foo

setup(..., version=foo.__version__)

また、これはpyproject.tomlファイル（およびsetup.py ）がある場合にのみ発生します。 それを削除すると、インストールは正常に機能します。 そのため、そこでの動作にはいくつかの違いがあるようです。 たぶん、伝統的な方法はsys.path / PYTHONPATHますか？

ああ、私は何が起こっているのか理解できたと思います。 pyproject.tomlファイルを使用することで、基本的にPIPにPEP517 / 518を使用するように指示していることになります。

# pyproject.toml
[build-system]
requires = ["setuptools", "wheel"]

上記は、PyInstallerをビルドするためにsetuptoolsとwheelが必要であることをpipに伝えています。 しかし、PyInstallerの場合、 setup.pyもこれが含まれています。

# setup.py
from PyInstaller import __version__

PEP 517の観点からは、 setuptoolsとwheel除いて、それ自体を構築する必要があることを意味します。 もちろん、これは少し奇妙です。

# pyproject.toml
[build-system]
requires = ["setuptools", "wheel", "PyInstaller"]

@cjerdonekがhttps://github.com/pypa/pip/issues/6175#issuecomment-456769285で言及しているように、誰かが--no-use-pep517これが修正されるかどうかを確認できますか？

この問題の原因は、ビルドの分離またはPEP 517コードがパッケージディレクトリのルートがsys.pathにあることを確認していないことだと思います。これは、pandasのsetup.pyの横にversioneer.pyがあるためです。 ある時点でこれが起こったことを覚えていますが、その議論が何であったかを頭の中で覚えていません。 これは、pipではなくsetuptoolsビルドバックエンドの問題と見なされるか、pipの分離メカニズムの障害である可能性があります。

[...]誰かが--no-use-pep517がこれを修正するかどうかを確認できますか？

PyInstallerは--no-use-pep517正常にインストールされます。

さて、それは確かに新しいPEP 517コードの問題であり、問​​題はプロジェクトルートを含むディレクトリがsys.path追加されていないことだけだと確信しています。 たぶん、 @ pfmooreは、それがpipの責任なのかsetuptoolsなのかをよりよく

これの別の例に役立つ場合（ apache-airflow経由はpip install pendulum==1.4.4失敗しますが、 pip install --no-use-pep517 pendulum==1.4.4機能します。

取得するスタックトレースは似ています。

Collecting pendulum==1.4.4
  Using cached https://files.pythonhosted.org/packages/85/a5/9fc15751f9725923b170ad37d6c61031fc9e941bafd5288ca6ee51233284/pendulum-1.4.4.tar.gz
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  Complete output from command /Users/ash/.virtualenvs/clean-airflow/bin/python3.7 /Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/tmprosed3kj:
  Traceback (most recent call last):
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 207, in <module>
      main()
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 197, in main
      json_out['return_val'] = hook(**hook_input['kwargs'])
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 54, in get_requires_for_build_wheel
      return hook(config_settings)
    File "/private/var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/pip-build-env-g__m0jh6/overlay/lib/python3.7/site-packages/setuptools/build_meta.py", line 115, in get_requires_for_build_wheel
      return _get_build_requires(config_settings, requirements=['wheel'])
    File "/private/var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/pip-build-env-g__m0jh6/overlay/lib/python3.7/site-packages/setuptools/build_meta.py", line 101, in _get_build_requires
      _run_setup()
    File "/private/var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/pip-build-env-g__m0jh6/overlay/lib/python3.7/site-packages/setuptools/build_meta.py", line 85, in _run_setup
      exec(compile(code, __file__, 'exec'), locals())
    File "setup.py", line 47, in <module>
      from build import *
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/build.py", line 7, in <module>
      from pip._vendor import pytoml
  ModuleNotFoundError: No module named 'pip'

また、以下のインストールもpip v 19.0では機能しませんが、-no-use-pep5517を使用すると機能します。
pendulum == 1.5.0（AttributeError：モジュール 'enum'には属性 'IntFlag'がありません）
pendulum == 1.5.1（AttributeError：モジュール 'enum'には属性 'IntFlag'がありません）
pendulum == 2.0.0（AttributeError：モジュール 'enum'には属性 'IntFlag'がありません）
pendulum == 2.0.1（AttributeError：モジュール 'enum'には属性 'IntFlag'がありません）
pendulum == 2.0.2（AttributeError：モジュール 'enum'には属性 'IntFlag'がありません）

一方、2.0.3と2.0.4は正常にインストールされます。

cartopy（少なくとも最新リリース）も19.0以降のインストールに失敗し、setup.pyの隣にあるversioneer.pyのインポートに失敗します。

これは、私が扱っているいくつかのプロジェクトの問題でもあります。 pyproject.tomlを使用してPythonの黒のパラメーターを定義し、setup.pyで同様のfrom project.version import __version__します。

少なくとも、pyproject.tomlでプロジェクトの分離を定義できなくても十分だと思います。 プロジェクトをインストールしたい人に--no-buid-isolationまたは--no-use-pep517を使用させるのは私には不合理に思えます

失敗はget_requires_for_build_wheelにあるようで、setuptoolsバックエンドはsetup.pyを実行して、ビルド要件を決定するために何らかのイントロスペクションを実行します（特定のコードはここにあり

PEP 517は、ビルドディレクトリをsys.pathに追加する環境でフロントエンドがフックを実行する必要があるとは述べていません。これを行うと、分離が破られる可能性があるという潜在的な懸念があります（ビルドディレクトリにたとえば、必須であるが指定されていないパッケージもあります）。 したがって、私の好みは、ビルドディレクトリをsys.path追加しないことです。 ただし、このリグレッションをすばやく修正できる場合は、そうするのが便利な場合があります。 しかし、プロジェクトはこれに依存すべきではないと思います。

概要：

1. これは、バックエンドの問題として確認するためにsetuptoolsに報告する必要があります。 理想的な解決策として、setuptoolsバックエンドで修正することを検討します（おそらくビルドディレクトリをsys.path追加するだけです）。
2. setuptoolsがそれを行わない場合、pipはビルドディレクトリをsys.pathに追加できますが、PEP517がそれをフロントエンドの責任と見なしているとは思いません。
3. ビルドディレクトリを要求することにあるフックに見えるようにsys.path少なくともPEPの明確化が必要となります。

PEP 517が開発されていたとき、このシナリオは考慮されていなかったと思います。 おそらくそれはsetuptools固有（というより、ビルドの一部として任意のPythonコードを実行するバックエンドに固有）だからです。

現在のディレクトリからsetup.pyに何かをインポートすることはかなり一般的だと思います。一般的には、 setup.pyが$PWDかのように扱います。

この責任をsetuptoolsに押し付けるのは合理的だと思います。おそらく、それが本当に必要な唯一のプロジェクトだからです。

うん、これについてもう少し考えてみると、それはsetuptoolsのバックエンドの責任だと確信しています。 PEP 517より前では、pipはスクリプトとしてsetup.pyしたため、標準のPythonルールはスクリプトディレクトリをsys.pathます。 PEP 517では、 setup.py呼び出しはバックエンドフックへの呼び出しに置き換えられるため、これらのフックはセマンティクスを保持する必要があります。 setuptoolsはフックからsetup.pyをインプロセスで実行するため、 sys.path自体を管理する必要があります。 うまくいけば、それは彼らにとって大きな修正ではありません。 @jeanlaroche （またはこの問題にぶつかっている他の誰か）は、このスレッドを参照して、setuptoolsトラッカーで問題を提起できますか？

[...]誰かが--no-use-pep517がこれを修正するかどうかを確認できますか？

--no-use-pep517でpip install pandasが成功することを確認できます。

--no-use-pep517を使用すると、壊れたすべてのパッケージで機能することも確認できます

私にとっても成功

pip install pyinstaller --no-use-pep517
Collecting pyinstaller
  Using cached https://files.pythonhosted.org/packages/03/32/0e0de593f129bf1d1e77eed562496d154ef4460fd5cecfd78612ef39a0cc/PyInstaller-3.4.tar.gz
Requirement already satisfied: setuptools in c:\python37\lib\site-packages (from pyinstaller) (39.0.1)
Collecting pefile>=2017.8.1 (from pyinstaller)
  Downloading https://files.pythonhosted.org/packages/ed/cc/157f20038a80b6a9988abc06c11a4959be8305a0d33b6d21a134127092d4/pefile-2018.8.8.tar.gz (62kB)
    100% |████████████████████████████████| 71kB 1.0MB/s
Collecting macholib>=1.8 (from pyinstaller)
  Downloading https://files.pythonhosted.org/packages/41/f1/6d23e1c79d68e41eb592338d90a33af813f98f2b04458aaf0b86908da2d8/macholib-1.11-py2.py3-none-any.whl
Collecting altgraph (from pyinstaller)
  Downloading https://files.pythonhosted.org/packages/0a/cc/646187eac4b797069e2e6b736f14cdef85dbe405c9bfc7803ef36e4f62ef/altgraph-0.16.1-py2.py3-none-any.whl
Collecting pywin32-ctypes (from pyinstaller)
  Using cached https://files.pythonhosted.org/packages/9e/4b/3ab2720f1fa4b4bc924ef1932b842edf10007e4547ea8157b0b9fc78599a/pywin32_ctypes-0.2.0-py2.py3-none-any.whl
Collecting future (from pefile>=2017.8.1->pyinstaller)
  Downloading https://files.pythonhosted.org/packages/90/52/e20466b85000a181e1e144fd8305caf2cf475e2f9674e797b222f8105f5f/future-0.17.1.tar.gz (829kB)
    100% |████████████████████████████████| 829kB 1.6MB/s
Installing collected packages: future, pefile, altgraph, macholib, pywin32-ctypes, pyinstaller
  Running setup.py install for future ... done
  Running setup.py install for pefile ... done
  Running setup.py install for pyinstaller ... done
Successfully installed altgraph-0.16.1 future-0.17.1 macholib-1.11 pefile-2018.8.8 pyinstaller-3.4 pywin32-ctypes-0.2.0

これはpip / setuptoolsのバグではないと思います。PEP517のBuildEnvironmentセクションを読んだところ、 pyproject.toml宣言された依存関係が利用可能である以外は、環境について何も想定すべきではないようです。

また、インストールされているパッケージをsetup.pyからインポートすることは悪い習慣ではありませんか？ たとえば、PyPAのこのパッケージガイドで説明されているように、パッケージバージョンを1か所で維持するためのはるかに優れた方法があります。

pypa / setuptools＃1642での議論で、 @ uranusjrと私は両方とも、これが、実行時に.がsys.pathにあるという事実に頼るのをやめる機会になることを望んでいました。 Pythonスクリプトを作成し、人々をより明確なセマンティクスに移行し始めます。

ここでの主な問題は、 pyproject.tomlが存在するだけで、PEP518とPEP517の両方にユーザーがオプトインするため、ビルドバックエンドを指定していなくても、突然新しいセマンティクスを取得することです。

pipの部分に関するこの決定は、現時点では元に戻せませんか？ pyproject.tomlのプレゼンスでPEP 518をオプトインできるかもしれませんが、実際にビルドバックエンドを指定しない限り、PEP 517はトリガーされませんか？

正直なところ、それはいたるところで厳しい状況ですが、 setuptools場合よりも、 pipがこれについて警告する方が簡単だと思います。 今のところPEP517をオプトインし、 pyproject.tomlの存在が20.0または21.0の後にPEP 517をトリガーし始めると言う場合、移行ガイドを作成し、 pip警告の発行を開始できます。 build-backendから欠落pyproject.toml 、バージョン21.0の後、ビルドアイソレーションが使用するようにデフォルト設定されますので注意してくださいsetuptools.build_metaで移行ガイドを参照してください..."

また、インストールされているパッケージをsetup.pyからインポートすることは悪い習慣ではありませんか？ たとえば、PyPAのこのパッケージガイドで説明されているように、パッケージバージョンを1か所で維持するためのはるかに優れた方法があります。

公平を期すために、このガイドでは、インストールされているパッケージをsetup.pyからインポートすることを戦略6として定義しているため、これは確かにある程度一般的です。 この時点で、そのような戦略から離れる場合は、そのページを更新して、もう含まないようにする必要があります。

pyproject.tomlの存在でPEP 517をトリガーするという決定は、意図的な選択でした（議論は、おそらくPEP 517の実装の問題またはPRに関するものでしたが、今はそれを見つける時間がありません）。 明らかに、ここで見たものに照らして変更することはできますが、私たちが決定した理由を十分に考慮せずに変更するべきではありません。

Pip自体は、 setup.pyがプロジェクトディレクトリがsys.pathにあると想定するのが正しいかどうかを判断しません（そうすべきではありません）。そのため、単にpipを変更するのは少し気が進まないのです。 setuptoolsは、バックエンドが使用されるときに別のデフォルトをプッシュしたいためです。 setup.pyでビルドされているプロジェクトのインポートには多くの問題があることに同意しますが、これまで警告をトリガーしたものではないため、バックエンドはそのセマンティクスを維持する必要があると思いました。 別の言い方をすれば、pipがあなたの提案どおりに警告したとしても、なぜユーザーは「ビルドの分離はデフォルトでsetuptools.build_metaを使用する」と読み、「 setup.pyからプロジェクトをインポートできない」ことを意味します。

個人的には、pyproject.tomlファイルの存在に依存するという現在のアプローチに同意します。 IMOの問題は、パッケージング以外の目的でpyproject.tomlを使用している人々に起因しています。 したがって、正しい方法は、パッケージ化されていないツールをプッシュして別の構成方法を提供することです。これにより、人々はpyproject.tomlを使用するかどうかを選択できます。

Pip自体は（すべきではありませんが、IMOは）setup.pyがプロジェクトディレクトリがsys.pathにあると想定するのが正しいかどうかを確認しません。そのため、setuptoolsがプッシュしたいという理由だけでpipを変更するのは少し気が進まないのです。バックエンドが使用されるときの異なるデフォルト。

確かに、 pipは、 setuptools.build_metaフックを呼び出すことは、 setup.pyを呼び出すことと完全に同等であり、完全に同等であると想定しているだけです。 そうでない場合はすでに見てきましたが、私たち（ setuptools ）がsetuptools.build_metaの契約を「これはpython setup.pyを呼び出すのと同じです」にするかどうかは、まだ確立されていないと思います。 setup.py直接呼び出す、よりロックダウンされた分離バージョンです "にしたい場合。

もちろん、 setuptoolsは「これは関数のコントラクトではないので、修正しません」と言うことができ、 pipは「デフォルトでPEP517に設定することにしました」と言うことができます。バグは他のプロジェクトにあると言えますが、調整することをお勧めします。

言い換えると、pipがあなたの提案どおりに警告したとしても、なぜユーザーは「ビルドの分離はデフォルトでsetuptools.build_metaを使用する」と読み、「setup.pyからプロジェクトをインポートできない」ことを意味するのでしょうか。 2つの事実は私には無関係のようです...

それらは関連している場合と関連していない場合がありますが、セマンティクスに他の変更がある場合もあります。 そのような警告のポイントは、「ビルドを壊す可能性のあるものにすぐにオプトインするので、このビルドをどのように実行するかを明示してください」ということです。 プロジェクトは、ビルドバックエンドを事前にpyproject.toml追加し、発生する可能性のある破損を事前に修正できます。

setuptools.build_meta_legacyようなsetuptools 「ダミー」のPEP 517バックエンドを作成して、ルートディレクトリにchdirだけ入れ、 setuptools.build_metaを呼び出すこともできます。人々は、古い動作が壊れ始める前に必要な場合にのみ、古い動作にオプトインできます。

個人的には、pyproject.tomlファイルの存在に依存するという現在のアプローチに同意します。 IMOの問題は、パッケージング以外の目的でpyproject.tomlを使用している人々に起因しています。

私たちはPEP 517とPEP 518分離する必要があると思うPEP 518のに対し、「デフォルト値」は、PEPのためであるか明示的にリストをPEP 517は、デフォルトのバックエンドが何であるかについては何も指定しません。

「 pyproject.tomlの存在により、ビルドの分離が選択される」という全体にひどく嫌悪感を覚えることはありませんが、実際に見てみると、分離されたビルドの依存関係を指定することも選択するという考えは好きではありませんsetuptools.build_meta私を入れます。

おそらく解決策は、違いを分割し、バックエンドを文書化されていないsetuptools.build_meta_legacyデフォルト設定することです（これはsetup.pyのセマンティクスを維持しようとします）。 そうすれば、少なくとも、ユーザーが新しいセマンティクスを使用することを肯定的に選択したのか、それとも単にそれについて考えなかったのかを判断する方法があります。

警告メッセージ付きのbuild_meta_legacyは、私には合理的な解決策のように思えます。 警告を非常に目立たせて（たとえば、インストール中に、これをバグとしてメンテナに提出するようにユーザーに勧める）、移行の実行方法を明確に指示することをお勧めします。

また、ピップの意図（これは「企業」ピップです;-）-つまり、ピップ開発者はこれについて少し話し合い、合理的なアイデアのように聞こえるという一般的なコンセンサスに達しましたが、まだ確固たる計画ではありません。そして、それが起こるために実際にコードを書いている誰かに依存しています）は、比較的迅速にすべてのプロジェクトをPEP 517に渡し、レガシーコードパスをsetup.py完全にドロップすることに切り替えます。 setuptoolsバックエンドをpip21.0でのみ作成すると（上記の推奨リリースを使用するため）、少なくともさらに2年は延期されます。

一方、PEP 517は、デフォルトのバックエンドが何であるかについては何も指定していません。

本当。 しかし、ある時点で、pipはsetuptoolsの特別なケースのサポートを終了します。 つまり、結局のところ、PEP 517の（少なくとも私たちにとっての）要点は、フロントエンドをバックエンドから切り離し、すべてのバックエンドを同等の立場に置くことです。 そのため、これを行うときは常に、バックエンドがない場合はエラーを発生させるか、デフォルトを選択する必要があります（レガシーの理由から、デフォルトでsetuptoolsを選択します）。 ここでの議論は、私たちがそれを行うときであり、そうでない場合ではありません。

Pipには現在、インストール用の2つのコードパスがあります。PEP517パスと従来のsetup.pyパスです。 これがメンテナンスの問題と潜在的なバグの原因です。 PEP 517パスの使用を確実にするためにpyproject.tomlが存在する場合、PEP 517をデフォルトにすることを選択しました（プロジェクトがbuild-backend = setuptools.buid_metaを急いで追加する可能性は低いため、現在の動作がなければ、確率は次のようになります。 pipのPEP517コードとsetuptoolsのバックエンドの両方のテストは、長期間ゼロに近いままです）。 setuptoolsバックエンドが不適切であった（まれに想定される）ケースに正確に対応するために、 --no-use-pep517の形式でオプトアウトがあります。

setuptoolsがsetup.pyとバックエンドの間にセマンティックの違いを持ちたいとは誰も予想していなかったので、セマンティックの違いを回避するために--no-use-pep517が必要になる可能性があります。デフォルトは考慮されていませんでした。

また、setuptools.build_meta_legacyのようなsetuptoolsで「ダミー」のPEP 517バックエンドを作成して、ルートディレクトリにchdirし、setuptools.build_metaを呼び出すこともできます。これにより、ユーザーは、壊れ始める前に必要な場合にのみ、古い動作にオプトインできます。 。

それは合理的な解決策かもしれません。 ただし、少なくとも部分的に文書化する必要があります。少なくとも、pipは、これが想定されるデフォルト値であることを文書化します。 setuptoolsがバックエンドを文書化しないままにすることを選択したかどうかは、私が推測する彼らの選択です。

これ以上の理論的議論がどれほど役立つかはわかりません。 確かに、これ以上追加するものはないと思います。 誰かがこれを前進させたいのであれば、デフォルトを切り替えるPRを作成するのが最善の方法であり、それを受け入れるかどうかについての議論はそこに移ることができます。

ユーザーのためにこの問題を解決しようとしているパッケージメンテナの場合： sys.path修正を実装するシムを公開しました。

https://pypi.org/project/setuptools-localimport/

うまくいけば、これは一時的なものとして機能するので、解決策に急ぐことなくこれをどのように進めるかを考えることができます。または、pip 19.0（PEP 517よりもはるかに多くの機能が含まれています）の採用を不必要に遅くすることができます。

sys.path修正を実装するシムを公開しました。

すごい！ 最終的な修正に関係なく、これはPEP517フックシステムの柔軟性の本当に良い例です:-)

私は19.xの下で私のpipバージョンをダウングレードすることによってそれを修正しました、そして私はインストールしようとしました、そしてうまくいきました

3番目のユースケースがあります：独自のビルドバックエンドを提供しているパッケージはどうですか？ 例：setuptools自体はビルド要件としてwheelのみをリストします：

[build-system]
requires = ["wheel"]
build-backend = "setuptools.build_meta"

もちろん、PEP 517を処理するためのpipのコードがソースディレクトリをsys.path追加しない場合、これは失敗します。

PEP 517から：

モジュールパスをインポートするとき、ソースツリーを含むディレクトリは検索しません。ただし、それがsys.pathにある場合を除きます（たとえば、PYTHONPATHで指定されているため）。 Pythonは状況によっては自動的に作業ディレクトリをsys.pathに追加しますが、バックエンドを解決するコードはこれによる影響を受けないはずです。

これは（私にとって）かなり明確に言っていますが、プロジェクトはbuild-backend解決するときに、自分のプロジェクトディレクトリを表示できると期待すべきではありません。そのため、setuptoolsはrequires IMOに自分自身を追加する必要があります。 はい、そうすることは循環的であることを理解しています。 しかし、それ自体を構築するビルドバックエンドは、本質的にかなり循環的です-それらは確かに通常のケースではありません。

同じセクションで、ビルドツールがプロジェクトディレクトリがビルド環境のsys.pathにあることを期待してはならないことも確認しているようです。

それは--no-binary :all:どのように機能しますか？

@pfmoore状況の変形は、パッケージがカスタムビルドシステムを提供することです。 ビルドシステムはインストールされていません（そしてbdistの一部ではありません）が、おそらくいくつかのビルドプロセスをカスタマイズするためにsdistに付属しています。 これは有効なユースケースですか、それともメンテナはカスタムビルドシステムを個別のパッケージとして公開する必要がありますか？

編集：のようなもの

project/
    custom_build.py
    src/
        my_package/
            __init__.py
            ...
    pyproject.toml  

[build-system]
requires = []
build-backend = "custom_build"

# Maybe the custom backend specifies metadata like this…
[tool.custom_build.metadata]
name = "my-package"
dependencies = []
packages = ["my_package"]

おそらく解決策は、ビルド中にモジュールを見つける場所を示すために、新しいオプションの構成を追加することです。

[build-system]
requires = []
build-backend = "custom_build"
build-backend-findpath = ["build_systems"]   # Put custom_build.py above in a subdirectory.

構成のデフォルトは[] （空のリスト）です。つまり、パスは追加されません（つまり、現在の動作と同じです）が、プロジェクトはパスを追加してビルドシステムをローカルで見つけることができます。

build-systemが完全に省略されている場合、セクションのデフォルトは次のとおりです。

requires = ["setuptools", "wheel"]
build-backend = "setuptools.build_meta"
build-backend-findpath = [""]

pipは、警告/情報メッセージを表示して、ユーザーに移行するように指示できます（ドキュメントページへのリンクが含まれている可能性があります）。

このソリューションの追加の利点は、すべてがpip（実際にはベンダーのpep517モジュール）で実行できることです。 setuptoolsや既存の壊れたプロジェクトを変更する必要はありません。

状況の変形は、パッケージがカスタムビルドシステムを提供することです。

正直わかりません。 それは私が自分自身について考えた状況ではありません。 PEPの作者がそれを考慮したかどうかはわかりません。PEPが開発されていたときの問題についての議論は覚えていません。

実際、確認したところ、PEP 517は明示的に（ build-backendのセクションで）「モジュールパスをインポートするとき、とにかくsys.pathにある場合を除いて、ソースツリーを含むディレクトリを調べません。 「これは、ツリー内のバックエンドを持つことが明示的に推奨されていないことを意味します。 誰かがこれを十分に悪意のあるコードで回避できるかどうかはわかりません（しかし、私はそうは思わない）。

PEP 517を開発したときに予想されたユースケースは、バックエンドがPyPI（またはカスタムインデックス）のホイールとして出荷され、ビルド環境にダウンロードおよびインストールされることでした。 バックエンドがどのように構築されたかは明らかに範囲外でした-私の個人的な推測では、バックエンドはPEP 517メカニズムを使用せず、低レベルのコマンド（たとえば、 setup.py bdist_wheelまたはflit build ）を使用します。 ）。 PEP 517バックエンドを再帰的に使用してそれ自体を構築することは、複雑すぎるステップのように見えました。 これは、pipでのPEP 518実装の一部と見なされていました（バックエンドがsdistとして出荷され、それ自体を使用してビルドする場合、フォーク爆弾が悪用される可能性があります。ホイールとして配布されていないバックエンドをサポートする前に、これを防ぐ必要がありました。 ）ただし、PyPIからバックエンドをダウンロードする場合のみ。

tl; dr; 私が提供できるのは、当時の議論を思い出すことだけです。実際の背景については、アーカイブを検索したほうがよいかもしれません。

PEPの作者がそれを考慮したかどうかはわかりません。PEPが開発されていたときの問題についての議論は覚えていません。

私はアーカイブを見始めたばかりですが、この質問は実際にプロセスの終わりに向かって（または少なくとも十分に）詳細に議論されたようです。 アーカイブを表示するのに最適なWeb​​サイトはわかりませんが、この質問について再び議論が始まる1つのポイントがあります（2017年7月28日）。
https://mail.python.org/pipermail/distutils-sig/2017-July/031109.html
https://www.mail-archive.com/[email protected]/msg26624.html

たとえば、この特定の電子メールは次で終わります-

すでにPEP517でどれほどの問題が発生しているのかを考えると、PEP 517にディレクトリをsys.pathにないように指示し、python-path専用に少しフォローアップPEPを作成する方が理にかなっているかもしれません。

最終的な評決が何であるかを見つけたらお知らせしますが、他の人にも自分で読んでもらうことをお勧めします。

いいね！ それを見つけてくれてありがとう:-)

だから私はたくさんの電子メールをざっと読んだ。少なくとも8月29日までスキップできると思う。ニックはsys.pathのソースディレクトリ_out_を離れることについてコンセンサスがあることを示唆しているようだ。
https://mail.python.org/pipermail/distutils-sig/2017-August/031413.html
（一人ずつ、人々はナサニエルの議論を確信するようになりました。）

ただし、上記のリンク先の同じメールで、ニックは次のように述べています:)

1. それを省略することが本当に問題である場合は、setup.pyバックエンドの実装の一部としてすぐにわかるでしょう。

これが電子メールからのより完全な段落です：

私は、我々は初期の一環として、新しい何かを学ぶ私たちのチャンスを最大化が意味する出発物質として、「現在のディレクトリが指定されたバックエンドをインポートする前のsys.pathにされていないことを確認しなければならないフロントエンド」を優先して解決、このいずれかを考えることができると思いますので、暫定的に承認されたAPIのロールアウト。

この要約を変更するメールが後であるかどうかはまだわかりませんが、その後のトピックに関するメールはそれほど多くありません。

@cjerdonekのためにアーカイブをトロールしてくれてありがとう。 問題についての私の現在の理解を述べる：

1. 多くの実際のsetup.pyファイルは、現在、実行時に現在のディレクトリがsys.pathにあると想定しており、プロジェクトがインストール時の依存関係として処理するため、奇妙なブートストラップの問題が発生します。
2. PEP 517は、ビルドフロントエンドが現在のディレクトリをsys.path暗黙的に追加してはならないと明示的に述べています（バックエンドについては何も述べていません）
3. pip 19.0は、 build-systemセクションのないpyproject.tomlを、 setuptoolsバックエンドを指定するbuild-systemセクションと同等であると見なします。
4. setuptools PEP 517バックエンドは現在のディレクトリをsys.pathも追加しません（上記のポイント1から離れることは望ましい将来の目標と見なされるため）
5. デフォルトの動作が改善されている間、2つの暫定的な回避策が既存のプロジェクトで利用可能です： pipを19.0未満に固定することと、 --no-use-pep517オプションを明示的に設定することです。 ただし、人々は、 pipをアップグレードするとビルドが破損することを最初に発見した後でのみ、それらを発見します。

機能的な観点から、私たちが導入したい重要な変更は、「 build-systemセクションのないpyproject.toml 」の場合、 setup.pyを含むディレクトリが最終的になることだと思います再びsys.pathに。 これを処理するには、主に2つの方法があります。

1. それを行うにはpipを入手してください。 これには、動作をフロントエンドに依存させるという不幸な副作用があり、すべてのフロントエンドが同じ回避策を実装しない限り、既存のプロジェクトのインストールに失敗する可能性があります。
2. setuptools PEP 517バックエンドを取得して、 build-systemセクションのpyproject.tomlを検査し、 setup.pyディレクトリをsys.path挿入します。セクションとパスエントリの両方が欠落している場合。 「 build-systemセクションがない」場合を正しく処理するsetuptoolsの最小バージョンを指定する必要があるため、この状況でも新しいpipが必要です。

不幸なデザインコーナーに自分自身を塗りつぶすことなく、エンドユーザーのためにできるだけ早く物事を機能させるために、私は実際に3ステップの解決策を提案します。

1. 新しいpipリリース（19.0.1？）を実行して、「 build-systemエントリがない」場合の追加のsys.pathエントリを追加します。 この時点で、互換性の問題はエンドユーザーにとってほとんどなくなるはずです。
2. フロントエンドがまだ行っていない場合は、sys.pathの追加を処理する新しいsetuptoolsリリースを実行します。
3. それ以降のpipリリースでは、「 build-systemエントリがない」ケースを変更して特別なケーシングを削除し、代わりにsetuptoolsより厳密な最小バージョンを設定します。

この提案は、 setuptools PEP 517バックエンドがsetup.py下位互換性の問題を処理するための「適切な」場所であると思うという事実に基づいていますが、 pipを調整することも考えています。直接的な変更は、短期的にははるかに単純な変更になる可能性が高く、アーキテクチャ的に望ましい修正が行われている間、問題が含まれる変更です。

pypa / setuptools＃1652でbuild_meta_legacyバックエンドを作成しました。 pipがデフォルトのバックエンドとしてsetuptools.build_meta_legacyを使用するように切り替わるのであれば、私は本当にそれを好みますが、組み込みの「レガシーシム」バックエンドを作成することは、私が快適に行ける範囲であると思いますsetuptools 。 メインのsetuptools PEP 517バックエンドで完全な「 python setup.py installエミュレーション」を無期限にサポートすることに固執したくありません。

setuptoolsがここTBHでネイティブにスクリプトを実行することをエミュレートしたくない理由は少し混乱しています。 python setup.py bdist_wheelが正しく機能する場合、エンドユーザーに混乱を招くように思われますが、 pip wheelは機能しません（非レガシービルドバックエンドに設定されていると仮定）。

理論的根拠は何ですか？

理論的根拠は何ですか？

私の長期的な計画は、 setup.pyすべての直接呼び出しを廃止し、PEP 517フロントエンドまたは同等のもの（他のコマンドの場合）による間接呼び出しを優先することです。 私たちは「すべての隔離環境」の世界に移動している場合は、私がのセマンティクス保つために強制されないようにするsetuptools呼び出すと互換性のあるコマンドの呼び出しpython setup.py同じ理由PEPのために、 517は特に、フロントエンドはこれを行うべきではないと述べました。これは、ビルドの分離を破り、一般的に望ましくない状況を引き起こす可能性があります。

アンチパターンの一部を除いて、これが必要になることはかなりまれだと思います。 それを正当に必要としている人は誰でも、セットアップスクリプトでsys.pathを非常に簡単に操作できます。

ちょうどメモとして、PEP 517が、すべてのビルドツールへのアクセスがフックを介して可能になるという設計目標を持っていたとは思いません。 たとえば、flitには独自のコマンドセットflit buildなどがあり、それらを非推奨にするつもりはありません。 したがって、PEP 517の背後にある意図が、ツール固有のコマンドを使用する必要があるというエッジケースを見つけることができる可能性があります。 明らかな例はバックエンド自体のビルドです（前述のとおり）が、編集可能なインストールやインプレースビルド（以前のビルドのアーティファクトを再利用）などの他のケース（現在標準化されていませんが、将来のPEPはフックを追加する可能性があります）が存在します。

すべてのツールが「buildsdist」と「buildwheel」をサポートできるという合意を得るのは非常に困難だったので、標準操作のリストをこれ以上拡張することはすぐには起こりません。

ちょうどメモとして、PEP 517が、すべてのビルドツールへのアクセスがフックを介して可能になるという設計目標を持っていたとは思いません。

これは私が提案したことではなく、少し余談です。 私のポイントは、問題が必要PEP 518はまた、すべてのために、より一般的に存在することをということでしたsetup.pyコマンド、およびそれらが最高離れ呼び出しから人々を移動することで解決されるsetup.pyすべてで。 flitがサブコマンドを追加するためにPEPを必要としないのと同じ方法でこれを行うために、標準は必要ありません。

ああ、わかりました。 誤解してすみません。

@ncoghlanの提案された移行は私には良いようです。 誰も問題がなければ、先に進みましょう。

アーカイブ@cjerdonekを掘り下げてくれてありがとう！

setuptoolsでこれを修正するPRがすでにあることを考えると（レガシーバックエンドの導入を通じて）。 上記のステップ1をスキップしない理由はありますか？ setuptoolsを分離されたビルド環境にインストールしているので、ごく最近のバージョンに依存することは問題にはならないはずです。

上記のステップ1をスキップしない理由はありますか？

いいえ。 現在の最小必要バージョンを直接バンプできます。

私の移行計画は、人々がsetuptools側で長寿命の移行メカニズムを理解するためにより多くの時間を必要とするという仮定に基づいています-@ pganssleの専用の移行バックエンドはその面で有望に見えますが、私はその変更がレビューされている間、現状を維持することが理にかなっているのかわかりません。

とはいえ、 pipでのPEP 517の実装がどのように機能するかについての詳細はよくわからないため、フロントエンドでの問題の回避は簡単であるという私の仮定は正しくない可能性があります。

バックエンドはサブプロセスで実行されるため（実際には、ベンダーのpep517プロジェクトを使用して、間接レベルを追加します）、 sys.pathをどのように設定するかはまったくわかりません。バックエンドフック。 少なくとも、 PYTHONPATHを含める必要があります。これは、ユーザーがすでにPYTHONPATH設定している場合と、分離コードがそれをどのように使用するかについて心配することを意味します。

基本的に、pipにsys.pathを設定することは、明らかに重要なことだと思います。 詳細を調べる時間がない可能性があります。パッチを自分で作成する（そして適切にテストされていることを確認する）ことはほとんどありません。

修正されたsetuptoolsバックエンドを入手することが最速の方法だと思います。

私の長期的な計画は、setup.pyのすべての直接呼び出しを廃止し、PEP 517フロントエンドまたは同等のもの（他のコマンドの場合）による間接呼び出しを優先することです。

@pganssle痛い。 手続き上のsetup.pyは死ななければなりません。 何らかの理由で存在してはなりません。 この「柔軟性」は、痛みと故障の無限の原因であるためです。 setup.pyを移行することは不可能であるため、Pythonパッケージングに関するすべての問題が発生します。

setup.pyをpackage.json置き換え、さらに別のパッケージ記述形式の代わりにPythonセクションを追加します。

少なくとも、 ==1.xバージョン指定子を使用でき

@techtonik離れてください。 私が参加しているどのプロジェクトでも、あなたの非建設的な貢献は歓迎されません。

＃6210に取り組んでいると、 pipレベルでこれに対処するのがどれほど難しいかについての私自身の質問に答えることができます。課題は、ソースディレクトリをsys.path[0]として挿入する必要があるかどうかに関する情報です。 pyproject.tomlを読み取るコードからPEP 517フック呼び出し元にトンネリングされ、そこから実際のインプロセスラッパースクリプトにトンネリングされる必要があります。

これらは大きなアーキテクチャの変更なしで実行できます（最初の部分のビルドバックエンド名のpip._implicit.プレフィックス、後者のPEP517_SYS_PATH_0 env var）が、ベンダーのpep517一時的に変更することを意味しますsetuptoolsの適切な修正の準備ができるまで、 pep517コード。

私の移行計画は、setuptools側で長寿命の移行メカニズムを理解するために人々がより多くの時間を必要とするという仮定に基づいています-@ pganssleの専用の移行バックエンドはその面で有望に見えますが、それが理にかなっているかどうかは

はい、同意します。 私はdistutilsの投稿でこれだけを提案しました、私が重要だと思う2つのことがあります：

1. できるだけ早くユーザーのために修正を取得する
2. 適切な移行を実施します。

個人的には、移行ロジックが配置されるまで、「pyproject.tomlの存在によってPEP517にオプトインする」ロジックを削除するのが正しいと思います。 setuptoolsでの変更は、その公開APIに影響を及ぼし、 pipでは、後方互換性のない変更であることが判明したことを遅らせるだけであることを考えると、私には理にかなっています。 setuptools今後の方向性を検討している間に、 pipクイックフィックスを実行します。

両方のアプローチがローカルマシンで動作している状態で、元の問題のあるPyInstaller==3.4要件に対して＃6210と＃6212の両方をテストしました。

• ＃6210は希望どおりに機能しました： https ：
• ＃6212が期待どおりに動作していません： https ：

＃6212の失敗がテストセットアップの問題なのか、それともsetuptoolsプレリリースにさらに問題があるのか​​はわかりませんが、その解決策に自信を持つ前に、さらに統合作業を行う必要があることだけを知っています。私は今＃6210に自信を持っていますが、それの唯一の間違いは、 pipを永遠に持ち歩かなくてはならないという恐ろしい互換性ハックだということです。

--no-cacheが、＃6212で失敗したassert原因であるようです。 代わりに--cache-dirテストすると、ローカルテストが成功しました： https ：

（私は睡眠と仕事のために約18時間オフラインになるので、それまでの間、＃6210または＃6212のどちらかが理にかなっている方で自由に走ってください）

状況をよりよく反映するようにタイトルを更新しました。 PRをありがとう@ncoghlan ！

モデレートノート：私は先に進んで、非生産的なコメント（およびそれらへの応答）を「オフトピック」として非表示にしました。これらの行に沿った今後のコメントについてもそうします。 モデレーションについて話し合いたい場合は、新しい問題を提出するか、メールでpingしてください。 このスレッドは、モデレートに関する問題を提起するのに適切な場所ではありません。

また、重複を作成する人を避け、これについて知っていることを明確に示すために、これを先に進めて固定しました。

pep517をオプトインした場合でも、これは発表されていない動作の変更であるため、ライブラリが既にオプトインされている場合でもライブラリが破損します（たとえば、 PyInstallerを参照）。 ライブラリがpep517ビルドへのオプトインを宣言し、 sys.pathで見つかると予想されるものをローカルにインポートする場合、pipによって行われる仮定はありませんが（ライブラリが明示的であるため）、ライブラリはまだ突然壊れた。

その場合、setuptoolsにcwdを含める以外に、これが壊れているだけなので、実際には代替手段が見つかりません。 pep517とpip19の間にカットしたリリースに戻って修正するように人々に指示する提案でない限り、ユーザーがこれらのバージョンを厳密に固定していると、突然インストールできなくなる可能性があります。ユーザーエクスペリエンスに関するこれらの決定のこの議論と現在の提案に基づいて、これらのライブラリの一部は、pep517ビルドが明示的に無効にされていない限り、デフォルトを使用して新しいバージョンのpip + setuptoolsでインストールできません。

これは、Pythonから提供されたツールを使用してパッケージをインストールしようとしているだけの場合はかなり影響がありますが、実際にはランダムにインストールすることはできません。 これは、技術的な側面から少しの間焦点を外し、ツール、エコシステム、ライブラリ、または言語自体に不満を感じる可能性のあるエンドユーザーへの影響に焦点を当てるためです。特定の状況）、彼らが今うまくインストールできたものはインストールできません。 実装されているソリューションでは、このギャップを埋めるべきだと本当に思います。

現在、pipenvで失敗したインストールを処理するために失敗スタックを使用しており、これらの変更の結果として失敗を処理するために利用可能な場合は--no-use-pep517追加しています。 問題の原因がすぐにはわからないので、それが平均的なユーザーにとって直感的であるかどうかはわかりません。 これは回避策があることを指摘するためだけに言っていますが、このギャップを埋めて、ユーザーがこのギャップを少し理解できるようにすることが重要だと感じています。

（編集：pganssle、cjerdonek、pfmoore、pradyunsg、ncoghlan、およびこれに多くの時間と労力を費やしてくれた他のすべての人にも感謝します）

PEP 517を開発したときに予想されたユースケースは、バックエンドがPyPI（またはカスタムインデックス）のホイールとして出荷され、ビルド環境にダウンロードおよびインストールされることでした。 バックエンドの構築方法は明らかに範囲外でした。私の個人的な推測では、バックエンドはPEP 517メカニズムを使用せず、低レベルのコマンド（setup.pybdist_wheelやflitbuildなど）を使用します。 PEP 517バックエンドを再帰的に使用してそれ自体を構築することは、複雑すぎるステップのように見えました。 これは、pipでのPEP 518実装の一部と見なされていました（バックエンドがsdistとして出荷され、それ自体を使用してビルドする場合、フォーク爆弾が悪用される可能性があります。ホイールとして配布されていないバックエンドをサポートする前に、これを防ぐ必要がありました。 ）ただし、PyPIからバックエンドをダウンロードする場合のみ。

これに戻ると、新しいsetuptools.build_meta_legacyデフォルトは、 setuptools自体の問題であるPEP517バックエンドを除くすべてにPEP517を使用する場合の問題を解決します。 それを解決しないと、@ benoit-pierreがpypa / setuptools＃1644で指摘しているように、 setuptools依存するプロジェクトにpip install --no-binary :all:を使用することはできません。 （または、おそらく任意PEP 517のバックエンド・プロバイダ）。

このスレッドでそれについて話し合うべきですか、それともそれについて話し合うために新しいスレッドを作成するべきですか？

このスレッドでそれについて話し合うべきですか、それともそれについて話し合うために新しいスレッドを作成するべきですか？

私はそれを分割します。 私の当面の感覚は、問題はここで--no-binary :all:が重大な意図しない結果をもたらすことであり（実際には、sdistsではなくホイールのみを配布するプロジェクトの存在下でそのフラグを使用することの影響と同様です）、私は欲しいです（たとえば） --no-binary :all:を使用することの推奨性への逸脱を避けるために、このスレッドからさらに注意をそらします。

--no-binary :all:ビルドバックエンドの問題を修正することは、これほど重要ではないと思います。 ユーザーがすでに--no-binary :all:指定している場合は、比較的簡単に--no-use-pep517追加できます。

新しいPR＃6229：

1. pyproject.toml build-systemセクションを作成する@pganssleの提案された暫定的な回避策を実装し、PEP 517に自動的にオプトインするための初期要件（「任意のpyproject.tomlファイル」オプトを延期後のリリースに）
2. setup.pyからの隣接パッケージのインポートをカバーする3つの専用テストケースを追加します

エンドユーザーが再び機能するようにするための最小限の修正であり、＃6210のような恐ろしいハックや＃6212のような新しいsetuptoolsリリースを必要としないため、他の2つのPRを閉じて1つにします。

では、それはsetuptools.build_meta_legacyどこに残すのでしょうか？ pyproject.tomlで明示的に指定するために、「隣接パッケージのインポート」機能を必要とするプロジェクトを要求するという提案はありますか？ もしそうなら、その仕様なしで隣接するパッケージをインポートすることは非推奨であり、pip 19.Xで削除されるという事実とともに（Xが何であるかについて同意する必要があります）、どこかに文書化する必要があることを強くお勧めします、それを行うことはできませんプログラムによる非推奨（私は思いません）ですが、それが明確に文書化する理由であるため、十分な通知なしに機能を削除したとして（再び）非難されることはありません。

編集：しかし、そうでなければ、新しいPRと要約に感謝します。

編集2： setuptools.build_meta_legacyプロポーザルを閉じたようです。 私たちの長期計画が何であるかを今言う機会を失うので、私はそれが好きかどうかはわかりません。そのため、前述のように、非推奨期間を延長します...

ノー@pfmoore、所望の動作になって背中が（おそらくに更新することにより、＃6163の回避策を削除すると関連する新しい問題でカバーしなければならないことを意味setuptools提供するsetuptools.build_meta_legacy ）。

編集：今のところ、＃6212を再開しましたが、現在失敗しているインストールコマンドを修正する前に、 build_meta_legacy議論全体が解決されるのを待つ必要がないことを明確にするために、タイトルを変更しました。

私の提案は、実際には、PEP 517のオプトインはbuild-systemの存在ではなく、 build-system.build-backend指定しており、現在から19.1リリースまでの間にsetuptoolsが追加されるというものbuild_meta_legacyとpipは、これをデフォルトのバックエンドとして使用します。

19.1で、おそらくpipがsetuptools.build_meta_legacy見つけられない場合は、古いコードパスにフォールバックする必要があることに同意します。 これにより、最大人数を選択しながら、最小限の重大な変更が可能になります。

私の提案は、実際には、PEP517のオプトインでbuild-system.build-backendを指定することでした。

...これはフォールバックの場合にuse_pep517 = Falseを設定するだけで処理できます（現在行っているhas_pyproject設定するのではありません）。

19.1では、おそらくpipがsetuptools.build_meta_legacyを見つけられない場合は、古いコードパスにフォールバックする必要があります。

これはやる価値がないと思います。 レガシーバックエンドを確実に入手できるように、十分に新しいsetuptoolsバージョンを指定します。また、setuptoolsが将来のバージョンでそのバックエンドを削除する可能性に対応する必要はありません（または、削除する場合は、結果として生じる問題について単にそれらを非難します;-)）

注： use_pep517 = Falseデフォルトは、＃6229が開始したものですが、PEP518テストで失敗を引き起こしました。

1. 「 build-system.requiresが設定されています」の場合は、ビルド分離を使用する必要があります。これにより、親環境に影響を与えることなく、要求された依存関係をインストールできます。 現在のコード構造を考えると、これを行う最も簡単な方法は、この場合はuse_pep517 = Trueを設定することです。そのため、これを実行して、テストケースを再度合格させました。
2. [build-system]テーブルがない場合は、 pyproject.tomlが[tools]テーブルに設定を格納するために使用されていることを示しuse_pep517 = Falseを使用する必要があります。最初に報告された問題については、このテストケースを予想される失敗としてマークしました。
3. これにより、「空の[build-system]テーブル」のケースが残ります。これは、どちらの方向でも合理的に解決できると思います。 ただし、実際にはこの特定のケースが頻繁に発生するとは思わないため（ requiresまたはbuild-backendを設定せずにbuild-systemテーブルを追加するのに苦労するのはなぜbuild-backend ？）、2番目の予想される障害マーカーを追加するのではなく、以前に定義されたPEP518テストケースに合格することを意味する方法で解決することを選択しました。

3を反対方向に解決するには、次の行を変更する必要があります。

use_pep517 = build_system is not None

代わりに：

use_pep517 = build_system is not None and build_system.get('requires', None)

そうすれば、空でない要件のみがPEP 517ビルド分離にオプトインします（空のbuild-system.requiresフィールドの動作が異なるため、4番目のテストケースを追加することも意味します）。

ここでの招待されていない貢献については申し訳ありませんが、これはすべてsys.path cwdがないようにするためのかなり手の込んだ方法のように感じられ、最終的には以前は機能していたものが壊れたままになり、非常に混乱を招くことに気づかずにはいられませんUXの観点から。

これにより、重要な数のユーザーとパッケージが影響を受けます。 それらの少なくとも一部には[build-system]セクションが定義されており、_また_古い動作に依存しているため、これらのバージョンを固定している人にとっては壊れたままになります。

@techalchemyええ、 pipの元々の仮定は、 setuptools.build_metaがsys.path観点から、 setup.py直接呼び出しと同じように機能するというものsys.path正しくないことが判明した。 https://github.com/pypa/setuptools/pull/1652で定義されているsetuptools.build_meta_legacyバックエンドを含むsetuptoolsリリースが利用可能になると、＃6212を完了することができ、それは長くなります用語の解決。 ただし、そのようなリリースの現在のETAはないため、明示的に「PEP 517ネイティブ」ではないパッケージのソースディレクトリをsys.pathに戻すには、 pipのみの解決策を引き続き調査する必要があります。 "。

＃6229で、「デフォルトでPEP 517」の採用を単に延期するという@pganssleの提案を実装しpip 19の別の変更により、解決するよりも多くの問題が発生するようです。 build-system.requiresはbuild-system.build-backendの処理に関連付けられているため、 --no-use-pep517はPEP 518も無効にします（これによりテストスイートの失敗が発生し、ビルドの場合は実際のインストールの失敗も発生する可能性があります依存関係はプリインストールされていません）。

＃6210では、代わりにpep517にローカルでパッチを適用して、サブプロセスへのsys.path[0]挿入をサポートし、 setuptools.build_meta_legacyが将来setutpools実行すると予想されるのと同じことを効果的に実行します。 build-system.requiresは引き続き処理され、 setup.pyが実行されると、ソースディレクトリはsys.path[0]になります。 また、 https： //discuss.python.org/t/pep-517-backend-bootstrapping/789/29？u = ncoghlanで提案したものと非常によく似ており、 https://github.com/でドラフトしました。 pypa / pep517 / pull / 42 / --no-binary :all:と互換性のある方法でセルフブートストラップバックエンドを処理します

AWOLRMになってすみません。 思いもよらなかったことが起こった。

私は明らかにこれに対するsetuptools側の修正を好みますが、＃6210は私にとってもクールです-短期的な修正として。

@techalchemyと@pradyunsgに同意します-setuptools側の修正がここでの正しいアプローチだと思います。 pip内で高速な修正を見つけようとする作業に感謝しますが、 _build_meta_legacyを使用してsetuptoolsの新しいリリースを促進するためにそのような時間を費やしたほうがよいのではないでしょうか。 setuptoolsの中にクイックフィックスをリリースするとの問題は（setuptoolsのは、サイクルが速くピップのより方法ですリリース）がありますなぜ私はすべて明確ではないんだので、私は、setuptoolsの上で何が起こっているか見ていません。

短期間のpip-side修正は問題ありませんが、setuptoolsの修正がいつ期待できるかを明確にしたいと思います。

こんにちは、みんな！

私は同じ問題を抱えています：

**Collecting pyinstaller==3.4
  Using cached https://files.pythonhosted.org/packages/
a0cc/PyInstaller-3.4.tar.gz
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  Complete output from command "c:\program files (x86)\
gram files (x86)\microsoft visual studio\shared\python3
requires_for_build_wheel C:\Users\ASUS\AppData\Local\Te
  Traceback (most recent call last):
    File "c:\program files (x86)\microsoft visual studi
process.py", line 207, in <module>
      main()
    File "c:\program files (x86)\microsoft visual studi
process.py", line 197, in main
      json_out['return_val'] = hook(**hook_input['kwarg
    File "c:\program files (x86)\microsoft visual studi
process.py", line 54, in get_requires_for_build_wheel
      return hook(config_settings)
    File "C:\Users\ASUS\AppData\Local\Temp\pip-build-en
, line 115, in get_requires_for_build_wheel
      return _get_build_requires(config_settings, requi
    File "C:\Users\ASUS\AppData\Local\Temp\pip-build-en
, line 101, in _get_build_requires
      _run_setup()
    File "C:\Users\ASUS\AppData\Local\Temp\pip-build-en
, line 85, in _run_setup
      exec(compile(code, __file__, 'exec'), locals())
    File "setup.py", line 20, in <module>
      from PyInstaller import __version__ as version, H
  ModuleNotFoundError: No module named 'PyInstaller'**

問題が解決したかどうか誰かが知っていますか？ またはそれを一時的に解決する方法は？

皆さんありがとう！

@ jce94 、今のところpip <19を使用します。

@altendky情報をありがとう！

pipenvを使用しているときに、推奨される回避策でこの問題を解決できませんでした。 凍結pipに18.1でPipfileなど何の効果もないようだpipenv最新ピップバージョンを強制的に維持します。 手動でpipを18.1に設定できますが、pipenv仮想環境を再作成すると、Pipenvは何があっても最新のpipにアップグレードします...それを維持するための推奨事項はありますか？

@altendky残念ながら、pipenv（および私が思う詩）ユーザーは、事前定義されたバージョンのpipを使用することはできません。 どちらも最新バージョンを使用しています。 だから今のところ多くの人が壊れたパイプラインで立ち往生していると思います

さらに奇妙なことに、それは一貫して起こっていません。 Appveyorジョブを再実行しました。最初のジョブは成功し、2番目のジョブは失敗しましたが、完全に同一です。

誰かがタイムラインについて疑問に思っている場合は、今週の終わりまたは来週の初めまでに修正を準備し、その後すぐにpipのバグ修正リリースを行うことができると思います。

setuptoolsの新しいバージョンであるバージョン40.8.0が、 build_meta:__legacy__バックエンドで利用できるようになりました。

ありがとう！ そして、これはPyInstallerに使用するように指示する必要があるものですか？ 彼らはいた
変更に非常に不満です...私が提示できるドキュメントまたはPEP
変更をサポートするためにそれらを使用しますか？

2019年2月5日火曜日、10：24 Paul Ganssle < [email protected]は次のように書いています。

setuptoolsの新しいバージョンであるバージョン40.8.0が、
build_meta：__ legacy__バックエンド。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/pypa/pip/issues/6163#issuecomment-460747909 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/ADtXZjnOfu56IYR6VEKK4yowMg3XdcFEks5vKcxBgaJpZM4aNvmP
。

@AlmogCohenいいえ、これは直接使用する必要があるものではなく、 pipがデフォルトのバックエンドとしてbuild_meta:__legacy__使用を開始することです。 これは、エンドユーザーの観点からは実行可能ではありません。

修正を統合する新しいリリースのETAはありますか？

ほんの数時間で。 :)

固定された問題を参照してください。

pip 19.0.2がリリースされ、この問題が修正されました。

--no-use-pep517を使用している場合でも、最新バージョンのpipでpyinstallerをインストールできません

pip install pyinstaller --no-cache-dir --no-use-pep517
Collecting pyinstaller
  Downloading https://files.pythonhosted.org/packages/03/32/0e0de593f129bf1d1e77eed562496d154ef4460fd5cecfd78612ef39a0cc/PyInstaller-3.4.tar.gz (3.5MB)
     |████████████████████████████████| 3.5MB 273kB/s
  Installing build dependencies ... done
    ERROR: Complete output from command python setup.py egg_info:
    ERROR: Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\Raffaele\AppData\Local\Temp\pip-install-5e9w2p2c\pyinstaller\setup.py", line 20, in <module>
        from PyInstaller import __version__ as version, HOMEPATH, PLATFORM
    ModuleNotFoundError: No module named 'PyInstaller'
    ----------------------------------------
ERROR: Command "python setup.py egg_info" failed with error code 1 in C:\Users\Raffaele\AppData\Local\Temp\pip-install-5e9w2p2c\pyinstaller\

このスレッドは、閉じられた後に最近のアクティビティがないため、自動的にロックされています。 関連するバグについては、新しい問題を開いてください。