<p>pip 19.0 gagal menginstal paket yang mengimpor paket yang akan diinstal dari CWD</p>

Ini tampaknya menjadi masalah dengan cara pyinstaller mengimpor dirinya sendiri untuk instalasi.

Mungkin merupakan ide yang baik untuk mengajukan masalah pada orang-orang PyInstaller.

Saat ini kami menggunakan 18.1, dan meningkatkan ke 19.0 menyebabkan masalah ini juga bagi kami. Ada masalah terkait di repo PyInstaller, karena pip '' tidak ada di sys.path.

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

Saya pikir ini adalah alur kerja yang cukup umum. Anda memasukkan __version__ = "1.2.3" di foo/__init__.py dan kemudian melakukan import foo di setup.py sehingga Anda tidak perlu menentukan versi di dua tempat. Dan setiap pengguna perpustakaan dapat memeriksa versi sesuai dengan PEP 396 .

# foo/__init__.py
__version__ = "1.2.3"

# setup.py
from setuptools import setup

import foo

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

Selain itu, ini hanya terjadi jika Anda memiliki file pyproject.toml (dan setup.py ). Hapus dan instalasi berfungsi dengan baik. Jadi sepertinya ada beberapa perbedaan perilaku di sana. Mungkin cara tradisional memodifikasi sys.path / PYTHONPATH ?

Ah, saya pikir saya mengerti apa yang terjadi. Karena dengan menggunakan file pyproject.toml , pada dasarnya Anda memberi tahu pip bahwa Anda ingin menggunakan PEP 517/518.

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

Di atas memberi tahu pip bahwa ia membutuhkan setuptools dan wheel untuk membangun PyInstaller. Tetapi dalam kasus PyInstaller, ini juga mendapatkan ini di setup.py :

# setup.py
from PyInstaller import __version__

Dari perspektif PEP 517, selain setuptools dan wheel , itu berarti perlu dibangun sendiri. Yang tentunya agak aneh.

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

Seperti yang disebutkan @cjerdonek di https://github.com/pypa/pip/issues/6175#issuecomment -456769285, dapatkah seseorang memeriksa apakah --no-use-pep517 memperbaiki ini untuk mereka?

Saya menduga penyebab masalah ini adalah isolasi build atau kode PEP 517 tidak memastikan bahwa root direktori paket ada di sys.path, karena pandas memiliki versioneer.py di sebelah setup.py. Saya ingat ini muncul di beberapa titik, tetapi saya tidak ingat di atas kepala saya apa diskusi itu. Ini mungkin dianggap sebagai masalah dengan build backend setuptools daripada pip, atau mungkin karena kesalahan mekanisme isolasi pip.

[...] dapatkah seseorang memeriksa apakah --no-use-pep517 memperbaiki ini untuk mereka?

PyInstaller dapat menginstal dengan --no-use-pep517 .

Oke, itu pasti masalah dengan kode PEP 517 baru dan saya cukup yakin masalahnya hanya direktori yang berisi root proyek belum ditambahkan ke sys.path . Mungkin @pfmoore akan memiliki pemahaman yang lebih baik tentang apakah itu adalah responsbility pip atau setuptools.

