Sepakat. Perilaku pip saat ini untuk tautan ketergantungan benar-benar menyebalkan.

4295

3610

[Tulis di #3939, pindahkan komentar saya ke sini]

Jadi, inilah masalah utamanya: Jika saya tidak ingin menggunakan file requirements.txt (karena, katakanlah, saya ingin dependensi deklaratif semua ditentukan dalam setup.cfg ), bagaimana saya bisa menentukan a URL sebagai ketergantungan?

Ini tidak berfungsi:

[options]
install_requires = 
  requests==2.18.4
  https://github.com/example/example_lib/archive/master.zip

Saya juga berpikir tautan ketergantungan itu aneh dan bagus untuk dijatuhkan, tetapi secara kanonik bagaimana kasus penggunaan ini disajikan jika tidak dengan itu?

Masalah lainnya adalah dependency_links tampaknya tidak dapat ditentukan di setup.cfg, hanya sebagai argumen setup.py. Jika mereka tidak digunakan lagi, itu harus diperbaiki.

Apakah ada berita tentang ini? Apakah ada alternatif yang sedang berlangsung? ketergantungan_links_ tampaknya menjadi satu-satunya pilihan untuk distribusi perpustakaan internal/pribadi.

Alih-alih mencelanya, itu harus diperbaiki, banyak orang lupa atau bingung karena mereka lupa memasukkan nama-versi perpustakaan di install_requires dan tautan ketergantungan yang berisi tarbal bersama dengan telur. Sebagai alternatif, saya ingin melihat bahwa @jleclanche telah menyarankan, tautan sederhana ke tarball di install_requires (menentukan telur bisa jadi opsional).

Saya tidak berpikir kita sendirian: https://stackoverflow.com/questions/3472430/how-can-i-make-setuptools-install-a-package-thats-not-on-pypi

Alat @robertour seperti devpi mendukung pendekatan yang lebih jelas sejak bertahun-tahun sekarang

@dstufft btw - saya ingin berpendapat bahwa keberadaan devpi menunjukkan solusi yang lebih bersih untuk masalah yang membuat tautan ketergantungan tidak diperlukan

Warisan indeks IMHO + daftar putih/daftar hitam lebih konsisten dan lebih dapat dipahami di tingkat operasi

@RonnyPfannschmidt , terima kasih atas sarannya, sepertinya saya melewatkan sesuatu yang penting (diskusi tentang penghentian ini telah berlangsung terlalu lama) tetapi secara umum saya tidak bisa lebih setuju dengan komentar ini dari reddit :

devpi bisa menjadi solusi, tetapi membawa layanan lain ke dalam game yang membutuhkan pemeliharaan dan harus menunggu beberapa administrator untuk menyiapkan, tidak akan membuat saya segera bekerja. Kami juga masih perlu membangun paket dan kemudian menempatkannya ke devip (atau memiliki fitur devpi untuk melacak repositori git??)

Idealnya, saya ingin alternatif yang tidak akan membawa saya lebih dari menambahkan file di perpustakaan saya, atau beberapa baris di setup.py.

Saya pada dasarnya tidak mengerti keputusan mendasar untuk menghapusnya, saya dapat melihat bagaimana hal itu dapat menyebabkan praktik buruk dan ketidakamanan, tetapi selama itu disimpan untuk penggunaan internal, itu seharusnya tidak menjadi masalah besar.

4175 berarti dukungan URL PEP 508 akan ada di pip 10. Saya pikir ini bisa ditutup.

Pikiran @pfmoore @dstufft?

Saya pikir https://github.com/pypa/pip/pull/4175/commits/86b07792e7ae762beeaeb471ab9db87e31bc285d berarti sintaks @ tidak dapat digunakan untuk dependensi, jadi ini berarti #4175 bukan solusi untuk masalah ini . Komentar di sana adalah bahwa kami tidak boleh menerapkan dukungan @ untuk dependensi sampai PyPI dapat memblokir unggahan yang menggunakannya (karena kami tidak ingin menginstal sesuatu dari PyPI untuk dapat mengambil barang dari URL arbitrer , mungkin).

Seharusnya tidak ditinggalkan sampai ada alternatif, yaitu dukungan PEP 508. Sampai saat itu, terlalu banyak orang yang menggunakannya.

Apa alur kerja yang tepat untuk ini?

Katakanlah ada perpustakaan yang perlu saya tambahkan fitur. Saya garpu di Github. Fitur tidak akan digabungkan dalam waktu dekat, jadi saya memiliki alat yang saya atur untuk menggunakan garpu Github saya alih-alih PyPi.

Sekarang semua pengguna saya harus menambahkan --process-dependency-links saat menginstal alat saya dengan pip, yang merupakan flag yang sudah usang dan bahkan pernah dihapus?

Apakah ada beberapa opsi di setup.py yang saya lewatkan atau benar-benar tidak ada jalan keluarnya? Sepertinya satu-satunya cara yang layak untuk melakukan ini adalah dengan mendorong paket pypi bercabang. Itu hanya akan menambah kebingungan pengguna setelah permintaan tarik Anda digabungkan.

Mari kita datang sekitar untuk ini.

--process-dependency-links tidak benar-benar memiliki alternatif hari ini. Jadi, saya akan menyarankan agar kita melanjutkan dan tidak mencelanya.

Namun, bendera tersebut berarti bahwa pip akan menjangkau URL yang berubah-ubah -- ia harus memiliki peringatan yang dilampirkan padanya tentang hal ini.

@pradyunsg kecuali ada rencana aktual untuk membunuhnya untuk selamanya, saya sangat menyarankan untuk membiarkan zombie itu beristirahat atau dihapus

saya tidak berpikir orang-orang yang benar-benar membutuhkannya memiliki insentif untuk memperbaiki situasi kecuali pip mengatakan "TIDAK, saya tidak mengambil hutang Anda"

Sebagai pengelola pip, kekhawatiran saya adalah tidak mengizinkan pip menjadi vektor untuk eksploitasi. Pip menganggap PyPI sebagai indeks default, jadi ada kepercayaan implisit pada PyPI di sana. Jadi pertanyaan pertama saya adalah:

1. Apakah ada paket di PyPI yang memiliki metadata dependency_links ?
2. Bisakah PyPI dimodifikasi untuk menolak unggahan proyek dengan dependency_links (atau sudah melakukannya)?
3. Atau, dapatkah pip menolak untuk memproses tautan ketergantungan (terlepas dari apakah opsi disetel) untuk paket yang diunduh dari PyPI?

Jika kami dapat memastikan bahwa tidak ada cara bagi pengguna pip untuk digigit oleh paket di PyPI dengan dependency_links berbahaya, saya tidak akan terlalu khawatir. Pengguna yang memilih untuk menggunakan indeks khusus harus memutuskan sendiri apakah akan mempercayainya. (Saya masih lebih suka untuk mempertahankan bendera itu - ini berpotensi mengeksploitasi jarak jauh dan harus selalu secara eksplisit ikut serta).

Jadi, dengan perubahan berikut:

1. Pip tidak akan pernah memproses tautan ketergantungan dari PyPI (baik secara eksplisit, atau hanya karena kami tahu tautan tersebut tidak ada)
2. Bendera --process-dependency-links tidak digunakan lagi, tetapi hanya berfungsi untuk indeks khusus.

Saya akan baik-baik saja dengan menerima itu sebagai status quo. Orang-orang yang membutuhkan fitur gaya tautan ketergantungan kemudian dapat membicarakan di antara mereka sendiri bagaimana (jika ada) mereka ingin bergerak maju.

Jika seseorang menginginkannya, kami dapat menempatkan semua itu dalam metadata tautan ketergantungan pendefinisian standar, dan penghentian saat ini akan menjadi "perilaku saat ini akan dibatalkan demi perilaku yang ditentukan dalam standar". Tetapi dari sudut pandang pip-centric, saya lebih suka melakukannya - biarkan orang-orang yang membutuhkan tautan ketergantungan melakukan pekerjaan standarisasi (bagaimanapun juga, ini untuk keuntungan mereka, karena mereka kemudian memiliki rute - mendapatkan perubahan standar - untuk memodifikasi perilaku pip dengan konsensus komunitas penuh).

Pada dasarnya kami memiliki fitur yang dimaksudkan untuk menggantikan tautan ketergantungan, tetapi pip belum mulai menghormatinya, karena kami belum memiliki cara untuk memblokir unggahan ke PyPI yang menggunakannya.

Apakah yang Anda maksud: 4175 Manakah yang diblokir karena 86b0779? Mungkin kita bisa memodifikasi https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L167 untuk hanya memberikan kesalahan jika comes_from adalah PyPI?

Kemudian kita dapat mengubah peringatan penghentian untuk --process-dependency-links untuk mengatakan bahwa pengguna harus beralih ke sintaks @ , dan menghapus --process-dependency-links setelah periode penghentian yang wajar (kita harus memulai jam berdetak dari titik di mana sintaks @ tersedia).

@pfmoore Ya itulah tepatnya, dan sepertinya itu kemungkinan jalan ke depan.

OKE. Jika tidak ada orang lain yang melakukannya lebih dulu, saya akan melihat tentang menulis PR.

Dari apa yang saya kumpulkan, masalah pengguna di sini adalah mereka harus memberikan opsi yang secara eksplisit mengatakan "hei, saya sudah usang" ketika Anda meneruskannya untuk fungsionalitas yang tidak memiliki alternatif.

Saya mendukung penghentian dukungan dependency_links sepenuhnya selama periode penghentian. Dan sementara itu, menambahkan dukungan ketergantungan URL PEP 508, yang menurut saya pip masih harus keras ketika digunakan dan mereka harus tetap ikut serta.

Itu berarti:

• letakkan kemampuan untuk memproses PEP 508 url-deps di belakang bendera
  
  
  
  • samping: harus memberi nama bendera sedemikian rupa sehingga pengguna yang peduli dengan keamanan akan memeriksa dokumen
  
  
• mulai menolak untuk menginstal PEP 508 url-deps ketika mereka berasal dari paket PyPI
• tautan ketergantungan tetap tidak digunakan lagi tetapi kami memiliki tanggal untuk kami akan menghapusnya
  
  
  
  • sejujurnya, saya tidak ingin memberikan ini periode penghentian lebih dari satu rilis mencetak alternatif.
  
  

Saya mengetiknya kemarin tetapi tidak mengirimnya. Saya sekarang menyadari bahwa itu pada dasarnya sama dengan komentar terakhir @pfmoore .

_ya!

Haruskah deps URL memerlukan tanda keikutsertaan? PEP 508 tidak mengatakan demikian, dan implementasi saat ini tidak melakukannya. Saya dapat melihat logikanya, tetapi saya tidak mempercayai penilaian saya tentang pertanyaan keamanan vs kemudahan penggunaan.

Juga, saya ingin melihat beberapa dokumentasi yang jelas tentang bagaimana proyek harus beralih dari tautan ketergantungan ke sintaks @ sebelum kita mulai menekan sakelar. Sudah cukup sulit untuk menjangkau orang-orang yang akan terpengaruh oleh penghinaan, dan peringatan bahwa mereka tidak dapat menemukan cara untuk mengatasinya tidak akan membantu. Idealnya, peringatan harus menyertakan penunjuk ke dokumen "cara mengubah", IMO.

Saya tidak mempercayai penilaian saya tentang pertanyaan keamanan vs kemudahan penggunaan.

Saya cenderung ke arah: "aman secara default" dan ikut serta untuk perilaku yang kurang aman.

dokumentasi yang jelas tentang bagaimana proyek harus beralih dari tautan ketergantungan ke sintaks @ sebelum kita mulai mendorong sakelar

Terdengar bagus untukku.

Saya cenderung ke arah: "aman secara default" dan ikut serta untuk perilaku yang kurang aman.

Sebagai seseorang yang duduk di belakang keras untuk berurusan dengan firewall dan kendala keamanan di tempat kerja saya, saya sangat sadar bahwa kami tidak memiliki banyak pemahaman tentang jenis lingkungan di mana fitur ini mungkin paling berguna (pengembangan internal, sumber tertutup , alur kerja dan tata letak jaringan yang dikontrol ketat, dll). Jadi kecenderungan saya adalah untuk mengamankan alur kerja default (PyPI) tetapi tidak menempatkan penghalang jalan tambahan di jalan orang-orang dengan kasus penggunaan yang jelas penting untuk alur kerja mereka, tetapi di mana kami tidak memahami dengan benar pertukaran yang harus mereka lakukan membuat.

Menurut pendapat saya, "jika paket tersebut berasal dari server yang secara eksplisit Anda pilih untuk digunakan" sudah cukup untuk mengizinkan tautan URL.

Melihat? Bukannya saya tidak punya pendapat, hanya saja saya tidak yakin bias saya tidak terlihat :senyum:

tidak menempatkan penghalang jalan tambahan di jalan orang-orang dengan kasus penggunaan yang jelas penting untuk alur kerja mereka, tetapi di mana kita tidak memahami dengan benar pertukaran yang harus mereka lakukan.

Cukup adil. Jika beberapa pengguna dapat memberikan wawasan tentang alur kerja mereka, itu akan menyenangkan.

"jika paket tersebut berasal dari server yang secara eksplisit Anda pilih untuk digunakan" sudah cukup untuk mengizinkan tautan URL.

Saya tidak yakin di sini. :/

Melihat? Bukannya saya tidak punya pendapat, hanya saja saya tidak yakin bias saya tidak muncul

Hehe.

Cukup adil. Jika beberapa pengguna dapat memberikan wawasan tentang alur kerja mereka, itu akan menyenangkan.

Menurut pendapat saya, "jika paket tersebut berasal dari server yang secara eksplisit Anda pilih untuk digunakan" sudah cukup untuk mengizinkan tautan URL.

Hanya mengizinkan sumber dari GitHub akan menyelesaikan 99% masalah bagi saya. Paket upstream memiliki bug atau fitur yang hilang. Saya memotong dan memperbaikinya, mengeluarkan PR, lalu menunggu waktu yang mungkin sangat lama untuk menggabungkannya dan kemudian dirilis di PyPI. Sementara itu paket saya bergantung pada perbaikan dalam paket tersebut.

Ini bisa menjadi opt-in, asalkan bisa dilakukan dalam satu baris.

Sebenarnya bukan masalah keamanan untuk menggunakan tautan langsung (dengan asumsi HTTPS/dll), itu hanya ketersediaan. Karena kami melarang mereka dari PyPI maka saya akan mengatakan itu cukup baik dan kami tidak memerlukan bendera lain.

Di tempat kerja saya, kami akan jatuh dalam beberapa kasus penggunaan yang disebutkan @pfmoore , yaitu, pengembangan internal sebelum sebuah paket bersumber terbuka, sumber tertutup, dll. (selalu paket internal tergantung pada paket internal lainnya, semuanya dalam server kontrol versi ).
Meskipun, saya juga melihat kemungkinan kasus penggunaan seseorang yang merujuk ke lokasi sistem file ...
Apakah masuk akal untuk memberikan daftar host/lokasi yang masuk daftar putih? Nama bendera harus IMO, seperti yang disarankan @pradyunsg , cukup deskriptif untuk membuat pengguna sadar akan risiko yang terlibat. Mungkin --whitelisted-host ?

@masdeseiscaracteres Saya pikir Anda mungkin salah paham - Saya menyarankan bahwa jika sebuah paket diambil dari PyPI, kami akan gagal jika salah satu dependensinya ditentukan melalui referensi @ . Tetapi seharusnya tidak ada kasus seperti itu di PyPI (kami berharap untuk menolaknya di beberapa titik, kami hanya belum dapat mengaturnya). Semua kegunaan lain dari referensi @ akan baik-baik saja.

Sepertinya kita akan melanjutkan dengan PR yang melakukan apa yang dijelaskan oleh @pfmoore di https://github.com/pypa/pip/issues/4187#issuecomment -389846189.

PR selamat datang. :)

