Pip: Kesalahan dengan `import pip` di pip 9.0.2

Saya dapat mengkonfirmasi ini juga. Baru saja akan mengajukan masalah yang sama.

Ini adalah penipuan #5079 -- mengimpor pip bukanlah kasus penggunaan yang didukung (dan belum pernah).

Ayo.. membuat perubahan besar dalam satu versi x.x.PATCH ? Untuk metode tingkat atas yang disebut "utama"? menurut saya bentuknya kurang bagus..

Ini juga merusak Anaconda dan saya menemukan solusi yang sama dengan @Miserlou :

https://github.com/ContinuumIO/anaconda-issues/issues/8911

Kesalahan dilaporkan di banyak proyek.

Kesalahan ini juga mengganggu saya ketika saya mencoba menggunakan pip untuk memperbarui anaconda-navigator saya.

Apakah ada kemungkinan kita mendapatkan 9.0.3 yang memperbaiki ini - idealnya segera?

Ini sudah mempengaruhi banyak proyek besar (Anaconda, SpaCy, Zappa), dan ada lebih dari 850k+ penggunaan ini di GitHub saja yang sekarang rusak oleh pembaruan versi "tambalan" yang seharusnya ini.

Bisakah Anda setidaknya mengembalikan perubahan besar-besaran ini di 9.0.3 dan kemudian _announce_ untuk menurunkan niat Anda untuk mengubah perilaku ini untuk rilis 10.xx atau setidaknya 9.xx di masa mendatang?

Kami juga tidak ingin menggunakan versi yang lebih lama, tetapi itulah yang akhirnya kami lakukan. 9.0.2 tidak ada di dalam lingkungan CI kami, setidaknya untuk saat ini.

Juga melihat hit ini di beberapa proyek OpenStack.