Jika itu membantu contoh lain dari ini (melalui apache-airflow adalah pip install pendulum==1.4.4 gagal, tetapi pip install --no-use-pep517 pendulum==1.4.4 berfungsi.

Jejak tumpukan yang kami dapatkan serupa:

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'

Juga penginstalan berikut ini juga tidak berfungsi dengan pip v 19.0 tetapi akan berfungsi jika menggunakan --no-use-pep5517:
pendulum == 1.5.0 (AttributeError: modul 'enum' tidak memiliki atribut 'IntFlag')
pendulum == 1.5.1 (AttributeError: modul 'enum' tidak memiliki atribut 'IntFlag')
pendulum == 2.0.0 (AttributeError: modul 'enum' tidak memiliki atribut 'IntFlag')
pendulum == 2.0.1 (AttributeError: modul 'enum' tidak memiliki atribut 'IntFlag')
pendulum == 2.0.2 (AttributeError: modul 'enum' tidak memiliki atribut 'IntFlag')

Sedangkan 2.0.3 dan 2.0.4 dapat diinstal dengan baik.

cartopy (Setidaknya rilis terbaru mereka) juga gagal dipasang sejak 19.0, gagal mengimpor versioneer.py di sebelah setup.py

Ini juga merupakan masalah dengan beberapa proyek yang saya tangani. Kami menggunakan pyproject.toml untuk menentukan parameter hitam python kami, dan melakukan serupa from project.version import __version__ di setup.py kami.

Setidaknya saya merasa tidak dapat mendefinisikan isolasi proyek di pyproject.toml akan cukup. Tampaknya tidak masuk akal bagi saya untuk membuat siapa pun yang ingin menginstal proyek menggunakan --no-buid-isolation atau --no-use-pep517

Kegagalan tampaknya terjadi di get_requires_for_build_wheel , dan backend setuptools menjalankan setup.py untuk melakukan semacam introspeksi guna menentukan persyaratan build (kode spesifik ada di sini ). Kode itu tampak aneh bagi saya, dan saya tidak mengerti mengapa itu diperlukan. Insting awal saya adalah bahwa ini adalah bug di backend setuptools yang harus ditangani oleh mereka.

PEP 517 tidak menyatakan bahwa frontend harus menjalankan hook di lingkungan yang menambahkan direktori build ke sys.path , dan ada potensi kekhawatiran bahwa jika kita melakukannya, itu dapat merusak isolasi (jika direktori build berisi salinan beberapa paket yang diperlukan tetapi tidak ditentukan, misalnya). Jadi preferensi saya adalah tidak menambahkan direktori build ke sys.path . Tetapi mungkin bijaksana untuk melakukannya jika itu menawarkan perbaikan cepat untuk regresi ini. Saya tidak berpikir proyek harus bergantung pada ini.

Ringkasan:

1. Ini harus dilaporkan ke setuptools untuk ditinjau sebagai masalah backend. Saya akan mempertimbangkan untuk memperbaikinya di backend setuptools (mungkin hanya dengan menambahkan direktori build ke sys.path ) sebagai resolusi yang ideal.
2. Jika setuptools tidak melakukannya, pip dapat menambahkan direktori build ke sys.path , tetapi menurut saya PEP 517 tidak menganggapnya sebagai tanggung jawab frontend ..
3. Membutuhkan direktori build agar dapat dilihat oleh hook pada sys.path memerlukan setidaknya klarifikasi PEP.

Saya rasa skenario ini tidak dipertimbangkan ketika PEP 517 sedang dikembangkan. Mungkin karena itu khusus setuptools (atau lebih tepatnya, khusus untuk backend yang menjalankan kode Python arbitrer sebagai bagian dari build).

Saya pikir itu cukup umum bagi orang untuk mengimpor sesuatu dari direktori saat ini ke setup.py , dan secara umum memperlakukan hal-hal seolah-olah setup.py ada di $PWD .

Saya pikir masuk akal untuk mendorong tanggung jawab ini ke setuptools , karena itu mungkin satu-satunya proyek yang benar-benar membutuhkannya.

Ya, memikirkan hal ini lagi, saya yakin ini adalah tanggung jawab backend setuptools. Sebelum PEP 517, pip menjalankan setup.py sebagai skrip, jadi aturan standar Python meletakkan direktori skrip ke sys.path . Di bawah PEP 517, pemanggilan setup.py diganti dengan panggilan ke kait backend, jadi kait tersebut perlu mempertahankan semantik. Karena setuptools menjalankan setup.py dalam proses dari hook, ia perlu mengatur sys.path itu sendiri. Mudah-mudahan, ini bukan perbaikan besar bagi mereka. @jeanlaroche (atau orang lain yang mengalami masalah ini) dapatkah Anda mengangkat masalah di pelacak setuptools, merujuk kembali ke utas ini?

[...] dapatkah seseorang memeriksa apakah --no-use-pep517 memperbaiki ini untuk mereka?

Saya dapat mengonfirmasi bahwa --no-use-pep517 memungkinkan pip install pandas berhasil.

Saya juga dapat mengonfirmasi bahwa menggunakan --no-use-pep517 berfungsi untuk semua paket saya yang rusak

sukses buat saya juga

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

Saya tidak berpikir ini adalah bug di pip / setuptools, dari pembacaan saya bagian Lingkungan Bangun PEP 517, tampaknya tidak ada tentang lingkungan yang harus diasumsikan kecuali bahwa ketergantungan yang dideklarasikan dalam pyproject.toml tersedia.

Juga bukankah mengimpor paket yang sedang diinstal dari setup.py adalah praktik yang buruk? Ada banyak cara yang lebih baik untuk mempertahankan versi paket di satu tempat, misalnya seperti yang dijelaskan dalam panduan pengemasan dari PyPA ini.

Dalam diskusi di pypa / setuptools # 1642, @uranusjr dan saya sama-sama berharap ini bisa menjadi kesempatan untuk membuat orang berhenti mengandalkan fakta bahwa . ada di sys.path saat Anda menjalankan python, dan mulai pindahkan orang ke semantik yang lebih eksplisit.

Masalah utama di sini adalah bahwa hanya dengan adanya pyproject.toml orang memilih PEP 518 dan PEP 517, jadi meskipun Anda belum menentukan build backend, Anda tiba-tiba mendapatkan semantik baru.

Apakah keputusan atas bagian pip tidak dapat diubah pada saat ini? Mungkin kami dapat memiliki kehadiran pyproject.toml mengikutsertakan Anda ke PEP 518, tetapi PEP 517 tidak terpicu kecuali Anda benar-benar menentukan build backend?

Sejujurnya, ini adalah situasi yang sulit di sekitar, tetapi saya pikir lebih mudah bagi pip untuk memperingatkan tentang hal ini daripada setuptools . Jika kami membuat PEP 517 ikut serta untuk saat ini dan mengatakan bahwa keberadaan pyproject.toml akan mulai memicu PEP 517 setelah 20.0 atau 21.0, kami dapat membuat panduan migrasi dan mulai mengeluarkan peringatan di pip untuk efek itu - " build-backend hilang dari pyproject.toml , perhatikan bahwa setelah versi 21.0, isolasi build akan secara default menggunakan setuptools.build_meta , lihat panduan migrasi di ..."

Juga bukankah mengimpor paket yang sedang diinstal dari setup.py adalah praktik yang buruk? Ada banyak cara yang lebih baik untuk mempertahankan versi paket di satu tempat, misalnya seperti yang dijelaskan dalam panduan pengemasan dari PyPA ini.

Agar adil, panduan itu mendefinisikan mengimpor paket yang diinstal dari setup.py sebagai strategi 6, jadi ini pasti agak umum. Pada titik ini, jika kita beralih dari strategi semacam itu, halaman tersebut harus diperbarui agar tidak menyertakannya lagi.

Keputusan untuk memicu PEP 517 atas keberadaan pyproject.toml adalah pilihan yang disengaja (pembahasannya mungkin tentang masalah implementasi PEP 517 atau PR, tetapi saya tidak punya waktu sekarang untuk menemukannya). Jelas itu bisa diubah dalam terang apa yang kita lihat di sini, tapi kita tidak boleh melakukannya tanpa mempertimbangkan alasan kita membuat keputusan yang kita lakukan.

Pip itu sendiri tidak (seharusnya, IMO) melihat apakah setup.py benar untuk menganggap bahwa direktori proyek ada di sys.path , jadi saya agak enggan untuk mengubah pip dengan mudah karena setuptools ingin memasukkan default yang berbeda saat backend digunakan. Meskipun saya setuju bahwa mengimpor proyek yang sedang dibangun di setup.py memiliki sejumlah kesulitan, itu tidak seperti itu sesuatu yang telah memicu peringatan hingga sekarang, jadi saya berasumsi bahwa backend harus mempertahankan semantik itu. Dengan kata lain, meskipun pip memang memperingatkan seperti yang Anda sarankan, mengapa pengguna membaca "isolasi build secara default menggunakan setuptools.build_meta " sebagai menyiratkan "Anda tidak akan dapat mengimpor proyek dari setup.py "? Kedua fakta itu tampaknya tidak ada hubungannya dengan saya ...

Secara pribadi, saya setuju dengan pendekatan saat ini yang mengandalkan keberadaan file pyproject.toml. Masalah IMO berasal dari orang-orang yang menggunakan pyproject.toml untuk hal-hal selain pengemasan. Oleh karena itu, jalan keluar yang benar adalah dengan mendorong alat non-pengemasan untuk menawarkan cara lain untuk konfigurasi, sehingga orang dapat memilih apakah akan menggunakan pyproject.toml atau tidak.

Pip itu sendiri tidak (seharusnya, IMO) melihat apakah setup.py benar menganggap bahwa direktori proyek ada di sys.path, jadi saya agak enggan untuk mengubah pip hanya karena setuptools ingin mendorong default yang berbeda saat backend digunakan.

Benar, hanya saja pip membuat asumsi bahwa pemanggilan hook setuptools.build_meta adalah dan seharusnya sama dengan memanggil setup.py . Kami telah melihat kasus di mana tidak, dan saya pikir masih harus ditetapkan apakah kami ( setuptools ) ingin kontrak setuptools.build_meta menjadi "ini setara dengan memanggil python setup.py "atau jika sebaliknya kita menginginkannya menjadi" ini adalah versi yang lebih terkunci dan terisolasi dari pemanggilan setup.py secara langsung ".

Tentu saja setuptools dapat mengatakan "itu bukan kontrak fungsi jadi kami tidak akan memperbaikinya" dan pip dapat mengatakan, "keputusan kami adalah defaultnya adalah PEP 517" dan kita berdua bisa mengatakan bug ada di proyek lain, tapi mungkin ide yang bagus untuk berkoordinasi.

Dengan kata lain, meskipun pip memang memperingatkan seperti yang Anda sarankan, mengapa pengguna membaca "isolasi build akan secara default menggunakan setuptools.build_meta" sebagai menyiratkan "Anda tidak akan dapat mengimpor proyek Anda dari setup.py"? Kedua fakta itu tampaknya tidak ada hubungannya dengan saya ...

Mereka mungkin terkait atau tidak, tetapi mungkin juga ada perubahan lain pada semantik. Inti dari peringatan seperti itu adalah mengatakan, "Harap jelaskan bagaimana Anda ingin build ini terjadi, karena kami akan segera mengikutsertakan Anda ke dalam sesuatu yang mungkin merusak build Anda." Proyek dapat menambahkan backend build ke pyproject.toml sebelumnya dan secara proaktif memperbaiki kerusakan yang mungkin terjadi.

Kita juga dapat membuat backend PEP 517 "dummy" di setuptools seperti setuptools.build_meta_legacy yang hanya chdir s ke dalam direktori root dan memanggil setuptools.build_meta , dengan cara itu orang dapat memilih perilaku lama hanya jika mereka membutuhkannya sebelum mulai rusak.

Secara pribadi, saya setuju dengan pendekatan saat ini yang mengandalkan keberadaan file pyproject.toml. Masalah IMO berasal dari orang-orang yang menggunakan pyproject.toml untuk hal-hal selain pengemasan.

Saya pikir kita perlu memisahkan PEP 517 dan PEP 518. PEP 518 secara eksplisit mencantumkan apa "nilai default" untuk PEP, sedangkan PEP 517 tidak menentukan apa pun tentang apa itu backend default.

Saya ingat saya tidak merasa sangat menolak seluruh "keberadaan pyproject.toml memilih Anda untuk membuat isolasi", tetapi melihatnya dalam praktiknya, saya juga tidak menyukai gagasan bahwa menentukan dependensi build yang terisolasi juga akan memilih saya masuk ke setuptools.build_meta .

Mungkin solusinya adalah membagi perbedaan dan memiliki backend default ke setuptools.build_meta_legacy yang tidak terdokumentasi (yang berusaha untuk mempertahankan semantik setup.py ). Dengan begitu, kita setidaknya akan memiliki cara untuk mengetahui apakah pengguna membuat pilihan afirmatif untuk menggunakan semantik baru atau jika mereka tidak memikirkannya.

A build_meta_legacy dengan pesan peringatan terdengar seperti solusi yang masuk akal bagi saya. Tampaknya lebih baik untuk membuat peringatan sangat menonjol (misalnya selama instalasi dan mendorong pengguna untuk melaporkan ini sebagai bug ke pengelola), dengan instruksi yang jelas bagaimana migrasi harus dilakukan.

Saya juga harus mencatat bahwa niat pip (itu adalah "perusahaan" pip ;-) - maksud saya adalah bahwa pip devs membahas ini sedikit dan mencapai kesepakatan umum yang kedengarannya seperti ide yang masuk akal, tetapi ini belum merupakan rencana yang pasti dan bergantung pada seseorang yang benar-benar menulis kode agar hal itu terjadi) adalah bahwa kami relatif cepat beralih untuk meneruskan semua proyek melalui PEP 517, dan menghapus jalur kode lama kami melalui setup.py seluruhnya. Membuat backend setuptools hanya di pip 21.0 (untuk menggunakan rilis yang disarankan dari atas) mendorongnya keluar setidaknya 2 tahun lagi.