Perhatikan bahwa saya tidak punya waktu untuk sampai ke ini - bukan karena perubahannya sulit (seperti yang disebutkan, tampaknya hanya cek terhadap comes_from ) melainkan karena saya tidak tahu bagaimana memprovokasi kesalahan sendiri (dan yang lebih penting, saya tidak tahu bagaimana menulis tes yang melakukannya). Jika ada yang bisa memberikan contoh kasus uji seperti itu, itu akan sangat membantu.

Jika ada yang bisa memberikan contoh kasus uji seperti itu, itu akan sangat membantu.

Ada tes yang ada test_install_pep508_with_url_in_install_requires yang menunjukkan ini.

Adapun kesalahan saat menginstal dari PyPI, saya tidak melihat opsi yang lebih baik daripada benar-benar mengunggah sesuatu di PyPI yang memiliki persyaratan URL. Saya mengunggah paket di PyPI untuk tujuan ini. https://pypi.org/project/pep-508-url-deps/

Hal lain adalah -- comes_from bukan URL atau jalur, ini adalah string di sepanjang baris 'box==0.1.0 from file:///private/tmp/box' . Siapa pun yang ingin memperbaiki masalah ini, sekarang harus mencari cara yang lebih baik untuk mengatasi kesalahan, sehingga kami memiliki informasi tentang dari mana sebuah paket berasal. :)

