<p>pip install --editable dan pip install bentrok untuk paket namespace</p>

Dibuat pada 14 Mar 2011  ·  41Komentar  ·  Sumber: pypa/pip

Paket namespace yang diinstal dapat diedit dan paket lain yang diinstal secara teratur tidak berfungsi bersama dengan baik.

auto-locked bug

Komentar yang paling membantu

Bagi siapa pun yang penasaran, berikut adalah daftar lengkap bagaimana paket namespace bekerja di pip install , pip install -e , python setup.py install , dan python setup.py develop :

https://github.com/jonparrott/namespace-pkg-tests/blob/master/table.md

tl; dr: Anda dapat menggunakan pip install -e dan python setup.py develop selama setiap paket lain di namespace Anda telah diinstal menggunakan pip .

Semua 41 komentar

Masalah yang sama di sini :(

Saya telah memposting kode untuk menguji bug ini: http://public.hg.stephane-klein.info/hgwebdir.cgi/test_pip_namespace_bug_3/

Akar masalah di sini adalah bahwa setuptools menyertakan dua metode untuk membuat paket namespace berfungsi: metode __init__.py (yang didokumentasikan, dan dapat digunakan oleh manusia), dan metode file ...-nspkg.pth , yaitu hanya digunakan dengan --single-version-externally-managed (yang digunakan pip). Kedua metode tersebut tidak kompatibel satu sama lain.

Setelah berdiskusi dengan mitsuhiko dan lainnya di IRC, tampaknya solusi terbaik (sebagian) untuk pip adalah dengan "pip install -e" menambahkan versi modifikasi dari setuptools standar ... file nspkg.pth untuk setiap paket yang dikembangkan . (Modifikasi yang diperlukan adalah dengan menggunakan jalur develop egg-link alih-alih sitedir, dan untuk melewati pemeriksaan init .py sepenuhnya, karena paket namespace yang diinstal develop akan memiliki init .py). Ini berarti pip setidaknya akan kompatibel dengan dirinya sendiri (paket namespace pip-instal dan pip-editable-instal akan bekerja sama). Paket namespace yang diinstal pip dan setuptools / didistribusikan-diinstal tidak akan kompatibel.

Saya baru-baru ini digigit oleh ini juga. Masalah lain yang disebabkan olehnya adalah karena __init__.py tidak diinstal untuk paket namespace (dengan asumsi Anda hanya menginstal satu paket di namespace itu, dan itu diinstal --single-versi-dikelola secara eksternal) itu mematahkan pencarian modul hidung. Mungkin itu salah hidung, tapi saya masih berpikir masuk akal untuk mengharapkan jika direktori tidak berisi __init__.py bahwa itu bukan paket Python.

Saya pikir pip entah bagaimana harus mematikan hal nspkg.pth sama sekali dan menginstal __init__.py . Selama paket itu sendiri dirancang dengan benar (mis. __init__.py kosong kecuali untuk extended_path / menyatakan_space) seharusnya tidak menjadi masalah. --single-version-external-managed dirancang dengan mempertimbangkan pemaket sistem, tetapi mereka tidak akan menggunakan pip sejak awal. Jadi saya bertanya-tanya apakah ada cara untuk menonaktifkan perilaku ini sama sekali tanpa terlalu mengganggu.

+1 untuk beralih dari '--single-version-externally-managed': opsi itu sama sekali tidak dimaksudkan untuk kasus penggunaan pip. Jika pip tidak dapat melakukan pekerjaan instalasi sebaik easy_install, apa tujuannya?

Beralih dari --single-version-externally-managed seluruhnya tidak akan terjadi; pemasangan datar adalah sebuah fitur. Beralih darinya dalam kasus paket namespace saja adalah kemungkinan yang akan saya pertimbangkan, untuk menghindari masalah ini. Saya tidak menyukainya, tetapi sepertinya tidak ada pilihan yang bagus, mengingat ketidakcocokan yang melekat antara dua jenis dukungan paket namespace yang dibangun di setuptools / distribut.

Mengatakan bahwa --single-version-externally-managed "tidak dimaksudkan untuk kasus penggunaan pip" adalah suatu tempat antara salah dan red herring. Bendera ini dimaksudkan untuk memungkinkan penginstalan versi tunggal datar, yang dikelola oleh beberapa alat selain easy_install. Untuk itulah pip menggunakannya; fakta bahwa pembuat setuptools pada awalnya (dan secara keliru) mengira bahwa hanya pemaket sistem yang akan tertarik dengan fitur seperti itu tidaklah relevan.

Kerusakan di sini adalah bug inheren dalam teknik yang digunakan setuptools untuk paket namespace dengan flag tersebut, dan bug tersebut juga ada saat flag digunakan oleh audiens yang awalnya dimaksudkan, pemaket sistem (saya pertama kali melihat bug dalam interaksi antara " setup.py develop "paket terinstal dan paket namespace terinstal paket sistem).

Saya mengalami bug ini juga. Saya rasa ini adalah salah satu bug yang tidak dapat dipecahkan yang akan tetap ada. Baiklah.

Saya akan menerima tambalan untuk menghindari --single-version-externally-managed ketika paket namespace terlibat, yang menurut saya akan menyelesaikan masalah ini. Saat ini saya tidak punya rencana untuk menulis tambalan itu.

Mengapa tidak ada opsi yang bisa kita berikan ke pip install untuk tidak menggunakan --single-version-externally-managed ? Saya menguji dengan berkomentar bahwa di ./pip/req.py:568 dan semua paket sekarang diinstal ke dir telur, seperti halnya easy_install. Kadang-kadang saya ingin melakukan ini jika saya menggunakan pip dan easy_install sehingga site-packages tidak bercampur dengan beberapa paket instalasi datar dan beberapa tidak.

Saya tidak melihat masalah dengan opsi --egg untuk menyisih dari --single-version-externally-managed .

https://github.com/k4ml/pip/commit/93cd6b16207d2eba201a7fc3126624b616f5e6f9

Dapatkah seseorang berkomentar jika saya bergerak ke arah yang benar? Ini adalah pertama kalinya saya meretas kode pip jadi ini didasarkan pada beberapa menit saya sekilas ke sebagian darinya, hanya untuk mendapatkan pip install --egg somepackages menginstal semuanya ke dalam satu telur dir.

Dapatkah seseorang berkomentar jika saya bergerak ke arah yang benar?

Kelihatannya bagus untuk saya, hanya perlu tes. Tes sebagian besar tingkat tinggi
tes integrasi menggunakan ScriptTest, harus mudah untuk menulis satu berdasarkan
contoh yang ada. Dalam hal ini Anda hanya ingin menguji pemasangan itu
paket sampel menghasilkan file .egg, bukan penginstalan datar, dalam format
paket situs. Anda harus menginstal paket dari sistem file lokal,
bukan jaringan: tests/packages/FSPkg mungkin akan berfungsi dengan baik. Menambahkan
tes ke tests/test_basic.py tidak apa-apa.

Terima kasih!

Permintaan tarik - https://github.com/pypa/pip/pull/541

Saya juga berpikir untuk memungkinkan pengesetan flag ini di pip.conf. Apa yang kamu pikirkan tentang itu?

Saya juga berpikir untuk memungkinkan pengesetan flag ini di pip.conf. Apa yang kamu pikirkan tentang itu?

Mari kita bahas tentang pull request.

Permintaan tarik gabungan # 541, yang menyediakan satu solusi. Terima kasih @ k4ml!

Perhatian: opsi --egg , yang ditambahkan untuk memperbaiki masalah ini berpotensi dihapus, tanpa ada solusi alternatif yang ditawarkan. Lihat diskusi di # 1749

Berikut ini skrip untuk mereproduksi masalah ini

https://gist.github.com/Ivoz/d9bff05069e0ec53e6ea

Saya bukan penggemar berat solusi --egg, tetapi perlu ada solusi yang tidak terlalu rumit untuk ini.

tanpa solusi, saat mengembangkan, saya tidak dapat menggunakan --editable sekali dan kemudian hanya mengedit dan menguji. setiap kali saya menyimpan kode saya, saya harus menjalankan pip install -I --no-deps . yang menjadi sangat tua dan rapuh (baca: terkadang saya lupa).

bagian dari masalah dengan cara seluruh masalah ini terwujud adalah bahwa ia diam. Anda hanya tidak dapat mengimpor modul meskipun telah diinstal dan pip memberi tahu Anda bahwa modul itu ada.

Ini akan menjadi langkah positif hanya untuk membuat pip mengeluh jika mencoba menginstal paket yang dapat diedit sebagai bagian dari namespace di mana paket yang tidak dapat diedit di namespace itu sudah diinstal. atau sebagai alternatif untuk mengeluh jika mencoba menginstal paket yang tidak dapat diedit yang merupakan bagian dari namespace di mana paket yang dapat diedit di namespace itu sudah diinstal.

Pilihan lain, jika kita benar-benar ingin membuat paket namespace dan penginstalan yang dapat diedit selalu berfungsi, bisa jadi jika paket namespace diinstal sebagai dapat diedit, pip dapat mengatur ulang semua paket lain di namespace itu sebagai dapat diedit di samping paket yang diinginkan.

Saya mengirimkan 2 proposal untuk memperbaiki masalah ini di setuptools https://bitbucket.org/pypa/setuptools/issue/250/develop-and-install-single-version. FYI.

menempatkan

impor pkg_resources; pkg_resources.fixup_namespace_packages ('')

dalam file .pth di paket-situs tampaknya cukup untuk membuat pip install -e hal-hal yang diinstal bekerja dengan benar.

Ini juga mempengaruhi dua paket dengan namespace teratas yang sama dengan keduanya diinstal sebagai dapat diedit. Pemasangan paket kedua rusak.

Kami menggunakan namespace global untuk semua aplikasi kami dan dengan demikian masalah ini agak sulit (+ masalah bahwa setuptools tidak mendukung roda, yang diperlukan karena kurangnya kompiler pada platform penyebaran windows kami). Juga semua solusi yang direkomendasikan tampaknya gagal dalam pengaturan kami dengan Python 3.4.

Setelah menyadari bahwa pip install -e menjalankan setup.py develop untuk proyek yang seharusnya dapat diedit, saya terhubung ke prosedur setuptools dan menulis file * .pth, yang "memperkenalkan" paket namespace saat proses python dimulai. Ini menyelesaikan masalah bagi kami saat menggunakan setuptools 18 dan pip 7.1.0.

Contoh file setup.py, yang menunjukkan bagaimana ini bisa dicapai, dapat ditemukan di sini:
https://gist.github.com/cbrand/a1624ac3e9c81ce45fcb

Saya harap ini juga bermanfaat bagi orang lain.

Saya mengalami yang ini hari ini juga, dan itu menghalangi saya untuk beralih dari buildout ke virtualenv + pip.

Saya membuat demo kecil yang mendemonstrasikan masalahnya. Untuk mengujinya, buka paket .tar.gz dan jalankan skrip {{run-me}} di dalamnya. Mungkin berguna saat menguji perbaikan.

Saya juga membahas masalah ini.

Ketika mencoba untuk memahami, saya menemukan solusi yang diusulkan oleh @carljm di https://github.com/pypa/pip/issues/3#issuecomment -1659959, yaitu _have "pip install -e" tambahkan versi standar yang dimodifikasi setuptools ... file nspkg.pth untuk setiap paket yang dikembangkan_.

Saya bereksperimen dengan pendekatan itu secara manual dan tampaknya berhasil dengan baik. Tampaknya ini sekaligus akan memecahkan pertanyaan tentang pohon sumber dangkal dengan paket namespace yang hilang seperti yang dijelaskan di # 3160.

Jadi saya bertanya-tanya apakah pendekatan itu masih dianggap valid, jika ada upaya untuk mengimplementasikannya, dan apakah patch untuk ini akan dipertimbangkan?

Jadi ... tidak ada harapan yang satu ini diperbaiki dalam waktu dekat?

Beberapa efek samping pkg_resources.get_distribution() membuat impor berfungsi. Kami menemukan ini ketika kode yang memuat titik masuk bekerja dengan benar sementara shell python gagal.

Ini juga dapat menjelaskan mengapa shell ipython tidak memiliki masalah dalam mengimpor paket.

Saya kagum bug ini masih terbuka tanpa penyelesaian yang jelas setelah 5 tahun.

Jika tugas Anda adalah merekatkan kerangka menjadi satu kerangka terpadu, pip membuat pekerjaan Anda payah. Sejujurnya saya tidak tahu bagaimana melanjutkan pekerjaan saya karena bug ini.

Ini adalah masalah yang sulit diperbaiki terutama dalam proyek yang dilakukan secara sukarela,
Jangan ragu untuk menambahkan dukungan yang diperlukan di setuptools sehingga pip dapat melakukannya dengan benar

Brandon Github [email protected] menulis:

Saya kagum bug ini masih terbuka tanpa penyelesaian yang jelas setelah 5 tahun.

Ya, sayang sekali.

Jika tugas Anda adalah merekatkan kerangka kerja menjadi satu kerangka terpadu,
pip membuat pekerjaanmu payah. Sejujurnya saya tidak tahu bagaimana melanjutkannya
pekerjaan saya karena bug ini.

Saya baru-baru ini menerapkan peretasan fixup_namespace_packages ('') yang disebutkan di atas dan
tampaknya berhasil: Saya membuat z.pth di dalam paket situs venv
hanya berisi import pkg_resources; pkg_resources.fixup_namespace_packages('')

Patut dicoba, IMHO.

Hanya benjolan lain di sini!

Saya hanya akan menyebutkan bahwa setiap paket sumsum menggunakan namespace (beberapa paket mengisi hingga empat atau lima) dan bahwa masalah khusus ini telah menjadi sedikit kutukan bagi keberadaan saya ketika harus membantu pengguna baru mengatur dengan alat pengembangan . Saya hanya memiliki 60 paket yang malu menggunakan ini. Uang kertas entry_points juga menarik, karena hampir setiap paket yang berkontribusi ke namespace juga menyumbang entry_points .

Pendekatan pip hanya berfungsi, menurut pengalaman saya, jika paket _every_ diinstal, dapat diedit, dari disk, yang bekerja sama pada namespace. Jika satu paket dipasang tidak dapat diedit melalui pip, seluruh bola benang mulai terurai dengan beberapa gejala yang sangat, sangat tumpul bagi pengguna baru. (Seperti modul yang dapat diimpor sebentar-sebentar; pemeriksaan kewarasan umum untuk mengimpor namespace induk dan memverifikasi namespace.__path___ telah dengan cepat mengidentifikasi paket yang bermasalah dalam pengujian.) Mencampur paket yang terinstal dengan benar pip dan murni setup.py develop 'd sumber yang (menghindari pip) tampaknya berfungsi.

Kami juga tampaknya bisa masuk ke situasi aneh di mana satu paket yang berkontribusi ruang nama dapat diinstal dengan tiga cara berbeda, terkadang semuanya secara bersamaan. (Panggilan berulang ke pip uninstall , setiap menemukan lebih banyak file, sangat lucu untuk dilihat dan disayangkan.) Instalasi ketergantungan saat menggunakan pip install -e tampaknya juga tidak konsisten. Dalam sebagian besar kasus kami berakhir dengan ruang nama yang dibongkar dengan benar (diinstal), file pth-link (diinstal dapat diedit), dan dalam satu kasus kami entah bagaimana berhasil mendapatkan .egg -zip, meskipun zip_safe menjadi False pada paket dependen itu dan tidak ada distribusi .egg yang disediakan di Pypi.

Frustrasi dengan masalah namespace mencapai puncaknya setelah keempat kalinya lingkungan virtual dihidupkan untuk memulai kembali dari awal. ;)