sedangkan PEP 517 tidak menentukan apa pun tentang apa itu backend default

Benar. Tetapi pada titik tertentu, pip akan membatalkan dukungan kasus khusus dari setuptools. Itulah intinya (bagi kami, setidaknya) dari PEP 517, untuk memisahkan frontend dari backend, dan meletakkan semua backend pada pijakan yang sama. Jadi setiap kali kita melakukan itu, kita harus salah jika tidak ada backend, atau memilih default (dan kita akan menggunakan default setuptools, karena alasan lama). Perdebatan di sini adalah saat kita melakukan itu, bukan jika.

Pip saat ini memiliki 2 jalur kode untuk penginstalan - jalur PEP 517, dan jalur setup.py . Itu adalah sumber masalah pemeliharaan, dan potensi bug. Kami memilih untuk menjadikan PEP 517 sebagai default jika pyproject.toml hadir untuk memastikan penggunaan jalur PEP 517 (tidak mungkin proyek akan terburu-buru menambahkan build-backend = setuptools.buid_meta , jadi tanpa perilaku saat ini, kemungkinannya adalah pengujian kode PEP 517 pip, dan backend setuptools, akan tetap mendekati nol untuk periode yang diperpanjang). Ada pilihan keluar dalam bentuk --no-use-pep517 tepatnya untuk memenuhi kasus (yang dianggap jarang) di mana backend setuptools tidak sesuai.

Saya tidak berpikir ada yang mengantisipasi bahwa setuptools ingin memiliki perbedaan semantik antara setup.py dan backend, jadi kemungkinan --no-use-pep517 akan diperlukan untuk mengatasi perbedaan semantik begitu sering sehingga seharusnya begitu default bahkan tidak pernah dipertimbangkan.

Kita juga mungkin dapat membuat backend PEP 517 "dummy" di alat setup seperti setuptools.build_meta_legacy yang hanya memasukkan chdir ke direktori root dan memanggil setuptools.build_meta, dengan begitu orang dapat memilih ke perilaku lama hanya jika mereka membutuhkannya sebelum mulai rusak .

Itu mungkin solusi yang masuk akal. Tetapi itu setidaknya harus didokumentasikan sebagian - minimal, pip akan mendokumentasikan bahwa ini adalah nilai default yang akan kami asumsikan. Apakah setuptools memilih untuk membiarkan backend tidak terdokumentasi, saya kira adalah pilihan mereka.

Saya tidak yakin seberapa berguna diskusi teoretis lebih lanjut. Saya rasa saya tidak punya hal lain untuk ditambahkan, tentu saja. Saya menyarankan bahwa jika seseorang ingin meneruskan ini, cara terbaik adalah membuat PR mengalihkan default, dan diskusi tentang apakah kita ingin menerimanya dapat pindah ke sana.

Untuk pengelola paket yang ingin menyelesaikan masalah ini untuk pengguna Anda: Saya telah menerbitkan shim yang mengimplementasikan perbaikan sys.path .

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

Mudah-mudahan ini dapat berfungsi sebagai sementara sehingga kita dapat merenungkan bagaimana ini harus dipindahkan tanpa terburu-buru ke solusi, atau tidak perlu memperlambat adopsi pip 19.0 (yang berisi lebih banyak barang daripada hanya PEP 517).

Saya telah menerbitkan shim yang mengimplementasikan perbaikan sys.path.

Itu luar biasa! Terlepas dari perbaikan terakhir, ini adalah contoh yang sangat bagus dari fleksibilitas sistem hook PEP 517 :-)

Saya memperbaikinya dengan menurunkan versi pip saya di bawah 19.x kemudian saya mencoba menginstal dan berhasil

Ada kasus penggunaan ketiga: bagaimana dengan paket yang menyediakan backend build mereka sendiri? Misalnya: setuptools sendiri hanya mencantumkan wheel sebagai persyaratan build:

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

Ini tentu saja akan gagal jika kode pip untuk menangani PEP 517 tidak menambahkan direktori sumber ke sys.path .

Dari PEP 517:

Saat mengimpor jalur modul, kami tidak mencari di direktori yang berisi pohon sumber, kecuali jika itu tetap ada di sys.path (misalnya karena ditentukan dalam PYTHONPATH). Meskipun Python secara otomatis menambahkan direktori kerja ke sys.path dalam beberapa situasi, kode untuk menyelesaikan backend tidak boleh terpengaruh oleh ini.

Itu cukup jelas (bagi saya) mengatakan bahwa proyek seharusnya tidak berharap untuk dapat melihat direktori proyek mereka sendiri ketika menyelesaikan build-backend - jadi setuptools perlu menambahkan dirinya sendiri ke requires IMO. Dan ya, saya mengerti bahwa melakukan itu melingkar. Tetapi membangun backend yang membangun dirinya sendiri pada dasarnya cukup melingkar - ini jelas bukan kasus normal.

Bagian yang sama menurut saya juga mengonfirmasi bahwa alat build seharusnya tidak mengharapkan direktori proyek berada di lingkungan build sys.path .

Bagaimana itu akan berhasil dengan --no-binary :all: ?

@pfmoore Varian dari situasi ini adalah bahwa paket menyediakan sistem build kustom. Sistem build tidak diinstal (dan bukan bagian dari bdist), tetapi disertakan dengan sdist, mungkin untuk menyesuaikan beberapa proses build. Apakah ini kasus penggunaan yang valid, atau haruskah pengelola menerbitkan sistem build kustom sebagai paket terpisah?

Edit: Sesuatu seperti

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"]

Mungkin solusinya adalah menambahkan konfigurasi opsional baru, untuk menunjukkan di mana menemukan modul selama pembuatan?

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

Konfigurasi default ke [] (daftar kosong), yang berarti tidak ada jalur yang ditambahkan (yaitu sama dengan perilaku saat ini), tetapi proyek dapat menambahkan jalur untuk menemukan sistem build secara lokal.

Jika build-system dihilangkan seluruhnya, bagian defaultnya adalah:

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

pip dapat menampilkan pesan peringatan / info untuk memberi tahu pengguna untuk bermigrasi (kemungkinan besar dengan link ke halaman dokumentasi).

Manfaat tambahan dari solusi ini adalah bahwa semuanya dapat dilakukan dalam pip (sebenarnya modul pep517 vendor). Tidak ada yang perlu diubah di setuptools atau project rusak yang sudah ada.

Varian dari situasi tersebut adalah bahwa sebuah paket menyediakan sistem build kustom.

Sejujurnya saya tidak tahu. Ini bukan situasi yang saya pikirkan tentang diri saya sendiri. Saya tidak tahu apakah penulis PEP mempertimbangkannya - saya tidak ingat diskusi apa pun tentang masalah tersebut saat PEP dikembangkan.

Sebenarnya, setelah dicentang, PEP 517 secara eksplisit mengatakan (di bagian build-backend ) "Saat mengimpor jalur modul, kami tidak mencari di direktori yang berisi pohon sumber, kecuali jika itu ada di sys.path "yang menyiratkan kepada saya bahwa secara eksplisit tidak disarankan untuk memiliki backend dalam pohon. Apakah seseorang bisa mengatasi ini dengan kode yang cukup licik, saya tidak yakin (tapi saya kira tidak).

Kasus penggunaan yang diharapkan ketika kami mengembangkan PEP 517 adalah bahwa backend akan dikirim sebagai roda di PyPI (atau indeks khusus) yang akan diunduh dan dipasang ke lingkungan build. Bagaimana backend dibangun secara eksplisit di luar ruang lingkup - anggapan pribadi saya adalah bahwa mereka tidak akan menggunakan mekanisme PEP 517, melainkan akan menggunakan perintah tingkat yang lebih rendah ( setup.py bdist_wheel atau flit build , misalnya ). Menggunakan backend PEP 517 secara rekursif untuk membangun dirinya sendiri tampak seperti langkah yang terlalu jauh dalam kompleksitas. Itu dianggap sebagai bagian dari implementasi PEP 518 di pip (ada potensi eksploitasi bom garpu jika backend dikirim sebagai sdist, dan menggunakan dirinya sendiri untuk membangunnya sendiri, yang harus kami cegah bahkan sebelum kami dapat mendukung backend yang tidak didistribusikan sebagai roda ) tetapi hanya dalam konteks mengunduh backend dari PyPI.

tl; dr; Yang bisa saya tawarkan hanyalah ingatan saya tentang diskusi pada saat itu - Anda mungkin lebih baik mencari arsip untuk latar belakang sebenarnya.

Saya tidak tahu apakah penulis PEP mempertimbangkannya - saya tidak ingat diskusi apa pun tentang masalah tersebut saat PEP dikembangkan.

Saya baru saja mulai melihat arsipnya, dan tampaknya pertanyaan ini memang dibahas secara mendetail menjelang akhir proses (atau setidaknya sampai ke dalamnya). Saya tidak tahu situs web mana yang terbaik untuk melihat arsip, tetapi inilah satu poin di mana diskusi mulai membicarakan pertanyaan ini lagi (28 Juli 2017):
https://mail.python.org/pipermail/distutils-sig/2017-July/031109.html
https://www.mail-archive.com/[email protected]/msg26624.html

Misalnya, email khusus ini diakhiri dengan--

Mengingat seberapa banyak masalah yang kita hadapi dengan PEP 517, mungkin lebih masuk akal untuk memiliki PEP 517 hanya mengamanatkan bahwa direktori tersebut tidak berada di sys.path, dan membuat PEP sedikit tindak lanjut hanya untuk python-path.

Saya akan memberi tahu Anda jika saya menemukan apa keputusan akhirnya, tetapi saya mendorong orang lain untuk membaca sendiri.

Bagus! Terima kasih telah menemukannya :-)

Jadi saya membaca sekilas banyak email, dan saya pikir Anda setidaknya dapat melewati 29 Agustus, di mana Nick sepertinya menyarankan ada konsensus untuk meninggalkan direktori sumber _out_ dari sys.path:
https://mail.python.org/pipermail/distutils-sig/2017-August/031413.html
(Satu demi satu, orang-orang menjadi yakin akan argumen Nathaniel.)

Namun, dalam email yang sama yang ditautkan di atas, Nick memang mengatakan hal berikut :)

1. Jika menghilangkannya memang suatu masalah, kami mungkin akan segera mengetahuinya sebagai bagian dari penerapan setup.py backend

Berikut adalah paragraf yang lebih lengkap dari email tersebut:

Jadi saya pikir kita dapat menganggap ini diselesaikan dengan mendukung "Frontends harus memastikan direktori saat ini TIDAK pada sys.path sebelum mengimpor backend yang ditunjuk", karena memulai dari sana berarti kita memaksimalkan peluang kita untuk mempelajari sesuatu yang baru sebagai bagian dari peluncuran API yang diterima sementara.

Saya belum tahu apakah ada email kemudian yang mengubah ringkasan ini, tetapi tidak ada banyak email tentang topik tersebut setelahnya.

Terima kasih telah menjaring arsip untuk kami @cjerdonek. Menyatakan pemahaman saya saat ini tentang masalah:

1. banyak file setup.py dunia nyata saat ini menganggap direktori saat ini ada di sys.path ketika dijalankan, menciptakan masalah bootstrap yang aneh karena proyek memperlakukan dirinya sendiri sebagai ketergantungan waktu penginstalan
2. PEP 517 secara eksplisit mengatakan bahwa front end build tidak boleh secara implisit menambahkan direktori saat ini ke sys.path (tidak mengatakan apa pun tentang backend)
3. pip 19.0 menganggap pyproject.toml tanpa bagian build-system sama dengan bagian build-system yang menentukan backend setuptools
4. backend setuptools PEP 517 saat ini tidak menambahkan direktori saat ini ke sys.path baik (karena keluar dari poin 1 di atas dianggap sebagai tujuan masa depan yang diinginkan)
5. Dua solusi sementara tersedia untuk proyek yang ada sementara perilaku default ditingkatkan: menyematkan pip menjadi kurang dari 19.0, dan secara eksplisit menyetel opsi --no-use-pep517 . Namun, orang-orang hanya menemukannya setelah pertama kali mengetahui bahwa mengupgrade pip merusak build mereka.

Dari perspektif fungsional, saya pikir perubahan utama yang ingin kami perkenalkan adalah bahwa dalam kasus " pyproject.toml tanpa build-system section", maka direktori yang berisi setup.py harus berakhir di sys.path lagi. Ada dua cara utama untuk mengatasinya:

1. Dapatkan pip untuk melakukannya. Ini memiliki efek samping yang tidak menguntungkan karena membuat perilaku front-end tergantung, dan dengan demikian berpotensi melihat proyek yang ada gagal dipasang kecuali semua frontend menerapkan solusi yang sama
2. Dapatkan backend setuptools PEP 517 untuk melakukannya, dengan memeriksa pyproject.toml untuk bagian build-system , dan memasukkan direktori setup.py ke sys.path jika entri bagian dan jalur hilang. pip masih diperlukan dalam situasi itu, karena ia harus menentukan versi minimum dari alat-alat setup yang menangani kasus "no build-system section" dengan benar.