@pfmoore masalah ini sudah dekat dan tersayang di hati saya Apakah unggahan @pradyunsg memberi Anda apa yang Anda butuhkan, dan apakah Anda masih berencana untuk mengatasi ini? Jika tidak, saya bisa mengambil ayunan itu.

@bstrdsmkr Tidak, dan seperti yang dikatakan @pradyunsg , ini tidak sesederhana yang saya kira, karena comes_from bukanlah URL sumber. Jadi saya tidak tahu kapan saya akan punya waktu sekarang (saya tidak punya penggunaan pribadi untuk fitur ini, jadi tidak ada dalam daftar prioritas saya).

Seperti disebutkan di atas, PR dipersilahkan :-)

Saya akan menambahkan bahwa paket yang diunggah tidak membantu implementasi dengan cara apa pun, itu hanya membantu untuk menguji fungsionalitas.

Pemahaman saya adalah bahwa perbaikan yang diinginkan adalah seperti:

if req.url and is_like(req.url, PYPI.url):
    raise

di https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L172
di mana is_like() mengembalikan True jika url root di domain yang sama. Apakah itu benar?

Ya. Aku pikir begitu. Itu akan menjadi perubahan kode.

Dan, kita perlu menambahkan/memperbarui tes dan entri NEWS.

Saya juga berpikir bahwa perubahan ini cukup penting untuk menjamin kemungkinan pesan penghentian menyediakan tautan ke dokumen + bagian tambahan dalam panduan pengguna yang memberi tahu orang-orang cara beralih ke alternatif.