Pip 10 akan keluar dalam waktu sekitar satu bulan. Seperti yang saya pahami, masalahnya adalah dengan kode yang menggunakan import pip untuk mengakses fungsionalitas internal pip. Kami tidak pernah mendukung penggunaan seperti itu secara resmi, dan kami telah secara eksplisit mendokumentasikan kurangnya dukungan untuk beberapa waktu sekarang (walaupun hanya dalam versi "terbaru" dari dokumen di https://pip.pypa.io/en/latest/user_guide /#using-pip-from-your-program, karena kami belum memiliki rilis stabil baru sejak bagian dokumen itu ditambahkan). Kami juga mengumumkan reorganisasi internal untuk memperjelas bahwa penggunaan API internal tidak didukung, Oktober lalu (lihat https://mail.python.org/pipermail/distutils-sig/2017-October/031642.html). Perubahan itu, yang ada di pip 10, akan menghentikan penggunaan semacam itu terlepas dari pip apa yang mungkin akan dilakukan oleh rilis pip 9.0.3. Jadi sulit untuk melihat ini sebagai kerusakan yang tiba-tiba dan tidak terduga.

Jika @dstufft ingin membuat rilis darurat 9.0.3, saya setuju dengan itu. Tapi itu hanya akan menjadi keuntungan jangka pendek, dan saya sedikit kecewa karena orang-orang belum beranjak dari import pip . Orang-orang yang terkena masalah ini masih perlu bersiap untuk pip 10, dan harus memahami bahwa hanya beralih ke import pip._internal bukanlah sesuatu yang akan kami dukung atau rekomendasikan.

Proposal untuk memperkenalkan kembali beberapa tingkat dukungan API tentu saja merupakan opsi (lihat #5080 misalnya) tetapi pada tahap ini, sudah terlambat untuk perubahan semacam itu untuk membuatnya menjadi pip 10.

Tanpa peringatan yang diajukan oleh kode untuk mereka yang menggunakan cara lama, tidak ada yang menunjukkan ini sebagai "internal" dengan dimulai dengan _, dan ini hanya perbaikan bug, saya sebenarnya berpikir cukup mudah untuk melihat ini sebagai kerusakan yang tiba-tiba dan tidak terduga .

Ya, ini adalah jenis perubahan yang diharapkan orang dari pembaruan versi MAJOR . Itu akan baik-baik saja.

Sayangnya, perubahan besar ini datang dalam pembaruan PATCH , yang _seharusnya memperbaiki sesuatu, bukan merusaknya_. Ini adalah kebalikan dari versi semantik. Dan, sebagai hasilnya, kami melihat kerusakan besar di seluruh ekosistem Python.

Anda harus mengembalikan perubahan ini ASAP dalam pembaruan PATCH lainnya, kemudian mintalah perubahan utama yang mengganggu dengan pembaruan versi MAJOR . Sekarang Anda telah menghancurkan segalanya untuk semua orang sebelum waktunya, saya pikir mereka akan lebih sadar bahwa perubahan besar yang sebenarnya akan datang.

Saya juga berpikir itu adalah polisi untuk mengatakan bahwa ini telah didokumentasikan dan diumumkan, mengingat itu _tidak_ didokumentasikan dalam dokumentasi stabil , dan bahwa pengumuman tersebut mengatakan bahwa jeda akan terjadi _untuk versi utama_, bukan untuk dalam tambalan sebulan sebelumnya.

Tolong, selamatkan semua orang dari sakit kepala besar, kembalikan masalah ini dan mulai benar-benar mengikuti versi semantik.

@Miserlou OK, saya mengerti maksud Anda - kami menargetkan perubahan penamaan internal untuk pip 10 karena ini adalah versi utama. Saya tidak benar-benar tahu driver untuk rilis tambalan - @dstufft mem -ping saya tentang hal itu dan tampaknya untuk menghindari kerusakan yang signifikan bagi pengguna Mac OS ketika tenggat waktu yang dekat untuk dukungan TLS menimpa kami, yaitu sebelum rilis pip 10. Kami mengharapkan masalah menjadi cukup signifikan untuk menjamin rilis patch jangka pendek. Jelas tidak ada niat untuk melanggar penggunaan yang ada.

Saya harus menyerahkan keputusan tindak lanjut 9.0.3 ke @dstufft - Saya tidak memiliki detail tentang apa yang masuk ke 9.0.2 atau tahu apakah mungkin untuk mengidentifikasi cara memperbaiki masalah ini. Dan saya tidak dapat menilai apakah menarik 9.0.2 secara keseluruhan akan menjadi manfaat keseluruhan, karena saya tidak tahu berapa banyak orang yang terpengaruh oleh masalah Mac OS. Saya mengerti bahwa (setidaknya untuk beberapa orang) menyematkan ke 9.0.1 adalah solusi, sehingga mungkin menjadi opsi yang paling tidak buruk.

Masalah TLS macOS akan memengaruhi semua orang yang menggunakan sistem Python di macOS<10.13

Saya harus meninggalkan keputusan tindak lanjut 9.0.3 ke @dstufft

Saya berada di posisi yang sama dengan @pfmoore.

Solusinya, jika Anda memilikinya, adalah memeriksa urutan impor dan menguji pemindahan pip impor di atas paket impor lainnya (khususnya, mengimpor permintaan impor pip _before_ tampaknya menyelesaikan beberapa kasus). (Perhatikan bahwa ini masih menyiratkan penggunaan internal pip, yang tidak didukung secara resmi.)

Masalah yang sama di sini dengan pip 9.0.2 di gitlab-ci dengan docker python 3.4: KeyError

  File "/usr/local/lib/python3.4/site-packages/pip/__init__.py", line 45, in <module>
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/usr/local/lib/python3.4/site-packages/pip/vcs/mercurial.py", line 9, in <module>
    from pip.download import path_to_url
  File "/usr/local/lib/python3.4/site-packages/pip/download.py", line 40, in <module>
    from pip._vendor import requests, six
  File "/usr/local/lib/python3.4/site-packages/pip/_vendor/requests/__init__.py", line 98, in <module>
    from . import packages
  File "/usr/local/lib/python3.4/site-packages/pip/_vendor/requests/packages.py", line 12, in <module>
    sys.modules['pip._vendor.requests.packages.' + mod] = sys.modules["pip._vendor." + mod]
KeyError: 'pip._vendor.urllib3.contrib'

FYI, 9.0.2 dirilis dengan build yang rusak:

Referensi Travis-CI: https://travis-ci.org/pypa/pip/builds/354616774?utm_source=github_status&utm_medium=notification

Memang kesalahan mungkin tidak terkait, meskipun ini hanya berbau seperti "rilis terburu-buru"...

@pfmoore

Jika @dstufft ingin membuat rilis darurat 9.0.3, saya setuju dengan itu. Tapi itu hanya akan menjadi keuntungan jangka pendek, dan saya sedikit kecewa karena orang-orang belum beranjak dari pip impor. Orang-orang yang terkena masalah ini masih perlu bersiap untuk pip 10, dan harus memahami bahwa hanya beralih ke import pip._internal bukanlah sesuatu yang akan kami dukung atau rekomendasikan.

Saya tidak percaya bahwa ini adalah pernyataan dari pemilik repositori ini... Anda benar-benar baru saja mengatakan "f*ck semantic versioning" dan "siapa yang membutuhkan kebijakan penghentian".

pip selalu didokumentasikan sebagai TIDAK memiliki python api yang dapat dikonsumsi, saya kecewa pada orang-orang yang bahkan pada saat itu mencoba untuk membalikkan karma "sudah memberi tahu Anda sejak beberapa tahun"

@RonnyPfannschmidt Ini seperti mengatakan "Kami sudah memberi tahu Anda 100 kali bahwa Anda tidak boleh mengemudi di atas batas kecepatan" dan kemudian menegakkan batas kecepatan dengan mengganti semua mesin-mobil dengan mobil-flintstone, sehingga orang tidak bisa melewati batas kecepatan. batas kecepatan lagi.

Anda baru saja menunjukkan dengan sempurna bahwa membalikkan kata-kata yang sangat buruk - mengatakan "jangan mengandalkan itu akan rusak" - sekarang rusak dan tiba-tiba proyek yang memberi tahu Anda sebelumnya bahwa itu akan rusak adalah salah

itu hanya menyalahkan karena kamu tidak suka disalahkan

@RonnyPfannschmidt

itu hanya menyalahkan karena kamu tidak suka disalahkan

Jadi Anda mengatakan bahwa saya bersalah karena menggunakan paket pihak ketiga yang mengandalkan fitur pip. Mungkin, saya... Saya seharusnya menyaring paket pihak ketiga untuk kesalahan tersebut dan mengajukan masalah atau bahkan PR yang lebih baik.

Tapi mari kita hadapi kenyataan: Ada banyak proyek di luar sana yang digunakan dalam produksi yang sekarang rusak. Ini bukan masalah moral, bukan pertanyaan siapa yang salah. Ini masalah "bisakah Anda memperbaikinya dan memberikan peringatan/penghentian yang tepat".

Jika paket pihak ketiga yang Anda gunakan rusak karena bergantung pada API internal yang tidak berdokumen dan tidak dijamin, menurut saya Anda harus mengajukan bug terhadap paket itu.

Ada garis yang mudah ditemukan antara bagian mana dari pip yang dimaksudkan dan tidak dimaksudkan untuk konsumsi pihak ketiga, dan saya tidak mendukung upaya memaksa pengembangnya untuk memelihara API internal yang seharusnya tidak pernah ada. dikonsumsi oleh paket pihak ketiga. Saya tidak mendukung memperlakukan ini sebagai kesalahan pengembang pip dan mengirim pengguna yang marah ke arah mereka. Jika Anda ingin marah pada seseorang, marahlah pada paket apa pun yang Anda gunakan yang mengandalkan API internal, dan dorong pengelolanya untuk memperbaiki kode mereka sendiri.

@anx-ckreuzberger

Saya tidak percaya bahwa ini adalah pernyataan dari pemilik repositori ini... Anda benar-benar baru saja mengatakan "f*ck semantic versioning" dan "siapa yang membutuhkan kebijakan penghentian".

Sementara saya memahami frustrasi di sini, saya semakin kesal dengan kesediaan orang untuk menyalahkan pengelola pip untuk hal-hal yang tidak pernah kami janjikan.

Jika Anda ingin membuat tuduhan seperti itu, silakan dukung dengan

1. Pointer ke pernyataan dari salah satu pengelola pip yang kami dukung penggunaan API internal pip dalam kode pengguna.
2. Pointer ke pernyataan dari salah satu pengelola pip bahwa pip menggunakan versi semantik.

Saya tidak berpikir Anda akan menemukan bukti itu...

Jadi Anda mengatakan bahwa saya bersalah karena menggunakan paket pihak ketiga yang mengandalkan fitur pip.

Tidak, tetapi menuduh pengelola pip daripada proyek-proyek itu tidak dapat diterima. Kami mencoba membantu Anda tetapi tidak bertanggung jawab atas apa yang dilakukan proyek tersebut. Sampaikan keluhan Anda dengan mereka.

Tapi mari kita hadapi kenyataan: Ada banyak proyek di luar sana yang digunakan dalam produksi yang sekarang rusak. Ini bukan masalah moral, bukan pertanyaan siapa yang salah. Ini masalah "bisakah Anda memperbaikinya dan memberikan peringatan/penghentian yang tepat".

Kami mencoba memberikan peringatan. Kami mengirimkan pengumuman beberapa bulan yang lalu, kami menambahkan dokumen yang menjelaskan situasinya, dan kami secara konsisten menjawab masalah pada pelacak yang menyatakan bahwa penggunaan API internal tidak didukung. Menambahkan penghentian jauh dari semudah yang Anda sarankan, karena pip itu sendiri akan memuntahkan peringatan itu (atau akan ada cara bagi pip untuk mematikannya, yang hanya akan disalin oleh orang lain - kami sudah mendengar orang berencana untuk hanya import pip._internal , jadi bahkan perubahan itu tidak akan menghentikan mereka :kecewa :).

Mengenai "memperbaiki" ini, saya akan dengan senang hati mengakui bahwa 9.0.2 dirilis dengan cepat untuk mengatasi masalah mendesak, dan kami tidak mengantisipasi masalah ini. Mungkin merilis 9.0.3 dengan masa hidup 2-3 minggu adalah hal yang wajar untuk dilakukan, saya sendiri tidak berpikir demikian, tetapi saya telah menyatakan bahwa kami akan mempertimbangkannya. Saya pribadi tidak setuju untuk melakukannya, karena saya bukan orang yang terlibat dalam rilis 9.0.x. Saya sedang mengerjakan pip 10, yang akan membuat semua perdebatan ini tidak relevan, jadi ini mungkin kata terakhir saya tentang masalah ini - saya perlu fokus pada hal-hal yang terkait dengan rilis itu.

Saran pribadi saya:

1. Sematkan ke 9.0.1 jika Anda terpengaruh oleh ini dan perlu solusi sekarang .
2. Bersiaplah untuk pip 10, ketika semua dependensi yang Anda miliki saat ini rusak karena menggunakan API internal pip akan rusak lagi. Dorong ketergantungan tersebut untuk mengambil tindakan atas informasi yang telah kami berikan selama berbulan-bulan, dan senang Anda mendapat peringatan sebelumnya bahwa itu akan terjadi.
3. Jika pip 9.0.3 terlepas, lepaskan pin.
4. Silakan , uji pip 10 beta ketika keluar, dan laporkan masalah apa pun kepada pihak terkait (proyek pihak ke-3 jika mereka memanggil pip secara internal, kami jika Anda memanggil sendiri pip).

Saya telah mengalami masalah yang sama dengan pip 9.0.2 dan Python 2.7.14 dalam wadah buruh pelabuhan.
Saya tidak dapat mereproduksi masalah pada mesin dev saya di luar wadah buruh pelabuhan.
Saya mencari impor pip (mengambil import.pip , from.pip , \'pip , \"pip ) tetapi tidak dapat menemukan apa pun.
Kami di Plone menggunakan mekanisme untuk secara otomatis memasukkan konfigurasi dari paket yang disertakan dalam file setuptools setup.py, yang terdengar mencurigakan - tetapi sekali lagi - yang ini hanya menggunakan __import__ dan tidak ada apa pun dari pip AFAIcansee.

Ini bagian yang relevan dari traceback:

  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/xmlconfig.py", line 359, in endElementNS
    self.context.end()
  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/config.py", line 558, in end
    self.stack.pop().finish()
  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/config.py", line 706, in finish
    actions = self.handler(context, **args)
  File "/home/plone/.buildout/shared-eggs/z3c.autoinclude-0.3.7-py2.7.egg/z3c/autoinclude/zcml.py", line 51, in includeDependenciesDirective
    info = DependencyFinder(dist).includableInfo(['configure.zcml', 'meta.zcml'])
  File "/home/plone/.buildout/shared-eggs/z3c.autoinclude-0.3.7-py2.7.egg/z3c/autoinclude/dependency.py", line 26, in includableInfo
    module = resolve(dotted_name)
  File "/home/plone/.buildout/shared-eggs/zope.dottedname-4.2-py2.7.egg/zope/dottedname/resolve.py", line 39, in resolve
    found = __import__(used)
  File "/plone/buildout/lib/python2.7/site-packages/pip/__init__.py", line 45, in <module>
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/plone/buildout/lib/python2.7/site-packages/pip/vcs/mercurial.py", line 9, in <module>
    from pip.download import path_to_url
  File "/plone/buildout/lib/python2.7/site-packages/pip/download.py", line 40, in <module>
    from pip._vendor import requests, six
  File "/plone/buildout/lib/python2.7/site-packages/pip/_vendor/requests/__init__.py", line 98, in <module>
    from . import packages
  File "/plone/buildout/lib/python2.7/site-packages/pip/_vendor/requests/packages.py", line 12, in <module>
    sys.modules['pip._vendor.requests.packages.' + mod] = sys.modules["pip._vendor." + mod]
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/plone/buildout/parts/instance/etc/site.zcml", line 15.2-15.55
    ZopeXMLConfigurationError: File "/plone/buildout/parts/instance/etc/package-includes/002-bda.aaf.site-configure.zcml", line 1.0-1.56
    ZopeXMLConfigurationError: File "/plone/buildout/src-aaf/bda.aaf.site/src/bda/aaf/site/configure.zcml", line 11.2-11.48
    ZopeXMLConfigurationError: File "/plone/buildout/src-aaf/bda.aaf.site/src/bda/aaf/site/configure-dependencies.zcml", line 10.2-10.39
    ZopeXMLConfigurationError: File "/plone/buildout/src-addons/plone.app.mosaic/src/plone/app/mosaic/configure.zcml", line 9.2-9.39
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/plone.app.tiles-3.0.3-py2.7.egg/plone/app/tiles/configure.zcml", line 18.2-18.41
    ZopeXMLConfigurationError: File "/plone/buildout/src/plone.app.z3cform/plone/app/z3cform/configure.zcml", line 10.2-10.41
    ZopeXMLConfigurationError: File "/plone/buildout/src/plone.app.widgets/plone/app/widgets/configure.zcml", line 12.2-12.41
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/Products.CMFPlone-5.1.0.1-py2.7.egg/Products/CMFPlone/configure.zcml", line 15.2-15.46
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/plone.app.contenttypes-1.4.9-py2.7.egg/plone/app/contenttypes/configure.zcml", line 10.2-10.37
    KeyError: 'pip._vendor.urllib3.contrib'

Sejauh yang saya mengerti hanya mengimpor pip - tanpa menggunakannya - sudah rusak. Ini bukan perilaku warga yang baik di tanah Python. Tidak mendukung menggunakannya/ tidak menyediakan API publik adalah satu hal, hanya melanggar impor yang lain. Ini memengaruhi banyak kode pemeriksaan otomatis.

Pikirkan seperti ini: pip adalah utilitas baris perintah, bukan perpustakaan. Fakta bahwa itu ditulis dengan Python tidak relevan. Itulah kenyataan yang terjadi.

@pfmoore

Sementara saya memahami frustrasi di sini, saya semakin kesal dengan kesediaan orang untuk menyalahkan pengelola pip untuk hal-hal yang tidak pernah kami janjikan.

Pikirkan seperti ini: pip adalah utilitas baris perintah, bukan perpustakaan. Fakta bahwa itu ditulis dengan Python tidak relevan. Itulah kenyataan yang terjadi.

Intinya adalah itu benar-benar tidak masalah apa yang Anda janjikan. Yang penting adalah apa yang Anda lakukan dan situasi yang dihasilkan. Mungkin Anda menganggapnya sebagai utilitas baris perintah. Tapi Anda merilisnya sebagai perpustakaan. Itu adalah kenyataan dari masalah ini:

Anda telah merilis perpustakaan dengan Fitur X. Orang-orang mulai menggunakan Fitur X. Tentu, Anda mengatakan "teman-teman, tolong jangan gunakan Fitur X". Tapi Anda terus merilisnya dengan Fitur X. Selama bertahun-tahun. Dan orang-orang terus menggunakannya. Puluhan, mungkin ratusan, dari ribuan proyek, besar dan kecil, gunakan sekarang. Tiba-tiba Anda menghapusnya dalam pembaruan kecil tanpa peringatan yang memadai.

Menurut Anda apa yang terjadi selanjutnya?

Dalam jangka pendek, orang hanya akan menyematkan versi lama dan tidak melepasnya kecuali ada alasan bagus.

Dalam jangka panjang... yah, tergantung pada berapa banyak orang yang memutuskan akan lebih hemat biaya untuk mengganti Anda daripada memperbaiki semua yang telah Anda rusak.

@pfmoore apakah Anda melihat sesuatu yang mencurigakan di traceback yang saya rujuk di atas? Tidak ada penggunaan pip internal AFAIK. Sangat menarik bahwa kebanyakan orang memiliki masalah ini dalam wadah buruh pelabuhan.

@ all, menuduh pengelola kode rusak tidak membantu memecahkan masalah.

Pikirkan seperti ini: pip adalah utilitas baris perintah, bukan perpustakaan. Fakta bahwa itu ditulis dengan Python tidak relevan. Itulah kenyataan yang terjadi.

Fakta: Tidak dapat diimpor, jika diimpor bahkan dengan kode pemeriksaan otomatis karena beberapa alasan: semua rusak. Saya kira ini terjadi dalam kasus @thet .
Kesimpulan: pip harus mengisolasi dirinya dari global atau virtualenv/venv Python namespace global atau saat ini tempat ia menginstal paket. Dengan begitu tidak akan mencemarinya dan bahkan tidak pernah terjadi impor secara tidak sengaja.

Pertama-tama, maaf jika saya menuduh pengelola repo untuk kode yang salah. Tuduhan apa pun dibuat karena frustrasi, dan, jika sama sekali, tunjukkan fakta bahwa IMHO rilis 9.0.2 menurut definisi semver rilis patch (meskipun @pfmoore menjelaskan bahwa pip tidak harus menggunakan semver - yang adalah masalah lain untuk hari lain saya kira).

@MikeHart85

Dalam jangka pendek, orang hanya akan menyematkan versi lama dan tidak melepasnya kecuali ada alasan bagus.
Dalam jangka panjang... yah, tergantung pada berapa banyak orang yang memutuskan akan lebih hemat biaya untuk mengganti Anda daripada memperbaiki semua yang telah Anda rusak.

Kurang lebih. Maksud saya lihat manajer paket JavaScript: npm, bower, yarn, apa pun yang dirilis ~ tahun ~ minggu depan

Tidak, tetapi menuduh pengelola pip daripada proyek-proyek itu tidak dapat diterima. Kami mencoba membantu Anda tetapi tidak bertanggung jawab atas apa yang dilakukan proyek tersebut. Sampaikan keluhan Anda dengan mereka.

Saya memahami bahwa keluhan saya (kami?) dalam masalah ini mungkin salah arah. Meskipun Anda harus mengakui bahwa sangat sulit untuk meyakinkan siapa pun bahwa ini adalah kesalahan pengelola pihak ketiga.

Kami mencoba memberikan peringatan. Kami mengirim pengumuman beberapa bulan yang lalu, kami menambahkan dokumen yang menjelaskan situasinya

Apakah ini untuk pip 9.0.2 atau untuk pip 10? Jika untuk pip 9.0.2, saya akan merasa senang jika ada catatan di Changelog . Bagaimanapun, terima kasih telah sangat proaktif dalam pengembangan pip 10 dan mengirimkan pengumuman tentang tidak menggunakan import pip , itu bagus! Teruskan!

Menambahkan penghentian jauh dari semudah yang Anda sarankan, karena pip itu sendiri akan memuntahkan peringatan itu (atau akan ada cara bagi pip untuk mematikannya, yang hanya akan disalin oleh orang lain - kami sudah mendengar orang berencana untuk hanya import pip._internal, jadi bahkan perubahan itu tidak akan menghentikan mereka kecewa).

Saya tidak berpikir ini akan terlalu sulit... Anda sudah memiliki ini di __init__.py :

if __name__ == '__main__':
    sys.exit(main())

Bagaimana kalau menambahkan yang lain saja?

if __name__ == '__main__':
    sys.exit(main())
else:
    logger.warning("You are importing PIP as a Python library. This behaviour is deprecated and should no longer be used. We will break the API with version 10.0!!!111eleven Please see https://pip.readthedocs.org/some_link_where_you_explain_this.html")

edit : Anda bahkan dapat mengajukan pengecualian di sini jika Anda ingin "tegas" tentang hal itu, dan menambahkan pernyataan serupa ke submodul.

Fakta bahwa orang akan mengatasi ini, adalah sesuatu yang lain. Jika Anda ingin meretas perpustakaan, Anda selalu dapat merekayasa baliknya. Anda selalu dapat menemukan cara untuk mengatasinya. Tetapi Anda tidak harus mempertimbangkan semua cara di sekitarnya dalam keputusan desain Anda.

Dalam jangka panjang... yah, tergantung pada berapa banyak orang yang memutuskan akan lebih hemat biaya untuk mengganti Anda daripada memperbaiki semua yang telah Anda rusak.

Saya selalu menganggap "ancaman" ini lucu. Muncul dengan itu kesalahpahaman mendasar tentang jumlah usaha yang dimasukkan ke dalam sesuatu seperti pip dan berapa biaya yang sebenarnya (dan betapa sedikit orang yang mau benar-benar membayar untuk itu). Jika Anda merasa mampu melakukan yang lebih baik, maka lakukanlah, saya (dan saya berasumsi yang lain) menyambutnya. Sejumlah upaya yang tidak sepele dalam beberapa tahun terakhir telah mendokumentasikan dan merancang standar dengan salah satu tujuan eksplisit untuk memungkinkan hal seperti itu terjadi.

Sangat penting untuk menjaga rasa perspektif tentang hal-hal ini. Ada.. kurang dari 15? 20? orang-orang berkomentar tentang bagaimana ini memecahkannya (meskipun selalu ada masalah "puncak gunung es" dengan metrik ini), sementara itu pip 9.0.2 sudah menjadi penginstal kedua yang paling banyak digunakan dalam seminggu terakhir (menghitung hari bahkan belum ada for) dan telah mengunduh 17 juta file dari PyPI sejak dirilis. Melihat hanya pada hari terakhir, ini adalah 80% cara untuk menyalip pip 9.0.1 sebagai penginstal yang paling banyak digunakan di PyPI.

Jadi, sementara saya menyadari bahwa ini memecahkan masalah bagi sebagian orang, itu adalah sejumlah kecil orang yang melakukan hal-hal yang tidak didukung, atau dalam situasi kasus yang cukup canggih.

JIKA saya dapat menemukan waktu, saya dapat mencoba untuk memotong 9.0.3, terutama untuk menyelesaikan kasus yang @thet telah mengalami di mana itu hanya importir otomatis yang mencoba mengimpor barang, dan mereka tidak benar-benar mencoba menggunakan API internal pip dengan cara apa pun. Jika itu juga akhirnya menyelesaikan perilaku untuk orang yang menggunakan API internal pip, saya tidak akan berusaha keras untuk memecahkannya secara khusus, tetapi jika tidak, saya juga tidak akan berusaha keras untuk memperbaikinya. mereka secara khusus baik.

Harap dicatat bahwa dibutuhkan berjam-jam untuk merilis 9.0.x pada saat ini (hal-hal telah menyimpang dalam master cukup sehingga memerlukan beberapa finagling untuk melakukan rilis) dan itu tidak menghitung waktu yang dibutuhkan untuk men-debug dan memperbaiki masalah yang sebenarnya. Jika Anda ingin meningkatkan kemungkinan hal ini terjadi, melakukan debugging dan memperbaiki dan menyediakan patch (atau cabang dari tag 9.0.2 di fork Anda sendiri) adalah cara terbaik untuk melakukannya.

Pertama-tama, maaf jika saya menuduh pengelola repo untuk kode yang salah. Tuduhan apa pun dibuat karena frustrasi

Terima kasih. Frustrasi tinggi di sini, dan saya mengerti itu.

Bagaimana kalau menambahkan yang lain saja?

Ide bagus - Saya berharap kita memikirkan ini beberapa waktu lalu. Tentu saja, tidak ada gunanya sekarang, karena namespace internal akan diatur ulang di pip 10, jadi sudah terlambat. Saya pasti akan mengingat trik ini untuk masa depan.

Apakah ini untuk pip 9.0.2 atau untuk pip 10?

Untuk 10.0. Tidak ada niat awal untuk merilis 9.0.2, kami hanya melakukannya sebagai rilis darurat sehingga pengguna Mac OS tidak akan kehilangan semua akses ke PyPI saat perubahan TLS mulai berlaku.

@dstufft telah merespons di sini jauh lebih lengkap, jadi saya pikir ini sudah teratasi seperti yang mungkin terjadi untuk saat ini.

Saya selalu menganggap "ancaman" ini lucu.

Ini bukan ancaman sama sekali, mohon maaf jika dianggap seperti itu.

Ini adalah pengamatan tentang sesuatu yang terlalu sering terjadi di dunia perangkat lunak. Orang tidak bekerja dengan janji atau niat Anda. Orang-orang bekerja dengan produk yang Anda berikan. Jika produk Anda memiliki fitur yang diandalkan oleh banyak orang, Anda tidak bisa lagi mencabutnya begitu saja. Jika Anda melakukannya, mereka mulai melihat produk Anda rusak. Jika satu-satunya penjelasan yang Anda berikan adalah "well, kami tidak pernah menjanjikan hal ini" maka mereka mulai melihat keengganan Anda untuk mengakui kekhawatiran mereka sebagai kewajiban.

Semakin banyak hal ini terjadi, semakin besar keinginan dan permintaan akan suatu alternatif. Tentu, orang meremehkan berapa banyak pekerjaan yang dibutuhkan. Tapi itu hanya membuat mereka lebih , tidak kurang, cenderung mulai mengerjakannya. Begitu bola itu menggelinding, ia memiliki kehidupannya sendiri.

Alternatif tidak selalu merupakan hal yang baik. Mereka cenderung membuat hal-hal berantakan. Secara pribadi, saya lebih suka satu manajer paket. Untuk semuanya. Tapi saya akan puas dengan satu manajer paket untuk Python.

Ketika orang-orang melaporkan Anda telah merusak fitur, disengaja atau tidak, pertimbangkan untuk menjelaskan secara singkat mengapa Anda harus merusaknya, atau mengapa mempertahankannya tidak dapat dijalankan, daripada mengabaikan kekhawatiran dengan "ini tidak didukung selama ini".

Hei @dstufft , terima kasih telah bergabung. Utas ini menjadi sangat panas!

Pertama-tama, saya berterima kasih atas pekerjaan Anda! Saya tahu bahwa pemeliharaan adalah tugas tanpa akhir dan tanpa pamrih, dan saya membayangkan itu hanya akan menjadi lebih buruk ketika Anda mengelola proyek sebesar dan sepopuler pip !

Sekarang, untuk masalah yang dihadapi: Meskipun dua puluh _pemelihara_ telah melaporkan masalah ini sejauh ini, saya tahu itu sudah mempengaruhi ribuan _orang_ - beberapa proyek yang terpengaruh sangat besar dalam hak mereka sendiri: Anaconda, OpenStack, SpaCy, Zappa, dan telah banyak puluhan ribu pengguna. Saya tahu saluran Slack kami dibanjiri diskusi tentang ini. (Secara harfiah, saat saya mengetik ini, masalah baru muncul.)

Jelas, ada banyak proyek Python penting yang membutuhkan kemampuan untuk memeriksa lingkungan mereka secara terprogram. Ini adalah hal yang benar-benar masuk akal untuk dapat dilakukan. Selain itu, dokumentasi tidak pernah memperingatkan untuk tidak melakukan ini - dan masih tidak! (Klik tautan Documents dari README repo ini!)

Saya pikir situasinya sejauh ini adalah:

• Mengingat format string versi, kita semua percaya bahwa pengelola pip mengikuti versi semantik
• Pengelola pip merilis "tambalan" yang memperkenalkan perubahan besar-besaran
• Perubahan ini tidak diumumkan dan tidak didokumentasikan - dan saya berasumsi, tidak terduga dan tidak disengaja
• Sekarang, memanggil import pip saja langsung merusak program, yang sangat memusuhi pengembang
• Ini menyebabkan sakit kepala besar di seluruh ekosistem Python
• Dokumentasi tidak (dan _still_ tidak - klik tautan Documents di README repo ini) memperingatkan agar tidak menggunakan pip secara terprogram.
• Tidak ada pengumuman bahwa import pip akan menyebabkan kerusakan ini dalam pembaruan PATCH - pengumuman itu datang untuk versi yang _belum dirilis_.
• Perubahan ini bahkan tidak disebutkan di Changelog
• Kami tidak ingin mengganti pip atau pengembang pip! Kami mencintai kamu!
• ..tapi kami tidak ingin hal seperti ini terjadi lagi!
• ..jadi kami ingin semver diikuti!
• Kami akan sangat, sangat menyukai PATCH lain yang membatalkan perubahan besar ini!

Kebutuhan akan cara terprogram untuk memeriksa lingkungan di dunia pip>=10.0.0 adalah topik untuk diskusi lain, tetapi faktanya adalah bahwa kami tidak pernah diberitahu bahwa kami tidak boleh menggunakan pip secara terprogram di pip <=9 dunia, dan ada perubahan besar-besaran yang tidak diumumkan, dan kami benar-benar ingin melihatnya terbalik karena berdampak negatif pada ribuan orang.

Terima kasih lagi,
Kaya

Pertama-tama: Terima kasih kepada pengelola pip atas upaya dan wawasan mereka dalam proyek ini. Saya percaya ini benar-benar membantu orang lain memahami masalah ini (meskipun mungkin layak untuk menulis artikel blog ringkasan tentang itu).

@dstufft

Sangat penting untuk menjaga rasa perspektif tentang hal-hal ini. Ada.. kurang dari 15? 20? orang-orang berkomentar tentang bagaimana ini memecahkannya (meskipun selalu ada masalah "puncak gunung es" dengan metrik ini), sementara itu pip 9.0.2 sudah menjadi penginstal kedua yang paling banyak digunakan dalam seminggu terakhir (menghitung hari bahkan belum ada for) dan telah mengunduh 17 juta file dari PyPI sejak dirilis. Melihat hanya pada hari terakhir, ini adalah 80% cara untuk menyalip pip 9.0.1 sebagai penginstal yang paling banyak digunakan di PyPI.

Saya cukup yakin bahwa metrik sangat bias oleh semua perintah pip install pip --upgrade otomatis dari sistem Integrasi/Pengiriman Berkelanjutan (mereka harus menggunakan cache, dan karena itu tidak perlu menginstal ulang paket dari pypi setiap saat; tetapi di pada saat yang sama, seseorang juga tidak boleh melakukan import pip ... begitulah cara kerja dunia TI).

Fakta bahwa (kurang dari) 15 orang mengeluh tentang ini seharusnya menunjukkan dua hal:

1. Saya tidak berpikir bahwa banyak orang menggunakan 9.0.2 (dalam produksi), beberapa mungkin masih mencoba untuk men-debug masalah ini dan akan "sementara" memperbaikinya dengan menggunakan pip 9.0.1 sebagai gantinya sampai diselesaikan (atau selamanya.. .) - juga, beberapa orang mungkin tidak menyadari bahwa ada sesuatu yang belum berfungsi...
2. Ada orang yang sudah membicarakannya dalam 2 hari setelah rilis. Lebih banyak orang akan mengalami masalah ini. Tunggu selama 2 minggu, dan Anda bisa mendapatkan 100 orang mengeluh tentang hal itu (misalnya, ketika mereka menyelesaikan sprint dan menyebarkan ke QA/staging). Saat ini Anda benar-benar tidak tahu berapa banyak orang yang akan terpengaruh oleh perubahan ini.

Bagaimanapun, berbicara dan berdebat tentang masalah ini memberi orang contoh yang baik tentang mengapa seseorang tidak boleh bergantung pada API internal, dan semoga beberapa pengelola paket pihak ketiga akan memperbarui proyek mereka karena apa yang telah dibicarakan di sini.

Jelas, ada banyak proyek Python penting yang membutuhkan kemampuan untuk memeriksa lingkungan mereka secara terprogram. Ini adalah hal yang benar-benar masuk akal untuk dapat dilakukan. Selain itu, dokumentasi tidak pernah memperingatkan untuk tidak melakukan ini - dan masih tidak! (Klik tautan Documents dari README repo ini!)

Tidak jelas bagi saya mengapa Anda harus memperingatkan hal ini. Penggunaan pip sebagai apa pun selain alat baris perintah sama sekali tidak didokumentasikan . Mencari dokumentasi saya tidak melihat referensi untuk mengimpor pip sama sekali . Ini seperti mengeluh karena Anda menautkan beberapa .so yang digunakan oleh Chrome dan mereka merusak kompatibilitas ABI.

Interpretasi SemVer yang biasa adalah bahwa itu berlaku untuk antarmuka publik yang didukung (dalam hal ini, CLI), bukan internal yang tidak berdokumen. Siapa pun yang menggunakan internal harus menyematkan versi pip mereka, karena dapat berubah secara sewenang-wenang.

Tidak ada yang bisa dibalik sebenarnya. Perbaikan backport untuk mencegah sebagian besar pengguna di macOS tidak dapat mengakses PyPI dalam waktu dekat memiliki bug saat diterapkan ke basis kode 9.0.x yang tampaknya hanya mengekspresikan dirinya dalam kondisi yang tidak didukung. Satu-satunya jalan ke depan adalah melakukan pekerjaan tambahan untuk mengatasi bug itu di seri 9.0.x. Seperti yang saya katakan jika saya dapat menemukan waktu, saya akan mencoba melakukannya, jika Anda ingin meningkatkan kemungkinan itu terjadi, maka berikan tambalan.

Dokumentasi tidak memperingatkannya karena tidak mungkin memberikan daftar lengkap tentang hal-hal yang mungkin dapat Anda lakukan dengan pip tetapi tidak didukung. Alih-alih, kami mengandalkan pendekatan yang cukup umum untuk mendokumentasikan apa yang didukung dan apa pun yang tidak didokumentasikan harus dianggap tidak didukung (dan jika Anda ingin mengandalkan sesuatu yang tidak didokumentasikan, buka masalah memintanya untuk didokumentasikan dan dengan demikian didukung ).

Jangka panjang kami cenderung bergerak menuju skema rilis berbasis tanggal untuk (semoga) menghilangkan kebingungan tentang apakah kami semver atau tidak.

dikirim dari iPhone saya

Pada 20 Maret 2018, pukul 11:02, Rich Jones [email protected] menulis:

Hei @dstufft , terima kasih telah bergabung. Utas ini menjadi sangat panas!

Pertama-tama, saya berterima kasih atas pekerjaan Anda! Saya tahu bahwa pemeliharaan adalah tugas tanpa akhir dan tanpa pamrih, dan saya membayangkan itu hanya akan menjadi lebih buruk ketika Anda mengelola proyek sebesar dan sepopuler pip!

Sekarang, untuk masalah yang dihadapi: Meskipun dua puluh pengelola telah melaporkan masalah ini sejauh ini, saya tahu itu sudah mempengaruhi ribuan orang - beberapa proyek yang terpengaruh sangat besar dalam hak mereka sendiri: Anaconda, OpenStack, SpaCy, Zappa, dan telah banyak puluhan ribu pengguna. Saya tahu saluran Slack kami dibanjiri diskusi tentang ini. (Secara harfiah, saat saya mengetik ini, masalah baru muncul.)

Jelas, ada banyak proyek Python penting yang membutuhkan kemampuan untuk memeriksa lingkungan mereka secara terprogram. Ini adalah hal yang benar-benar masuk akal untuk dapat dilakukan. Selain itu, dokumentasi tidak pernah memperingatkan untuk tidak melakukan ini - dan masih tidak!

Saya pikir situasinya sejauh ini adalah:

Mengingat format string versi, kita semua percaya bahwa pengelola pip mengikuti versi semantik
Pengelola pip merilis "tambalan" yang memperkenalkan perubahan besar-besaran
Perubahan ini tidak diumumkan dan tidak didokumentasikan - dan saya berasumsi, tidak terduga dan tidak disengaja
Sekarang, hanya memanggil pip impor segera merusak program, yang sangat memusuhi pengembang
Ini menyebabkan sakit kepala besar di seluruh ekosistem Python
Dokumentasi tidak (dan masih tidak - klik tautan Documents di README repo ini) memperingatkan agar tidak menggunakan pip secara terprogram.
Tidak ada pengumuman bahwa pip impor akan menyebabkan kerusakan ini dalam pembaruan PATCH - pengumuman itu datang untuk versi yang belum dirilis.
Perubahan ini bahkan tidak disebutkan di Changelog
Kami tidak ingin mengganti pip atau pengembang pip! Kami mencintai kamu!
..tapi kami tidak ingin hal seperti ini terjadi lagi!
..jadi kami ingin semver diikuti!
Kami akan sangat, sangat menyukai PATCH lain yang membatalkan perubahan besar ini!
Kebutuhan akan cara terprogram untuk memeriksa lingkungan di dunia pip>=10.0.0 adalah topik untuk diskusi lain, tetapi faktanya adalah bahwa kami tidak pernah diberitahu bahwa kami tidak boleh menggunakan pip secara terprogram di pip <=9 dunia, dan ada perubahan besar-besaran yang tidak diumumkan, dan kami benar-benar ingin melihatnya terbalik karena berdampak negatif pada ribuan orang.

Terima kasih lagi,
Kaya

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

@Miserlou

Mengingat format string versi, kita semua percaya bahwa pengelola pip mengikuti versi semantik

Sebagai seseorang yang sangat menentang semver, dapatkah Anda memberi tahu saya format apa string versi saya seharusnya untuk menghilangkan kebingungan ini? "Tiga angka putus-putus" tidak menyiratkan "mengikuti semver dengan ketat" bagi saya, jadi asumsi ini mengejutkan.

Menanggapi komentar ini : Apakah pip mematuhi semver atau tidak, atau berjanji untuk mematuhinya, penggunaan skema versi major.minor.micro masih membawa janji implisit dari beberapa jenis pengekangan di sekitar rilis mikro. Jika pin rilis yang kompatibel seperti ~= 9.0.1 tidak cukup untuk melindungi pengguna dari gangguan tak terduga dalam kompatibilitas mundur, satu-satunya alternatif aman yang tersisa adalah pencocokan versi biasa . Jika tidak ada niat untuk mendukung apa pun selain pencocokan versi, maka pip sebaiknya beralih ke skema versi gaya Chrome yang hanya memiliki satu komponen yang meningkat secara monoton.

Sunting: Saya melihat bahwa @dstufft sudah mengusulkan untuk pindah ke arah ini dengan mengadopsi versi berbasis tanggal. Saya pikir itu akan menjadi bagian yang tidak menguntungkan dari kerusakan tambahan yang dihasilkan dari insiden ini.

Jadi ya, sebagai pengguna proyek perangkat lunak yang digerakkan oleh sukarelawan, kita perlu menyeimbangkan harapan kita dengan apresiasi terhadap sifat hubungan pengguna/pengelola. Juga jelas bahwa rilis ini tidak dimaksudkan untuk membuat import pip tiba-tiba mulai gagal. Namun, di sisi lain, saya pikir masuk akal bagi orang-orang untuk frustrasi tentang regresi semacam ini yang terjadi dalam rilis mikro, dan merilis versi 9.0.3 yang memperbaiki masalah tampaknya merupakan solusi yang masuk akal.

Sebagai tambahan, saya dapat mereproduksi ini di virtualenv (2 atau 3, tidak masalah) dengan langkah-langkah berikut:

virtualenv -p python3 /tmp/pip
/tmp/pip/bin/pip install -e path/to/clone/of/pip/9.0.2
/tmp/pip/bin/pip install requests
/tmp/pip/bin/python

Kemudian, di dalam shell python:

>>> import requests
>>> import pip

Jika permintaan belum diimpor, maka import pip berhasil.

jeda tak terduga dalam kompatibilitas mundur

Tolong tunjukkan kepada saya di mana import pip didokumentasikan sebagai API stabil yang berada di bawah janji kompatibilitas mundur yang kami buat? Saya ingin memastikan bahwa saya menghapus dokumentasi tersebut karena kami dengan tegas tidak mendukung penggunaan itu.

Kecuali Anda berpendapat bahwa sama sekali tidak ada yang dapat merusak, bahkan penggunaan yang tidak didukung dan belum teruji. Dalam hal ini Anda mungkin ingin menyematkan == karena sama sekali tidak diketahui apa yang mungkin Anda gunakan pada saat itu, dan setiap perubahan berpotensi menjadi perubahan yang merusak bagi seseorang (wajib xkcd ).

pip adalah manajer paket Python. Python adalah bahasa pemrograman. Orang perlu memeriksa lingkungan mereka secara terprogram. 1+1=2.

Sangat masuk akal bagi orang untuk berasumsi bahwa ini adalah cara yang benar untuk melakukannya. Tidak ada - dan _ masih tidak ada _ - apa pun dalam dokumentasi yang mengatakan _not_ untuk melakukan ini. Sebagai pengingat, ada lebih dari 700.000 aplikasi yang sampai pada kesimpulan yang sama ! Juga - tidak ada cara lain untuk melakukannya!

Hanya karena sesuatu tidak didokumentasikan di ReadTheDocs tidak berarti itu dilarang - kita semua menemukan dan menggunakan proyek setiap hari yang hanya menyediakan kode dengan cara ini.

Jika ada, fakta bahwa pip bahkan _memiliki_ antarmuka baris perintah sama sekali tampaknya merupakan indikasi yang baik bahwa itu dapat digunakan sebagai perpustakaan, karena sudah memiliki klien Python!

Selain itu, kita tidak berbicara tentang API pribadi yang diberi namespace dengan _ , seperti konvensi, atau bahkan metode publik tertentu, kita hanya berbicara tentang _hanya memanggil import_ yang menyebabkan kegagalan bencana ini.

Tidak ada - dan masih belum ada - apa pun dalam dokumentasi yang mengatakan untuk tidak melakukan ini.

https://pip.pypa.io/en/latest/user_guide/#using -pip-from-your-program

Jika Anda mengklik tautan "Docs" dari _this very repo_, Anda tidak akan sampai ke halaman itu. Tidak ada yang referensi terbaru. Tautan Anda sendiri ke dokumentasi tidak tertaut ke yang terbaru. Tidak ada cara untuk sampai ke halaman itu. Semuanya berjalan stabil, yang tidak termasuk bagian itu.

@Miserlou Saya pikir catatan itu adalah kebaikan bagi orang-orang yang entah bagaimana berpikir bahwa mereka harus mengimpor internal alat baris perintah hanya karena kebetulan diimplementasikan dengan Python dan internal itu dapat diimpor.

Saya mendapatkan bahwa Anda memiliki interpretasi yang berbeda dari antarmuka publik pip dari saya, para pengembang dan kebanyakan orang yang menganggap pip sebagai program CLI, tapi apa bahaya sebenarnya dari ini? Cukup pin pip != 9.0.2 dan selesai.

Jelas bahwa kita semua berada di halaman yang sama pada saat ini tentang apa yang merupakan dan bukan bagian dari API publik yang didukung, dan tidak ada yang dapat dilakukan sekarang untuk secara surut membuat semua orang memperhatikan.

Sejujurnya, pengelola pip sudah menyatakan bahwa JIKA waktu mengizinkan, mereka akan mencoba memperbaiki masalah ini, meskipun setiap orang didorong untuk mengajukan permintaan tarik untuk mempercepat.

Saya pikir untuk saat ini yang bisa kita lakukan adalah membuat perpustakaan pihak ketiga mengetahui masalah ini, dan mengarahkan mereka ke masalah ini. Perpustakaan pihak ketiga jangka panjang perlu memperbaiki masalah ini, dan mudah-mudahan dengan cara di mana mereka tidak import pip , tetapi memanggil pip melalui baris perintah (dengan subproses atau perintah python serupa).

Saya percaya bahwa diskusi ini tidak mungkin produktif dan tidak ada tambahan yang bisa dikatakan. Ada:

• Deskripsi masalah yang memadai.
• Kemungkinan pekerjaan yang dapat dilakukan seseorang jika mereka mengalaminya.
• Alasan mengapa kami tidak menganggap ini sebagai perubahan yang melanggar sesuai pedoman kompatibilitas mundur kami.
• Pernyataan bahwa saya akan berusaha mencari waktu untuk memperbaikinya (meskipun tidak ada janji tentang itu).
• Ajakan Bertindak yang dapat dilakukan jika seseorang yang terpengaruh oleh ini ingin membuatnya lebih mungkin bahwa 9.0.3 ada dengan perbaikannya.

Pada titik ini diskusi tidak memiliki tujuan nyata kecuali untuk lebih membuat frustrasi semua orang yang terlibat, jadi saya mengesampingkan masalah ini untuk saat ini. Masalah ini akan ditutup baik setelah rilis 10.0, atau 9.0.3. Jika seseorang benar-benar berusaha dalam Ajakan Bertindak, mereka dipersilakan untuk membuka permintaan tarik, atau mengajukan perbedaan tentang masalah ini.

Untuk membuat mantra jangan-impor-pip ini lebih terlihat, bagaimana dengan mengganti nama namespace menjadi "_pip". Ini menunjukkan bahwa keseluruhan tidak untuk penggunaan umum pada tingkat nama.
Juga, akan lebih mudah untuk memberi tahu kode pemeriksaan otomatis untuk tidak melihat hal-hal yang dimulai dengan garis bawah. Nah, yang terakhir akan membutuhkan perubahan dalam kode inspeksi keterlibatan juga. Tetapi setidaknya ada peluang untuk mengotomatiskannya (berdasarkan konvensi) tanpa mengelola daftar hitam.

Oke, terakhir saya bersumpah-- pip 10 sudah memindahkan semua kode yang relevan ke pip._internal (kami tidak menggunakan _pip karena itu akan merusak python -m pip , yang didukung).

Adakah yang bisa memverifikasi jika https://github.com/pypa/pip/pull/5100 menyelesaikan ini untuk mereka?

Gores itu, saya pikir #5100 salah, bisakah Anda memverifikasi https://github.com/pypa/pip/pull/5101 sebagai gantinya.

@dstufft Saya dapat mengonfirmasi, perbaikan di # 5101 memecahkan masalah bagi saya.

Terima kasih @dstufft atas waktu Anda dalam menangani ini. Saya akan bekerja dengan tim Anaconda untuk mengomunikasikan masalah ini dan membantu mereka menjauh dari mengimpor pip.

Sebagai catatan di utas ini, #5101 memecahkan masalah saya juga.

Ditto, #5101 memungkinkan impor bekerja di dalam alat kami. Penghapus peringatan: Saya belum menguji pip yang ditambal atau alat kami secara ekstensif.

Ini harus diperbaiki di 9.0.3.

Terima kasih atas resolusi cepat, dari seseorang yang tidak pernah menulis import pip dalam hidup mereka tetapi merupakan konsumen paket yang melakukannya. Setelah membaca utas ini terdengar seperti banyak aplikasi telah mengimpor pip, tanpa sadar bertentangan dengan praktik terbaik, dan banyak pengembang dan pengguna berpotensi dipengaruhi oleh v9.0.2 dan v10.

Saya kedua/ketiga/N peringatan penghentian yang tepat ditambahkan untuk membuat segalanya lebih lancar. bahkan mungkin posting pypi.python.org?

Hore! Terima kasih untuk ini!

Saya juga sangat menyukai peringatan penghentian, dan, yang lebih penting - instruksi yang tepat tentang cara memeriksa lingkungan python secara terprogram di dunia pip10! Jelas ada kebutuhan untuk itu, mengingat lebih dari 700.000 aplikasi terpengaruh oleh bug ini.

pip list --format=json ?

Pertama-tama terima kasih semua yang berkontribusi pada orang pip karena itu benar-benar mencakup semua kasus penggunaan saya dengan beberapa opsi dan argumen yang ramah pengguna.

Karena "perilaku tidak terdefinisi yang diadopsi secara luas dan berguna" ini, apakah kita perlu menjadikan piplib sebagai libgit2 untuk git? Harap dicatat bahwa libgit2 tidak membagikan kode apa pun dengan git, dan dikelola oleh grup lain dari git. Dan itu bagus untuk ekosistem git. Mungkin piplib akan membahas beberapa kasus penggunaan menarik yang tidak kami duga.

Ini cerita serupa: https://public-inbox.org/git/1267957655.3759.29.camel@mattotaupa/T/

@drunkwcodes Saya menduga bahwa apa yang Anda usulkan sudah diimplementasikan dalam paket yang ada yang disebutkan dalam dokumentasi pip , packaging , setuptools , dan distlib . Sejauh yang saya tahu dari utas ini, tidak ada masalah dengan celah fungsionalitas, tetapi beberapa orang memiliki masalah dengan alat yang mencoba mengimpor dan memeriksa setiap modul, dan memperlakukan kegagalan impor sebagai kesalahan fatal.

Menurut saya, alat semacam itu dapat mengatasi masalah ini dengan membungkus pernyataan impor dalam blok coba/kecuali, tetapi itu juga tampak seperti preseden yang dipertanyakan untuk ditetapkan. Namun, mengingat rilis pip 9.0.3, saya pikir mungkin tidak ada waktu untuk memperdebatkan masalah impor kecuali masalah terjadi lagi di pip 10. Bagaimanapun, selama pengelola tidak berusaha keras untuk membuat import pip gagal, atau tolak tambalan yang memperbaiki kegagalan tersebut, akan ada landasan bersama untuk berdiri.

@sruggier Paket yang disebutkan semuanya bagus, dan WheelFile.install() juga membutuhkan lebih banyak promosi. Tapi layanan satu atap pip.main() yang diberikan tidak tergantikan dengan semua hal di atas. Ini masih layak untuk dicoba.

Yang paling penting adalah saya berharap kebutuhan ini dipegang oleh proyek lain, dan pip10 akan tiba dengan lancar tanpa jaminan tambahan. Penghentian dan meminimalkan basis kode adalah inti dari rilis besar.

Detail implementasi konkret untuk "perangkat lunak" infrastruktur permanen itu konyol. Anda tidak dapat menilai pengelola berdasarkan kasus penyalahgunaan yang didokumentasikan dan menahan roda pip.

Jika Anda bersikeras untuk menggunakan pip sebagai lib, banyak asumsi yang perlu dipertimbangkan kembali.

@drunkwcodes Untuk memperjelas, pip.main() adalah penggunaan termudah untuk diganti - Anda hanya perlu menggunakan subprocess.run([sys.executable, '-m', 'pip', <rest of args>]) .

Juga, alasan WheelFile.install() tidak dipromosikan adalah karena proyek wheel juga menyatakan bahwa mereka tidak menyediakan API yang dapat dilihat pengguna - kami awalnya menyebutkan wheel di pip docs, tetapi menghapusnya atas permintaan mereka. PEP roda cukup jelas tentang cara Anda memasang roda - tidak sulit untuk diterapkan dalam modul pihak ke-3.

Saya menghargai pekerjaan yang Anda semua lakukan di pip, dan tahu itu tidak mudah. Tapi sebagai catatan:

Saya sedikit kecewa karena orang belum beralih dari pip impor. Orang-orang yang terkena masalah ini masih perlu bersiap untuk pip 10

spaCy telah pindah dari import pip . Tetapi beberapa orang masih menggunakan spaCy 1, yang mengimpor pip --- dan untuk alasan yang jelas, tidak menyematkan pip ke rilis patch. Jika perubahan terjadi pada v10, versi lama kami tidak akan terpengaruh. Kami baru saja mengeluarkan perbaikan terbaru untuk mengatasi ini.

instruksi yang tepat tentang cara memeriksa lingkungan python secara terprogram di dunia pip10

Apa posisi PyPA di distlib? Pip jelas menggunakannya dalam beberapa kapasitas, tetapi juga menggunakan pengemasan, yang dimaksudkan untuk dihentikan oleh distlib.

Jika tidak ada posisi resmi, maka setidaknya pemikiran dan pendapat terkini dari pengelola inti pip akan sangat dihargai. Jika ada diskusi yang relevan tentang topik ini di tempat lain, petunjuk sederhana untuk diskusi lain sudah cukup baik bagi saya.

Saya tidak tahu bahwa distlib tidak lagi menggunakan kemasan. Disebutkan "distutils2/packaging" tetapi distutils2 adalah sesuatu yang berbeda.

Pandangan pribadi saya adalah bahwa distlib dan pengemasan adalah hal yang sangat masuk akal untuk digunakan. Anda harus mengevaluasinya sendiri untuk memastikan mereka memenuhi kebutuhan Anda, tentu saja, sama seperti ketergantungan lain yang Anda andalkan.

Mungkin mencela terlalu kuat kata itu. Sumber pemahaman saya saat ini:

https://distlib.readthedocs.io/en/latest/overview.html#distlib -evolved-out-of-packaging

Ah, itu "kemasan" yang berbeda - itu adalah modul stdlib yang diusulkan yang dimaksudkan untuk menggantikan distutil. Ini benar-benar berbeda dari proyek PyPI packaging . Mungkin ada baiknya meminta proyek distlib untuk mengklarifikasi perbedaan itu sedikit lebih baik.

Mungkin ada baiknya meminta proyek distlib untuk mengklarifikasi perbedaan itu sedikit lebih baik.

Sudah selesai :) Lihat: https://bitbucket.org/pypa/distlib/issues/100/clarify-project-positioning-and-status

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