Untuk membuat segala sesuatunya berfungsi untuk pengguna akhir secepat mungkin, tanpa mengecat diri sendiri ke sudut desain yang tidak menguntungkan, saya sebenarnya akan mengusulkan resolusi 3 langkah:

1. Lakukan rilis pip (19.0.1?) Sekarang yang menambahkan entri sys.path ekstra untuk kasus "no build-system entry". Pada titik ini, masalah kompatibilitas sebagian besar akan hilang untuk pengguna akhir.
2. Lakukan rilis setuptools yang menangani penambahan sys.path jika front end belum melakukannya.
3. Dalam rilis pip , ubah case "no build-system entry" untuk melepaskan casing khusus, dan sebagai gantinya setel versi minimum yang lebih ketat untuk setuptools .

Proposal ini didasarkan pada fakta bahwa menurut saya backend setuptools PEP 517 adalah tempat yang "tepat" untuk menangani masalah kompatibilitas mundur setup.py , tetapi saya juga berpikir bahwa mengubah pip secara langsung cenderung menjadi perubahan yang jauh lebih sederhana dalam waktu dekat, dan ini adalah perubahan yang akan mengandung masalah sementara perbaikan yang lebih disukai secara arsitektural sedang dikerjakan.

Saya telah membuat backend build_meta_legacy di pypa / setuptools # 1652. Saya benar-benar lebih suka jika pip akan beralih menggunakan setuptools.build_meta_legacy sebagai backend default, tapi menurut saya membuat backend "legacy shim" bawaan adalah sejauh yang saya mau di setuptools . Saya tidak ingin terjebak dalam waktu yang tidak terbatas dengan mendukung " python setup.py install emulasi" penuh di backend utama setuptools PEP 517.

Saya sedikit bingung mengapa setuptools tidak ingin meniru menjalankan skrip secara native di sini TBH. Sepertinya meminta pengguna akhir menjadi bingung ketika python setup.py bdist_wheel berfungsi dengan benar, tetapi pip wheel tidak (dengan asumsi mereka telah menyetel ke build backend non legacy).

Apa alasannya?

Apa alasannya?

Rencana jangka panjang saya adalah menghentikan semua pemanggilan langsung setup.py mendukung pemanggilan tidak langsung oleh frontend PEP 517 atau yang setara (untuk perintah lain). Jika kita pindah ke dunia "semua lingkungan terisolasi", saya tidak ingin dipaksa untuk menjaga semantik setuptools pemanggilan perintah kompatibel dengan pemanggilan python setup.py , untuk alasan yang sama PEP 517 secara khusus mengatakan bahwa frontend tidak boleh melakukan ini - ini berpotensi untuk merusak isolasi build dan umumnya menciptakan situasi yang tidak diinginkan.

Saya pikir ini cukup jarang dibutuhkan kecuali sebagai bagian dari anti-pola. Siapapun dengan kebutuhan yang sah untuk itu dapat dengan mudah memanipulasi sys.path dalam skrip pengaturan mereka.

Sekadar catatan, saya rasa PEP 517 tidak pernah memiliki tujuan desain bahwa semua akses alat build dapat dilakukan melalui hook. Misalnya, flit memiliki kumpulan perintahnya sendiri flit build dll, dan tidak ada niat yang saya sadari untuk membatalkannya. Jadi mungkin saja Anda dapat menemukan kasus-kasus edge di mana maksud di balik PEP 517 adalah bahwa perintah khusus alat perlu digunakan. Contoh yang jelas adalah membangun backend itu sendiri (seperti yang saya sebutkan di atas), tetapi kasus lain (saat ini tidak terstandarisasi, meskipun PEP di masa mendatang dapat menambahkan pengait) seperti pemasangan yang dapat diedit dan build di tempat (menggunakan kembali artefak dari build sebelumnya) ada.

Mendapatkan persetujuan bahwa semua alat dapat mendukung "build sdist" dan "build wheel" sudah cukup sulit sehingga saya tidak mengantisipasi penambahan daftar operasi standar lebih jauh akan segera terjadi.

Sekadar catatan, saya rasa PEP 517 tidak pernah memiliki tujuan desain bahwa semua akses alat build dapat dilakukan melalui hook.

Ini bukan yang saya sarankan, dan ini sedikit penyimpangan. Maksud saya adalah bahwa masalah yang membutuhkan PEP 518 juga ada secara lebih umum untuk semua perintah setup.py , dan itu paling baik diselesaikan dengan menjauhkan orang dari pemanggilan setup.py sama sekali . Tidak ada standar yang diperlukan untuk melakukan ini dengan cara yang sama flit tidak membutuhkan PEP untuk menambahkan subperintah.

Ah, oke. Maaf atas kesalahpahaman.

Transisi yang diusulkan

Terima kasih telah menggali arsip @cjerdonek!

Mengingat bahwa sudah ada PR yang memperbaikinya di setuptools (melalui pengenalan backend lama). Apakah ada alasan untuk tidak melewati langkah 1 di atas? Kami menginstal setuptools ke dalam lingkungan build yang terisolasi, jadi bergantung pada versi terbaru seharusnya tidak menjadi masalah.

Apakah ada alasan untuk tidak melewati langkah 1 di atas?

Nggak. Kami dapat langsung menabrak versi minimum yang dibutuhkan saat ini.

Rencana transisi saya didasarkan pada asumsi bahwa orang-orang akan membutuhkan lebih banyak waktu untuk mengerjakan mekanisme transisi berumur panjang di sisi setuptools -sementara backend transisi khusus @pganssle tampak menjanjikan di bagian depan itu, saya tidak yakin tidak masuk akal untuk membiarkan status quo di tempat saat perubahan tersebut sedang ditinjau.

Karena itu, saya tidak mengetahui detail tentang cara kerja implementasi PEP 517 di pip , jadi asumsi saya bahwa menangani masalah di front end mungkin tidak benar.

Karena backend dijalankan dalam subproses (dan pada kenyataannya, menggunakan proyek pep517 vendor, yang menambahkan tingkat tipuan ekstra) sama sekali tidak jelas bagi saya bagaimana kami menetapkan sys.path untuk pengait backend. Minimal kita perlu melibatkan PYTHONPATH yang berarti mengkhawatirkan kasus-kasus di mana pengguna sudah memiliki set PYTHONPATH , dan bagaimana kode isolasi menggunakannya.

Pada dasarnya, menetapkan sys.path dalam pip, saya kira, jelas tidak sepele. Saya tidak mungkin punya waktu untuk melihat detailnya, apalagi menulis tambalan (dan memastikan itu diuji dengan benar!) Sendiri.

Saya pikir mendapatkan backend setuptools tetap adalah cara tercepat untuk maju.

Rencana jangka panjang saya adalah menghentikan semua pemanggilan langsung setup.py yang mendukung pemanggilan tidak langsung baik oleh frontend PEP 517 atau yang setara (untuk perintah lain).

@pgansle aduh. Prosedural setup.py harus mati. Seharusnya tidak ada untuk alasan apapun. Karena "fleksibilitas" ini adalah sumber rasa sakit dan kerusakan yang tak ada habisnya. Tidak mungkin untuk memigrasi setup.py dan karenanya semua masalah dengan pengemasan Python.

Saya akan mengganti setup.py dengan package.json dan hanya menambahkan bagian Python untuk itu alih-alih format deskripsi paket lain.

Setidaknya saya dapat menggunakan penentu versi ==1.x .