Bukan solusi tapi saya hanya menaruh beberapa catatan. Saat menggabungkan antara paket 'editable', paket dengan namespace dan paket normal, saya lebih beruntung dengan buildout + mr.developer.

Meskipun perbaikan hack

Setelah bermain-main dengan pip install dan mode editable, saya mendapatkan ide yang sama dengan @carljm (menambahkan file -nspkg.pth untuk setiap paket yang dapat diedit), tetapi tampaknya tidak ada yang menerapkannya (atau apakah ini sekarang sudah usang - opsi -egg?).

Apakah ini masih menjadi masalah pada versi python yang lebih baru dengan PEP420 diimplementasikan? (baca: apakah akan membantu jika beralih ke versi python yang lebih baru?)

Menggunakan gaya PEP420 secara efektif membantu saya beberapa kali sekarang menggunakan mode editable.

Sayangnya itu datang dengan kesalahannya sendiri: misalnya, setuptools ' find_packages tidak mendukungnya , jadi paket saya yang lebih baru berisi peretasan berikut:

-    packages=find_packages('src'),
+    packages=['toplevel.child.' + package
+              for package in find_packages('src/toplevel/child/')],

sepertinya tidak ada yang menerapkan penambahan -nspkg.pth untuk setiap paket yang dapat diedit.