Sebagai pengelola pip, kekhawatiran saya adalah tidak mengizinkan pip menjadi vektor untuk eksploitasi. Pip menganggap PyPI sebagai indeks default, jadi ada kepercayaan implisit pada PyPI di sana.

Tidak, ada kepercayaan eksplisit. Dan menambahkan perlindungan terhadap penggunaan sumber eksternal dalam dependensi IMHO tidak akan memperbaiki situasi: lebih mudah menyembunyikan malware di pypi daripada di VCS yang tersedia untuk umum.

IMHO pendekatan yang lebih baik adalah menggunakan VCS pengembang sebagai sumber utama dan menyimpan pypy sebagai registri yang menunjuk ke mereka dan proxy caching dengan beberapa bukti kriptografis yang kuat bahwa konten dalam VCS identik dengan yang didapat dari pypy. maksudku

0 pendaftaran

dev -- public key --> pypa

1 mengunggah

setuptools -- git+https:/.... --> pypa
pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks the signature matches the dev

2 menganggur:

pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks it

2 mengambil

flips a coin
if coin == 1:
  pip -- give me package git+https:/... --> pypi
  pip <-- signature || content -- pypi
  pip -- give me the signature --> vcs
  pip <-- signature -- vcs
else:
  pip -- give signature of package git+https:/... --> pypi
  pip <- signature -- pypi
  pip --> Tor --> give me that commit --> vcs
  pip <-- Tor <-- here -- vcs


pip checks if the signature matches the public key and signature from pypa
pip -- give me public key --> keyserver
pip <-- PK -- keyserver
pip checks signature given by VCS against the sdist given by pypy
pip caches public key and repo location

1 sumber yang diinstal cocok dengan yang ada di VCS karena tanda tangan
2 penulis juga cocok
3 pypa dapat menipu dengan pengguna baru, tetapi kecurangan dapat dideteksi oleh pengguna lama
4 penulis dapat menipu dengan menunjukkan di cabang antarmuka web selain diberikan ke pypy dan mengirim ke pypy cabang lain. Ini tidak akan berfungsi dengan baik jika kita menjadikan cabang sebagai bagian wajib dari URI.

@KOLANICH Saya pikir maksud Anda PyPI (Python Packaging Index) ketika Anda mengatakan pypy/pypa. PyPy adalah implementasi alternatif dari Python. PyPA (Python Packaging Authority) adalah sekelompok sukarelawan yang mengelola proyek-proyek besar di ruang Kemasan Python. Tolong, perbaiki akronimnya atau jangan gunakan akronimnya.

Anda menyarankan untuk secara mendasar mengubah desain layanan mapan yang sudah ada. Jika Anda ingin memiliki perubahan besar seperti itu, Anda dipersilakan untuk menyediakan setidaknya rencana transisi (layak) dan implementasi POC, untuk mengelola/mengubah arsitektur untuk memungkinkan transisi/meminimalkan kerusakan alur kerja yang ada. Perhatikan bahwa bergantung pada hosting eksternal adalah sesuatu yang secara eksplisit dihapus dari PyPI di masa lalu di PEP 470 , namun itu adalah kasus yang cukup berbeda dari apa yang Anda sarankan.

PyPI dikelola oleh sukarelawan, berjalan di atas infrastruktur yang disumbangkan/disponsori. Anda menyarankan agar terhubung melalui Tor, layanan yang dikelola/dijalankan oleh sukarelawan lainnya. Keduanya adalah proyek besar dan memiliki biaya yang terkait dengan menjalankannya, meskipun tidak secara langsung ditanggung oleh/terlihat oleh penggunanya.

Bagaimanapun, ini bukan tempat yang tepat untuk diskusi ini. Jika Anda ingin mengusulkan desain ulang PyPI, saya sarankan Anda memulai diskusi dari awal di https://github.com/pypa/warehouse.

Terima kasih atas saran-sarannya.

Lihat #5571 -- PR untuk alasan mengapa ini didorong ke rilis selanjutnya.

Peringatan di log pemasangan PIP memberikan URL ini, tetapi tidak ada solusi untuk masalah tersebut baik di sini maupun di tiket lain yang disebutkan.

Selain itu, ini bahkan lebih membingungkan: apa yang Anda maksud ketika Anda mengatakan PyPI? Apakah maksud Anda server yang mengimplementasikan antarmuka PyPI (mis. Artifactory), atau, khususnya, pypi.org?

Sekarang, jelas, seseorang yang ingin mendukung baik menginstal paket melalui setuptools (alias menjalankan setup.py install ) dan melalui menggunakan pip install akan sekarang dalam acar. Menentukan tautan ketergantungan adalah satu-satunya cara bagi seseorang dalam situasi ini untuk menangani beberapa paket yang saling bergantung.

Sekarang, perbaiki saya jika saya salah, tetapi sejauh ini sepertinya jika Anda mengambil ini berdasarkan keputusan apa pun yang telah dibuat PyPA tentang unggahan ke server mereka, pada dasarnya, Anda membuat pip tidak berguna bagi pengguna Artifactory / perusahaan yang memiliki repositori pribadi dengan paket yang saling bergantung.

Tolong beri tahu saya bahwa saya salah dan melewatkan sesuatu dalam keseluruhan cerita ini (saya mengikuti dan mematikannya untuk sementara waktu). Saya merah PEP 508, tetapi itu benar-benar tidak ada bedanya dalam hal ini, setidaknya, saya tidak dapat melihat bagaimana hal itu akan membuat keadaan menjadi lebih baik atau lebih buruk.

@wvxvw-traiana Saya pikir Anda melewatkan PR #5571
Sebelum itu PR (dan dalam rilis saat ini -- 18.0) pip akan menolak untuk menginstal ketergantungan apa pun yang ditentukan melalui sintaks PEP508.

Setelah itu PR (sudah digabung jadi seharusnya di 18.1+) pip hanya akan menolak dependensi tersebut jika paket yang bergantung padanya berasal dari pypi.org.

Jika Anda menginstal paket dari repo pribadi Anda yang bergantung pada hal-hal dari pypi, jelas itu baik-baik saja.
Jika Anda menginstal paket dari pypi.org yang bergantung pada barang-barang dari repo pribadi Anda, itu gagal.
Jika Anda menginstal paket dari repo pribadi Anda yang bergantung pada hal-hal di repo pribadi Anda, tidak apa-apa.

Semoga itu membantu menjernihkan semuanya

@bstrdsmkr Apakah asalnya sama atau pypi kasus khusus? Yaitu

Jika Anda menginstal paket dari repo pribadi Anda yang bergantung pada barang-barang dari repo pribadi yang berbeda.

Untuk menambahkan beberapa konteks lebih lanjut tentang alasan di balik ini:

1. Tautan URL langsung memungkinkan paket untuk memicu pengunduhan dan menjalankan kode arbitrer dari mana saja di internet. Tidak apa-apa jika Anda bertanggung jawab atas paket yang melakukan itu, jadi kami mengizinkan tautan URL langsung pada pemahaman itu.
2. Orang berharap untuk menginstal dari PyPI (khususnya PyPI, bukan indeks paket pada umumnya) dan mempercayai paket yang mereka unduh dari sana. Untuk mencegah kompromi dari paket PyPI yang mengekspos sejumlah besar pengguna Python, kami tidak mengizinkan paket yang berasal dari PyPI bergantung pada tautan URL langsung (karena itu membebani terlalu banyak beban pada pengguna kami untuk bersikeras bahwa mereka harus mengaudit semuanya dari PyPI yang mereka gunakan untuk tautan ke kode eksternal).
3. Tautan ketergantungan adalah mekanisme khusus setuptools, dan diproses oleh mesin internal setuptools, bukan oleh pip. Jadi tidak seperti link URL langsung, kita tidak memiliki kontrol atas apa yang mereka lakukan. Itulah mengapa kami tidak lagi menggunakannya demi bentuk URL langsung standar, yang kami tangani sendiri.

seseorang yang ingin mendukung baik menginstal paket melalui setuptools (alias menjalankan setup.py install) dan melalui menggunakan pip install akan sekarang dalam acar.

Jika benar, itu karena setuptools belum menerapkan dukungan untuk tautan URL langsung, yang merupakan standar yang disepakati. Jangan ragu untuk meningkatkannya bersama mereka.

Jika Anda menginstal paket dari repo pribadi Anda yang bergantung pada barang-barang dari repo pribadi yang berbeda.

Itu bekerja dengan baik. PyPI tidak terlibat.

Oke, jadi, di satu sisi, saya senang ini tidak memengaruhi saya.

Di sisi lain, "perbaikan" ini tampaknya, bagaimana saya mengatakannya ... terlalu mudah untuk diselesaikan.

echo "not-pypi 151.101.61.63" >> /etc/hosts
pip install --index-url not-pypi

Bukan urusan saya, sungguh, tetapi sepertinya pendekatan tingkat permukaan. (Vektor serangan lainnya disebutkan dalam komentar lain, di mana Anda dapat mengunduh apa pun yang Anda inginkan di setup.py).

Ini tidak dirancang agar sulit bagi pengguna untuk dikerjakan oleh pengguna. Ini adalah cara untuk menawarkan solusi (terbatas) terhadap fakta bahwa PyPI belum memiliki cara untuk memblokir orang dari mengunggah paket dengan dependensi URL langsung. Lihat https://github.com/pypa/pip/pull/4175#issuecomment -266305694 untuk beberapa konteks.

@dpwrussell pypi.org adalah kasus khusus. Setiap repo pribadi ke repo pribadi apa pun berfungsi dengan baik setelah perubahan.

@wvxvw-traiana itu tidak dimaksudkan untuk mencegah Anda melakukan itu sendiri. Ini dimaksudkan untuk mencegah orang lain melakukan itu kepada Anda ketika Anda berpikir Anda baru saja menginstal paket dari pypi.org

Tidak terkait dengan diskusi saat ini, saya membuka kembali ini karena kami belum benar-benar memperbarui peringatan penghentian untuk ini.

5726 menambahkan bahasa yang menyarankan penggunaan URL PEP 508, yang IMO adalah bit terakhir yang diperlukan untuk ini.

Baiklah kalau begitu. Biarkan saya meringkas:

• tautan ketergantungan masih tidak digunakan lagi dan sekarang dijadwalkan untuk dihapus di pip 19.0.
• pengganti yang didukung standar untuk itu adalah dependensi URL PEP 508
• Saat menginstal dari PyPI, jika sebuah paket memiliki dependensi URL PEP 508, itu akan mengakibatkan pip membatalkan instalasi.

@pfmoore telah menguraikan alasan keputusan ini di sini: https://github.com/pypa/pip/issues/4187#issuecomment -415067034

@pradyunsg Kapan dependensi URL PEP 508 diizinkan di install_requires di setup.py? Apakah ada tanggal yang ditetapkan?

Dalam rilis pip berikutnya -- yaitu 18.1, dijadwalkan untuk bulan Oktober. Anda dapat membaca lebih lanjut tentang siklus rilis 3 bulan pip di https://pip.pypa.io/en/latest/development/release-process/. :)

https://github.com/pypa/wheel/issues/249 perlu ditangani sebelum dependensi URL PEP 508 menjadi alternatif yang layak.

pypa/wheel#249 perlu ditangani sebelum dependensi URL PEP 508 menjadi alternatif yang layak.

Ini telah diatasi.

Dalam catatan rilis pip 18.1 dikatakan

Izinkan persyaratan URL PEP 508 untuk digunakan sebagai dependensi.

Sebagai tindakan keamanan, pip akan memunculkan pengecualian saat menginstal paket dari PyPI jika paket tersebut bergantung pada paket yang tidak juga dihosting di PyPI. Di masa mendatang, PyPI akan memblokir pengunggahan paket dengan dependensi URL eksternal tersebut secara langsung. (#4187)

Jadi ini pada dasarnya berarti dependensi dapat ditentukan menggunakan URL, tetapi jika itu bukan URL PyPI, paket tidak dapat diinstal menggunakan pip? Mungkin saya benar-benar salah, tetapi bagaimana dependensi URL seharusnya digunakan?

Paket @JarnoRFB yang di-host di PyPI tidak dapat memiliki dependensi url.

Paket yang TIDAK dihosting di PyPI dapat memiliki dependensi url. Jika Anda menginstal paket langsung dari github (misalnya) dependensi url akan diselesaikan dan diinstal. Contoh instalasi seperti itu:

pip install git+https://github.com/bstrdsmkr/some_package.git

Pada dasarnya, jika Anda menginstal dari url, itu bisa bergantung pada url, jika tidak, tidak bisa. Dan hanya untuk kejelasan, itu juga dapat memiliki dependensi url dan non-url

Tambahan kecil:

...jika Anda menginstal dari url, itu bisa bergantung pada url

...jika Anda menginstal dari URL (VCS atau lainnya) atau file lokal atau indeks paket yang bukan PyPI, itu dapat...

Jadi apakah ada versi pip yang memproses install_requires sesuai deskripsi di atas? Saya tidak dapat mengetahui tag di atas apa status akhir dan dokumentasi pip saat ini menunjuk ke dokumentasi install_requires di setuptools yang masih mengatakan untuk menggunakan dependency_links .

Tidak dapat berbicara dengan dokumen sendiri, tetapi "relaksasi" ini untuk mengizinkan paket non-PyPI menginstal dependensi dari url dirilis di pip 18.0

AFAIK, dependensi URL di install_requires didukung sejak pip 18.1:

Izinkan persyaratan URL PEP 508 untuk digunakan sebagai dependensi.

Sumber: catatan rilis

Ugh, salah ketik di pihak saya -- @pietrodn jelas benar

Saya ingin meninggalkan contoh kecil tapi sukses di sini bagi mereka yang pertama kali menemukan masalah ini dengan ketakutan (seperti saya) tentang apa yang harus dilakukan tanpa --process-dependency-links. Dengan menggunakan alur kerja ini, pengguna saya sekarang dapat menginstal pip dari GitHub atau dari sumber lokal (bukan PyPI), atau ke pip install requirements.txt, atau ke python setup.py install, dan untuk bekerja di Travis-CI, dengan pip versi 18+, jadi saya pikir ini mencakup banyak basis. Saya harap ini bermanfaat bagi seseorang, dan permintaan maaf saya jika ini tampaknya di luar topik bagi orang lain:

Dalam file requirements.txt Anda, dengan asumsi Anda ingin orang-orang dapat bergantung pada cabang dev GitHub dari paket "foo", misalnya:

scipy>=0.17
matplotlib>=2.0
foo @ git+https://github.com/foo-organization/foo@dev#egg=foo-9999

Di file setup.py Anda:

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

Beberapa orang akan mengatakan bahwa menggabungkan install_requires dan requirements.txt tidak disarankan, dan untuk versi yang dirilis, saya setuju, tetapi saya pikir ini berfungsi dengan baik untuk pengembangan.

Ah, rapi. Jadi jika katakanlah paket "A" dan "B" keduanya menggunakan metode ini, dan paket "A" mencantumkan "B" sebagai ketergantungan, ketika Anda menginstal "A" itu sebenarnya berakhir dengan memproses persyaratan.txt untuk "B" (yang biasanya tidak) - benarkah?

Saya juga membaca pagi ini bahwa install_requires itu sendiri agak buruk karena mereka menginstal dilakukan oleh setuptools, yang berarti setiap opsi pip diabaikan, tapi saya tidak tahu apakah info yang sudah usang ...

Saya juga membaca pagi ini bahwa install_requires itu sendiri agak buruk karena pemasangan itu dilakukan oleh setuptools, yang berarti setiap opsi pip diabaikan, tetapi saya tidak tahu apakah info itu sudah usang ...

Anda membingungkan install_requires dengan setup_requires .

Ah, rapi. Jadi jika katakanlah paket "A" dan "B" keduanya menggunakan metode ini, dan paket "A" mencantumkan "B" sebagai ketergantungan, ketika Anda menginstal "A" itu sebenarnya berakhir dengan memproses persyaratan.txt untuk "B" (yang biasanya tidak) - benarkah?

@stevebrasier Ya, saya pikir itu akan menjadi masalah jika Anda telah menyematkan versi berbeda dari paket lain yang diperlukan di A daripada di B.

Hai teman-teman, saya hanya ingin mencatat bahwa jalur penghentian dalam kasus ini terlalu pendek. Saya tahu bahwa tautan ketergantungan telah ditandai sebagai usang untuk beberapa waktu, tetapi URL PEP 508, yang dapat digunakan untuk menggantikannya, belum diterapkan hingga 18.1. Akibatnya hanya ada waktu 3 bulan untuk beralih dari tautan ketergantungan ke persyaratan URL, yang merupakan waktu yang sangat singkat untuk proyek besar.

@rgerkin Hai, saya mencoba mengikuti instruksi Anda tetapi tidak berhasil,

Mencari PACKAGE@ git+ ssh://[email protected] :OWNER/PACKAGE. git@BRANCH
Membaca https://pypi.org/simple/PACKAGE/
Tidak dapat menemukan halaman indeks untuk 'PACKAGE' (mungkin salah eja?)
Memindai indeks semua paket (ini mungkin memakan waktu cukup lama)
Membaca https://pypi.org/simple/

PAKET@ git+ ssh://[email protected] : PEMILIK/PAKET. git@BRANCH , ini ada di install_requires.

Apakah Anda tahu mengapa saya mendapatkan hal di atas?

@KevinMars Ada beberapa perbedaan antara contoh saya dan apa yang Anda miliki, termasuk penggunaan git_ssh, bitbucket, akhiran a.git, cabang bernama, dan tidak ada tag versi. Mungkin satu atau lebih dari hal-hal itu mengarahkan pip untuk mencari di PyPI alih-alih di URL Anda. Pakai pip versi berapa?

Untuk mengomentari sesuatu yang saya temukan: Menggunakan setup.py untuk menginstal paket dengan python setup.py install masih memerlukan deklarasi dependensi eksternal di dependency_links .

Di file setup.py Anda:

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

@rgerkin Terima kasih telah berbagi solusi ini. Tetapi bagaimana jika saya menggunakan pbr untuk mengatur paket Python saya? Bagaimana cara mengadaptasi ini agar sesuai dengan pbr?

@KevinMars Saya memiliki masalah yang sama persis. Apakah Anda pernah mencari tahu perbaikannya? Saya mencoba meminta cabang tertentu dari repo bitbucket pribadi melalui SSH.

Saya baru menyadari --process-dependency-links tidak ada lagi. Saya berterima kasih atas semua pekerjaan yang dilakukan masyarakat. Mencoba membenarkan keputusan dalam diskusi yang tidak pernah berakhir dan labirin penutupan dan pengalihan masalah adalah solusi yang dipilih, tetapi saya masih berpikir meninggalkan opsi ini tidak akan merugikan siapa pun.