@techik Harap pergi. Kontribusi non-konstruktif Anda tetap tidak diinginkan dalam proyek apa pun yang saya ikuti.

Bekerja pada # 6210 telah memungkinkan saya menjawab pertanyaan saya sendiri dari atas tentang betapa sulitnya menangani ini pada level pip : tantangannya adalah informasi tentang apakah direktori sumber harus dimasukkan sebagai sys.path[0] perlu disalin dari kode yang membaca pyproject.toml hingga ke pemanggil hook PEP 517, dan kemudian dari sana ke dalam skrip pembungkus dalam proses yang sebenarnya.

Itu bisa dilakukan tanpa perubahan arsitektural besar (prefiks pip._implicit. pada nama backend build untuk bagian pertama, dan PEP517_SYS_PATH_0 env var untuk yang terakhir), tetapi itu berarti memodifikasi sementara pep517 vendor setuptools siap.

Rencana transisi saya didasarkan pada asumsi bahwa orang-orang akan membutuhkan lebih banyak waktu untuk mengerjakan mekanisme transisi berumur panjang di sisi setuptools -sementara backend transisi khusus @pganssle terlihat menjanjikan di bagian depan itu, saya tidak yakin itu masuk akal untuk membiarkan status quo di tempatnya sementara perubahan itu sedang ditinjau.

Ya, saya setuju dengan ini. Saya menyarankan ini saja di postingan distutils, ada dua hal yang menurut saya penting:

1. Mendapatkan solusi untuk pengguna secepatnya
2. Mempersiapkan transisi yang tepat .

Saya pribadi berpikir bahwa hal yang benar untuk dilakukan adalah menghapus "keberadaan pyproject.toml memilih Anda untuk masuk ke logika PEP 517" sampai kita memiliki logika transisi pada tempatnya. Mempertimbangkan bahwa perubahan pada setuptools memiliki konsekuensi untuk API yang dihadapi publik dan pada pip itu hanya akan menunda apa yang ternyata merupakan perubahan yang tidak kompatibel ke belakang, masuk akal bagi saya untuk lakukan perbaikan cepat di pip sementara kami meninjau langkah selanjutnya untuk setuptools .

Dengan kedua pendekatan yang beroperasi pada mesin lokal saya, saya menguji # 6210 dan # 6212 terhadap persyaratan asli PyInstaller==3.4 bermasalah.

• # 6210 bekerja sesuai keinginan: https://github.com/pypa/pip/pull/6210#issuecomment -458144828
• # 6212 tidak berperilaku seperti yang diharapkan: https://github.com/pypa/pip/pull/6212#issuecomment -458148519

Saya tidak tahu apakah kegagalan # 6212 adalah masalah pengaturan pengujian, atau jika sebenarnya ada masalah lebih lanjut di pra-rilis setuptools, saya hanya tahu bahwa ada pekerjaan integrasi lebih lanjut yang harus dilakukan sebelum kita dapat yakin dengan solusi itu, sedangkan saya yakin dengan # 6210 sekarang - satu-satunya hal yang salah adalah bahwa ini adalah peretasan kompatibilitas yang mengerikan sehingga kami tidak ingin pip harus dibawa selamanya.

Sepertinya --no-cache bertanggung jawab atas kegagalan assert pada # 6212. Menguji dengan --cache-dir malah memberikan pengujian lokal yang berhasil: https://github.com/pypa/pip/pull/6212#issuecomment -458166386

(Saya akan offline selama ~ 18 jam untuk tidur & bekerja, jadi orang-orang boleh bebas menjalankan # 6210 atau # 6212 mana saja yang masuk akal untuk sementara waktu)

Saya telah memperbarui judul agar lebih mencerminkan situasi. Terima kasih @ncoghlan untuk PR-nya!

Catatan moderasi: Saya juga telah menyembunyikan komentar non-produktif (dan tanggapannya) sebagai "Topik Tidak Aktif", dan akan melakukannya untuk komentar selanjutnya yang serupa dengan baris tersebut. Jika ada yang ingin berdiskusi tentang moderasi, ajukan masalah baru atau ping saya melalui email; utas ini bukan tempat yang tepat untuk mengemukakan masalah apa pun dengan moderasi yang mungkin Anda miliki.

Saya juga melanjutkan dan menyematkan ini, untuk menghindari orang membuat duplikat dan untuk dengan jelas memberi sinyal bahwa kita tahu tentang ini.

Bahkan jika kita membuat pep517 opt-in, ini adalah perubahan perilaku yang tidak diumumkan dan oleh karena itu akan merusak perpustakaan _bahkan jika mereka sudah memilih in_ (lihat PyInstaller , misalnya). Dalam kasus di mana pustaka mendeklarasikan keikutsertaan untuk pep517 membangun _and_ mengimpor hal-hal secara lokal yang diharapkan ditemukan di sys.path , tidak ada asumsi yang dibuat oleh pip (karena pustaka tersebut eksplisit) tetapi pustaka itu masih tiba-tiba rusak.

Dalam hal ini saya benar-benar tidak melihat alternatif selain hanya memasukkan cwd di setuptools, karena ini baru saja rusak. Kecuali jika proposalnya adalah untuk memberi tahu orang-orang untuk kembali dan memperbaiki rilis yang telah mereka potong di antara pep517 dan pip 19, yang, jika ada pengguna yang memasang pin dengan ketat, mungkin tiba-tiba berhenti dapat diinstal, saya benar-benar merasa kita harus mempertimbangkan dampaknya keputusan ini tentang pengalaman pengguna. Berdasarkan diskusi ini dan proposal saat ini, beberapa pustaka ini tidak akan dapat diinstal dengan versi baru pip + setuptools ke depannya menggunakan default kecuali build pep517 secara eksplisit dinonaktifkan.

Ini cukup berdampak jika Anda hanya mencoba menginstal paket dengan perkakas yang disediakan untuk Anda oleh python, tetapi sebenarnya tidak dapat menginstal sesuatu secara acak. Saya mengatakan ini untuk menarik fokus dari aspek teknis sejenak dan ke dampak ke pengguna akhir yang mungkin merasa frustrasi dengan perkakas, ekosistem, perpustakaan, atau bahasa itu sendiri, karena tiba-tiba (dan ya, hanya di bawah keadaan tertentu), hal-hal yang dapat mereka instal dengan baik sekarang tidak dapat diinstal. Saya benar-benar berpikir kita harus menutup celah ini dalam solusi apa pun yang diterapkan.

Saat ini kami menggunakan tumpukan kegagalan untuk menangani instalasi yang gagal di pipenv dan saya menambahkan --no-use-pep517 bila tersedia untuk menangani kegagalan sebagai akibat dari perubahan ini. Saya tidak yakin itu akan intuitif bagi pengguna rata-rata, karena mungkin bahkan tidak segera jelas apa penyebab masalahnya. Saya mengatakan ini hanya untuk menunjukkan bahwa kami memiliki solusi, tetapi rasanya penting untuk mencoba dan menutup celah ini untuk membantu pengguna sedikit tentang masalah ini.

(edit: juga terima kasih banyak kepada pganssle, cjerdonek, pfmoore, pradyunsg, ncoghlan, dan semua orang yang telah meluangkan banyak waktu dan upaya untuk ini)

Kasus penggunaan yang diharapkan ketika kami mengembangkan PEP 517 adalah bahwa backend akan dikirim sebagai roda di PyPI (atau indeks khusus) yang akan diunduh dan dipasang ke lingkungan build. Bagaimana backend dibangun secara eksplisit di luar ruang lingkup - anggapan pribadi saya adalah bahwa mereka tidak akan menggunakan mekanisme PEP 517, melainkan akan menggunakan perintah tingkat yang lebih rendah (setup.py bdist_wheel atau flit build, misalnya). Menggunakan backend PEP 517 secara rekursif untuk membangun dirinya sendiri tampak seperti langkah yang terlalu jauh dalam kompleksitas. Itu dianggap sebagai bagian dari implementasi PEP 518 di pip (ada potensi eksploitasi bom garpu jika backend dikirim sebagai sdist, dan menggunakan dirinya sendiri untuk membangunnya sendiri, yang harus kami cegah bahkan sebelum kami dapat mendukung backend yang tidak didistribusikan sebagai roda ) tetapi hanya dalam konteks mengunduh backend dari PyPI.

Hanya untuk mengulang kembali ini - setuptools.build_meta_legacy default baru memecahkan masalah untuk menggunakan PEP 517 untuk semuanya kecuali backend PEP 517, yang merupakan masalah untuk setuptools itu sendiri. Jika kita tidak menyelesaikannya, maka seperti yang ditunjukkan @ benoit-pierre di pypa / setuptools # 1644, tidak mungkin orang menggunakan pip install --no-binary :all: untuk proyek apa pun yang bergantung pada setuptools (atau mungkin setiap PEP 517 penyedia backend).

Haruskah kita membahasnya di utas ini, atau membuat utas baru untuk membahasnya?

Haruskah kita membahasnya di utas ini, atau membuat utas baru untuk membahasnya?

Saya akan membagi itu. Perasaan langsung saya adalah bahwa masalahnya adalah bahwa --no-binary :all: memiliki konsekuensi signifikan yang tidak diinginkan di sini (serupa dalam praktiknya dengan dampak menggunakan bendera itu di hadapan proyek yang hanya mendistribusikan roda, bukan sdists) dan saya suka untuk menghindari penyimpangan ke (misalnya) kelayakan menggunakan --no-binary :all: semakin mengganggu utas ini.

Saya tidak berpikir bahwa memperbaiki masalah dengan backend bangunan --no-binary :all: hampir sama pentingnya dengan masalah ini. Jika pengguna telah menentukan --no-binary :all: , mereka dapat dengan mudah menambahkan --no-use-pep517 .

PR baru # 6229 yang:

1. Menerapkan solusi sementara yang disarankan @pganssle untuk membuat bagian build-system di pyproject.toml persyaratan awal untuk secara otomatis ikut serta ke PEP 517 (menangguhkan "semua pyproject.toml file" opt- untuk rilis selanjutnya)
2. Menambahkan 3 kasus uji khusus yang mencakup pengimporan paket yang berdekatan dari setup.py

Saya akan menutup 2 PR lainnya untuk mendukung yang satu itu, karena ini adalah perbaikan minimal yang akan membuat semuanya berfungsi kembali untuk pengguna akhir, dan tidak memerlukan peretasan yang mengerikan seperti # 6210 atau rilis alat penyiapan baru seperti # 6212

Jadi, di mana tersisa setuptools.build_meta_legacy ? Apakah proposal sekarang memerlukan proyek yang memerlukan fungsionalitas "impor paket yang berdekatan" untuk menentukannya secara eksplisit di pyproject.toml ? Jika demikian, saya sangat menyarankan bahwa perlu didokumentasikan di suatu tempat, bersama dengan fakta bahwa mengimpor paket yang berdekatan tanpa spesifikasi itu tidak berlaku lagi dan akan dihapus dalam pip 19.X (kami perlu menyetujui apa itu X), Kami tidak dapat membuatnya penghentian terprogram (menurut saya), tetapi itulah alasan lainnya untuk mendokumentasikannya dengan jelas, jadi kami tidak dituduh (lagi) menghapus fungsionalitas tanpa pemberitahuan yang memadai.

Edit: Tapi sebaliknya, terima kasih untuk PR baru dan ringkasannya.

Sunting 2: Saya melihat Anda menutup proposal setuptools.build_meta_legacy . Saya tidak yakin saya menyukainya, karena hal itu membuat kita kehilangan kesempatan untuk mengatakan sekarang apa rencana jangka panjang kita, jadi perpanjang periode deprecation apa pun, seperti yang saya sebutkan di atas ...

@pfmoore Tidak, itu berarti bahwa kembali ke perilaku yang diinginkan harus dicakup oleh masalah baru yang terkait dengan penghapusan solusi # 6163 (mungkin dengan memperbarui ke setuptools yang menyediakan setuptools.build_meta_legacy ).

Sunting: untuk saat ini saya baru saja membuka kembali # 6212, tetapi memberi judul ulang untuk memperjelas bahwa saya rasa kita tidak harus menunggu seluruh diskusi build_meta_legacy diselesaikan sebelum memperbaiki perintah pemasangan yang saat ini gagal.

Proposal saya sebenarnya bahwa keikutsertaan untuk PEP 517 menetapkan build-system.build-backend bukan keberadaan build-system sama sekali, dan antara sekarang dan rilis 19.1, setuptools akan ditambahkan build_meta_legacy dan pip akan menggunakannya sebagai backend default.

Saya setuju bahwa di 19.1, mungkin jika pip tidak dapat menemukan setuptools.build_meta_legacy , itu harus kembali ke jalur kode lama. Itu akan memberi kita sedikit perubahan yang melanggar sementara memilih dalam jumlah maksimum orang.

Proposal saya sebenarnya adalah bahwa keikutsertaan untuk PEP 517 menentukan build-system.build-backend

... yang bisa ditangani hanya dengan menyetel use_pep517 = False dalam kasus fallback (daripada menyetelnya ke has_pyproject yang kita lakukan sekarang.

di 19.1, mungkin jika pip tidak dapat menemukan setuptools.build_meta_legacy, itu harus kembali ke jalur kode lama

Saya tidak berpikir ini layak dilakukan. Kami akan menentukan versi setuptools yang cukup baru sehingga kami yakin akan mendapatkan backend lawas, dan tidak perlu memenuhi kemungkinan setuptools menghapus backend itu di versi yang akan datang (atau lebih tepatnya, jika ya, kita cukup salahkan mereka atas masalah yang ditimbulkan ;-))

Catatan: use_pep517 = False default adalah awal dari # 6229, tetapi menyebabkan kegagalan dalam tes PEP 518.

1. The " build-system.requires diatur" kasus harus menggunakan membangun isolasi, sehingga dapat menginstal dependensi yang diminta tanpa mempengaruhi lingkungan induk. Cara termudah untuk melakukannya mengingat struktur kode saat ini adalah dengan menetapkan use_pep517 = True dalam kasus ini, jadi saya melakukannya, dan kasus uji lulus lagi.
2. Sebuah hilang [build-system] tabel menunjukkan pyproject.toml hanya digunakan untuk menyimpan pengaturan dalam [tools] tabel, sehingga harus menghasilkan use_pep517 = False menjadi solusi efektif untuk masalah yang dilaporkan semula, jadi saya menandai kasus uji ini sebagai kegagalan yang diharapkan.
3. Itu menyisakan kasus "kosong [build-system] tabel", yang menurut saya dapat diselesaikan secara wajar di kedua arah. Namun, karena menurut saya kasus khusus ini tidak akan sering muncul dalam praktik (mengapa ada orang yang bersusah payah menambahkan tabel build-system tanpa menyetel requires atau build-backend ?), Saya memilih untuk menyelesaikannya dengan cara yang berarti kasus uji PEP 518 yang ditentukan sebelumnya lulus, daripada menambahkan penanda kegagalan yang diharapkan kedua.

Untuk menyelesaikan 3 ke arah lain, kita perlu mengubah baris:

use_pep517 = build_system is not None

sebagai gantinya menjadi:

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

Dengan cara itu, hanya memerlukan yang tidak kosong yang akan ikut serta ke isolasi build PEP 517 (yang juga berarti menambahkan kasus pengujian ke-4, karena kolom build-system.requires kosong dan tidak kosong sekarang akan berperilaku berbeda).

Maaf atas kontribusi tak diundang di sini, tetapi saya tidak bisa tidak memperhatikan bahwa ini semua terasa seperti cara yang cukup rumit untuk menghindari cwd pada sys.path dan pada akhirnya akan meninggalkan hal-hal rusak yang dulu berfungsi, yang terasa cukup mengganggu dari perspektif UX.

Sejumlah besar pengguna dan paket terpengaruh oleh hal ini. Setidaknya beberapa dari mereka memiliki bagian [build-system] ditentukan dan _also_ bergantung pada perilaku lama, dan oleh karena itu akan tetap rusak bagi siapa saja yang memiliki versi yang disematkan.

@techalchemy Ya, asumsi asli di pip adalah bahwa setuptools.build_meta bekerja dengan cara yang sama dari perspektif sys.path bahwa pemanggilan langsung setup.py tidak, dan asumsi itu terbukti tidak benar. Setelah rilis setuptools berisi backend setuptools.build_meta_legacy ditentukan di https://github.com/pypa/setuptools/pull/1652 tersedia maka # 6212 dapat diselesaikan, dan itu akan menjadi waktu yang lama. resolusi jangka. Namun, saat ini tidak ada ETA untuk rilis semacam itu, jadi kami perlu terus menjelajahi resolusi pip -hanya untuk mendapatkan direktori sumber kembali pada sys.path untuk paket yang tidak secara eksplisit "PEP 517 asli ".

Di # 6229 saya mengimplementasikan saran @pganssle dengan hanya menunda adopsi "PEP 517 secara default", tetapi sepertinya itu menyebabkan lebih banyak masalah daripada yang dapat dipecahkan karena perubahan lain di pip 19: pemrosesan build-system.requires sekarang terkait dengan pemrosesan build-system.build-backend , jadi --no-use-pep517 menonaktifkan PEP 518 (yang menyebabkan kegagalan rangkaian pengujian, dan juga dapat menyebabkan kegagalan penginstalan di dunia nyata jika membangun dependensi tidak diinstal sebelumnya).

Di # 6210, saya malah secara lokal menambal pep517 untuk mendukung penyuntikan sys.path[0] ke dalam subproses, secara efektif melakukan hal yang sama dengan yang diharapkan setuptools.build_meta_legacy di masa depan setutpools rilis. Ini tampaknya berperilaku seperti yang kita inginkan - build-system.requires masih diproses, dan direktori sumber adalah sys.path[0] ketika setup.py dieksekusi. Ini juga sangat mirip dengan apa yang saya usulkan di https://discuss.python.org/t/pep-517-backend-bootstrapping/789/29?u=ncoghlan dan @takluyver telah menyusun di https://github.com/ pypa / pep517 / pull / 42 / untuk menangani backend self-bootstrap dengan cara yang kompatibel dengan --no-binary :all:

Maaf telah menjadi AWOL RM. Hal-hal terjadi yang tidak saya antisipasi.

Saya jelas lebih suka perbaikan sisi setuptools untuk ini tetapi # 6210 keren bagi saya juga - sebagai perbaikan jangka pendek.

Saya setuju dengan @techalchemy dan @pradyunsg - saya pikir perbaikan sisi setuptools adalah pendekatan yang benar di sini. Meskipun saya menghargai usaha untuk mencoba menemukan perbaikan cepat dalam pip, bukankah waktu seperti itu lebih baik dihabiskan untuk mempercepat rilis baru setuptools dengan _build_meta_legacy ? Saya belum melihat apa yang terjadi di setuptools, jadi saya sama sekali tidak mengerti mengapa ada masalah dengan merilis perbaikan cepat di setuptools (siklus rilis setuptools jauh lebih cepat daripada pip).

Saya setuju dengan perbaikan sisi pip jangka pendek, tetapi saya ingin mengklarifikasi kapan kita dapat mengharapkan perbaikan alat pengaturan.

Halo semua!

Saya memiliki masalah yang sama:

**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'**

Adakah yang tahu jika masalahnya sudah terpecahkan? Atau bagaimana mengatasinya untuk sementara?

Terima kasih semuanya!

@ jce94 , gunakan pip <19 untuk saat ini.

@altendky terima kasih atas infonya!

Saya tidak dapat menyelesaikan masalah ini dengan solusi yang disarankan saat bekerja dengan pipenv . Membekukan pip menjadi 18.1 di Pipfile tampaknya tidak berpengaruh karena pipenv terus memaksakan versi pip terbaru. Saya dapat mengatur pip secara manual ke 18.1 tetapi ketika saya membuat ulang lingkungan virtual pipenv, Pipenv akan mengupgrade ke pip terbaru apa pun yang terjadi ... Adakah rekomendasi untuk membuatnya tetap?

@altendky Sayangnya, menggunakan versi pip yang telah ditentukan tidak dimungkinkan pada saat itu untuk pengguna pipenv (dan juga untuk puisi menurut saya). Keduanya menggunakan versi terbaru. Jadi saya menduga banyak orang yang terjebak dengan jaringan pipa yang rusak untuk saat ini

Yang lebih aneh lagi, itu tidak terjadi secara konsisten. Saya telah menjalankan kembali pekerjaan Appveyor, yang pertama lulus, yang kedua gagal meskipun keduanya sama persis

Jika ada yang bertanya-tanya tentang garis waktu, saya berharap kami dapat menyiapkan perbaikannya pada akhir minggu ini atau awal minggu depan dan membuat rilis perbaikan bug pip segera setelah itu.

Versi baru setuptools, versi 40.8.0 sekarang tersedia dengan backend build_meta:__legacy__ .

Terima kasih! Dan apakah ini sesuatu yang harus kita tunjuk PyInstaller untuk digunakan? Mereka
cukup tidak senang dengan perubahan ... Dokumentasi atau PEP apa pun yang dapat saya tunjukkan
mereka dengan untuk mendukung perubahan?

Pada Tue, Feb 5, 2019, 10:24 Paul Ganssle < [email protected] menulis:

Versi baru setuptools, versi 40.8.0 sekarang tersedia dengan
build_meta: __ legacy__ backend.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/pypa/pip/issues/6163#issuecomment-460747909 , atau nonaktifkan
utasnya
https://github.com/notifications/unsubscribe-auth/ADtXZjnOfu56IYR6VEKK4yowMg3XdcFEks5vKcxBgaJpZM4aNvmP
.

@AlmogCohen Tidak, ini bukan sesuatu yang harus Anda gunakan secara langsung, ini hanya untuk digunakan oleh PEP 517 front-end. Langkah selanjutnya adalah pip untuk mulai menggunakan build_meta:__legacy__ sebagai backend default. Ini tidak dapat ditindaklanjuti dari sudut pandang pengguna akhir.

Adakah ETA pada rilis baru yang akan mengintegrasikan perbaikan?

Dalam beberapa jam. :)

Lihat masalah yang dipasangi pin.

pip 19.0.2 telah dirilis dengan perbaikan untuk ini.

Saya tidak dapat memasang pyinstaller dengan versi pip terbaru, meskipun menggunakan --no-use-pep517

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\

Utas ini telah dikunci secara otomatis karena tidak ada aktivitas baru-baru ini setelah ditutup. Silakan buka masalah baru untuk bug terkait.