Lihat Setuptools 31 yang menambahkan dukungan untuk fitur ini, dan juga hidup berdampingan dengan paket PEP-420 di Python 3.5+.

Bagi siapa pun yang penasaran, berikut adalah daftar lengkap bagaimana paket namespace bekerja di pip install , pip install -e , python setup.py install , dan python setup.py develop :

https://github.com/jonparrott/namespace-pkg-tests/blob/master/table.md

tl; dr: Anda dapat menggunakan pip install -e dan python setup.py develop selama setiap paket lain di namespace Anda telah diinstal menggunakan pip .

Saya akan menutup masalah ini. Tampaknya setuptools 31 telah memperbaiki ini untuk skrip reproduksi kita, dan di luar itu tidak ada yang bisa dilakukan pip di sini.

@jonparrott
Versi pip dan alat setup apa yang digunakan untuk mendapatkan hasil di https://github.com/jonparrott/namespace-pkg-tests/blob/master/table.md ?

@dstufft Meskipun saya menghargai bahwa ini seharusnya diperbaiki, saya ingin melihat tabel kompatibilitas @jonparrott dijalankan kembali sebagai bukti. Saya berharap yang terbaik, rencanakan yang terburuk pada tiket yang berusia hampir 7 tahun dan memiliki skenario kegagalan yang luas cakupannya. Keyakinan tidak tinggi mengingat sejarah panjang masalah ini, dan menjalankan ulang suite nox sendiri, kegagalan akan menunjukkan kurangnya resolusi aktual.

Dalam contoh @jonparrott , kasus yang gagal dapat disaring menjadi "menggunakan python setup.py install secara langsung (tidak termasuk kegagalan PEP 420 pada Python 2, yang diharapkan). Ini gagal bahkan dalam kasus di mana pip tidak terlibat sama sekali (seperti python setup.py install + python setup.py develop ).

Tiket ini untuk kombinasi pip install . dan pip install -e atau python setup.py develop .

Grafik yang telah diposting oleh @jonparrott menunjukkan bahwa tiket ini telah diselesaikan dan masalah yang tersisa di sini adalah masalah dengan python setup.py install dan bukan dengan pip.

Saya baru saja menjalankan ulang pengujian saya dan semuanya sama seperti saat saya menjalankannya. Saya setuju dengan penilaian @dstufft - pip telah melakukan semua yang dapat dilakukan untuk menyelesaikan masalah ini.

@ piotr-dobrogost pengujian menggunakan versi terbaru dari keduanya. Pada tulisan ini, pip 9.0.1 dan setuptools 34.3.2.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat