/cc @uranusjr @ncoghlan @altendky @njsmith

Saya yakin bahwa ini adalah hal yang biasa terjadi (FW perusahaan / proxy caching) -- Saya merasa kita memerlukan pengaturan override untuk menentukan mirror yang akan digunakan sebagai ganti pypi jika kita menemukannya di pipfile-- seperti PIPENV_PYPI_MIRROR atau PIPENV_PYPI_CACHING_PROXY atau sesuatu seperti itu untuk menentukan bahwa itu harus dicoba terlebih dahulu, diiris menjadi sources di depan pypi pada dasarnya.

Apakah itu tampak seperti mencapai tujuan? Jika demikian, kami dapat menandai jin implementasi untuk memberi tahu kami mengapa ini baik atau buruk (@ncoghlan)

Saya akan mulai dengan catatan kehati-hatian: hingga PyPI telah menerapkan mekanisme penandatanganan paket yang mirip dengan PEP 458 untuk menyediakan cara yang tidak bergantung pada TLS untuk pip guna memastikan bahwa paket yang secara nominal berasal dari PyPI benar-benar cocok dengan apa yang diterbitkan PyPI , kemudian menawarkan kemampuan untuk mengalihkan lalu lintas secara transparan ke server yang berbeda benar-benar mengkhawatirkan dari perspektif keamanan.

Sayangnya, vektor serangan itu sudah terbuka melalui pip.conf , jadi menawarkan sesuatu yang sebanding pada level pipenv tidak akan membuat sesuatu yang lebih buruk dari yang sudah ada.

Di luar itu, saya pikir mekanisme penulisan ulang URL repositori tujuan umum sebenarnya bisa lebih mudah untuk didokumentasikan dan dijelaskan daripada sesuatu yang spesifik PyPI, setidaknya pada lapisan kemampuan dasar. Sesuatu seperti:

pipenv --override-source-url 'default=https://pypi-proxy.example.com/api' --override-source-url 'https://pypi.python.org/simple=https://pypi-proxy.example.com/api'  --override-source-url 'https://pypi.org/simple=https://pypi-proxy.example.com/api' install

(Satu-satunya bit spesifik PyPI akan menggunakan "default" untuk merujuk ke sumber unduhan default pip, seperti yang spesifik dalam pip.conf ).

Mengeja seluruh peta penggantian URL sumber setiap kali akan sulit digunakan dalam praktiknya, jadi beberapa opsi untuk gula CLI mungkin terlihat seperti:

pipenv --override-source-urls <config file> install

pipenv --pypi-mirror https://pypi-proxy.example.com/api install

Apakah akan mengekspos lapisan --override-source-url segera atau tidak adalah pertanyaan yang berbeda - mungkin lebih masuk akal untuk mengimplementasikan opsi --pypi-mirror yang lebih sederhana terlebih dahulu, dan hanya menyimpan kemungkinan --override-source-url dan --override-source-urls sebagai opsi masa depan yang mungkin dalam pikiran saat melakukannya.

Pemetaan {given URL: override URL} umum adalah pemikiran pertama saya juga, tetapi pada pertimbangan lebih lanjut, ada beberapa argumen untuk PyPI casing khusus:

• PyPI cukup unik karena memiliki URL publik yang terkenal dan banyak mirror

• PyPI sebenarnya memiliki banyak URL (misalnya, kita mungkin akan memiliki Pipfiles yang beredar untuk sementara waktu dengan https://pypi.python.org/simple dan https://pypi.org/simple , dan mungkin juga https://pypi.python.org/simple/ dan https://pypi.org/simple/ dengan garis miring?), dan alangkah baiknya jika kita bisa menyelesaikan ini sekali daripada memaksa setiap pengguna untuk mencari tahu sendiri

@njsmith Lihat saran gula --pypi-mirror <URL> di bagian terakhir posting saya - jika implementasi awal hanya berfokus pada itu, maka kemampuan penulisan ulang URL umum dapat dimulai sebagai detail implementasi internal (didorong oleh fakta bahwa " PyPI" memiliki beberapa URL yang semuanya akhirnya diselesaikan ke tempat yang sama), dan kemudian dipertimbangkan untuk diekspos sebagai fitur tersendiri di kemudian hari (setelah dikonfirmasi bahwa itu berfungsi seperti yang diinginkan untuk penggunaan --pypi-mirror utama kasus).

Ah, benar, aku merindukan itu :-)

Apakah ada aturan umum yang memetakan argumen baris perintah ke beberapa jenis konfigurasi yang lebih persisten? Saya membayangkan bahwa sebagian besar pengguna ini ingin mengaturnya sekali dan kemudian melupakannya.

@ncoghlan menulis:

Saya akan mulai dengan catatan kehati-hatian: hingga PyPI telah menerapkan mekanisme penandatanganan paket yang mirip dengan PEP 458 untuk menyediakan cara pip yang tidak bergantung pada TLS guna memastikan bahwa paket yang secara nominal berasal dari PyPI benar-benar cocok dengan apa yang diterbitkan PyPI, lalu menawarkan kemampuan untuk mengarahkan lalu lintas secara transparan ke server yang berbeda benar-benar mengkhawatirkan dari perspektif keamanan.

Jika saya membaca Pipfile.lock saya dengan benar, tidak ada hubungan yang disimpan antara sebuah paket dan dari sumber mana paket itu diinstal. Mengingat bahwa kumpulan fitur yang ada memungkinkan banyak sumber ditentukan, bukankah itu menciptakan masalah serupa? sync akhirnya bisa mendapatkan paket dari sumber yang berbeda dari yang digunakan saat membuat lockfile.

Pipfile.lock menyimpan daftar hash artefak yang dapat diterima untuk setiap ketergantungan yang disematkan, jadi setelah Anda mengunci, mengganti paket secara diam - diam menjadi sulit. Pada waktu pembuatan kunci, secara eksplisit memilih sumber di Pipfile mengatakan "Saya percaya sumber ini tidak mengacaukan saya, dan akan menggunakan TLS untuk memverifikasi bahwa saya benar-benar berbicara dengan titik asal ini". (Saya pikir ada masalah di suatu tempat yang membahas prospek mengikat paket tertentu ke repo sumber tertentu, meskipun mungkin di pip atau salah satu repo PyPA lainnya, daripada di sini)

Mengubah URL indeks default (atau menambahkan URL indeks tambahan) di pip.conf , atau menggunakan fitur override yang diusulkan di sini melalui file konfigurasi atau mekanisme berbasis profil shell berbeda: yang mengatakan "Saya, atau proses arbitrer saya berjalan di beberapa titik waktu dengan akses tulis ke direktori home saya (seperti file setup.py sdist), memutuskan untuk mengonfigurasi pengaturan saya untuk mempercayai sumber paket ini". Dan bahkan skema penandatanganan seperti PEP 458 bukanlah pertahanan yang lengkap terhadap kejahatan semacam itu jika kunci publik yang digunakan untuk verifikasi itu sendiri disimpan di suatu tempat di dalam direktori home Anda daripada di direktori yang memerlukan hak istimewa yang lebih tinggi untuk dimodifikasi.

Ada alasan bagus mengapa organisasi dengan persyaratan keamanan yang ketat mengeksekusi build di server yang terkunci dengan hanya akses terbatas ke internet secara luas, atau memantau masalah semacam ini di tingkat jaringan :)

Perhatikan juga jika Anda menggunakan beberapa indeks dan sebuah paket berasal dari indeks non-primer, paket tersebut akan ditunjukkan di file kunci.

Kekhawatiran pep 458 pada dasarnya adalah apa yang ada dalam pikiran saya, karena hal-hal yang merupakan url yang berbeda tetapi pada kenyataannya titik di pypi berbeda daripada jika Anda hanya menyalin pypi secara lokal dan mengklaim itu sama.

Saya, atau proses arbitrer yang saya jalankan di beberapa titik waktu dengan akses tulis ke direktori home saya (seperti file setup.py sdist), memutuskan untuk mengonfigurasi pengaturan saya untuk mempercayai sumber paket ini

Jika ini adalah model ancaman Anda, maka saya tidak melihat bagaimana apa pun yang dapat dilakukan pipenv akan banyak mempengaruhinya. Seseorang yang dapat memodifikasi konfigurasi direktori home Anda juga dapat melakukan hal-hal seperti memasukkan direktori baru pada $PATH dan memasukkan pipenv palsu di sana yang melakukan apa pun yang mereka inginkan.

@njsmith ini juga model ancaman pip, karena instalasi paket memerlukan eksekusi kode arbitrer dari file sdist setup.py diperbolehkan. Kode itu memang bisa menimpa hal-hal di direktori home Anda seperti pengaturan Anda, atau menambahkan sesuatu ke jalur Anda, atau sejumlah hal. Itu sebabnya secara eksplisit mengistimewakan pypi (indeks yang diketahui dan dipercaya) dan memerlukan pemeriksaan hash adalah langkah yang baik menuju keamanan. Ini memungkinkan kontrol terpusat dan penghapusan ancaman keamanan yang diketahui dan mengidentifikasi verifikasi paket yang Anda unduh secara terdistribusi. Apa yang dikatakan file kunci yang Anda unduh tentang hash yang seharusnya Anda dapatkan? Itu tidak cocok dengan apa yang Anda dapatkan dari indeks? Agar mode operasi ini gagal, Anda harus mengalami kegagalan di lebih dari satu mesin lokal, indeks, dan lapisan jaringan karena Anda berbicara tentang memiliki beberapa paket yang rusak di tumpukan aplikasi Anda yang berfungsi bersama memverifikasi hash terhadap indeks tepercaya , dan dalam banyak kasus hash itu sendiri berasal dari sumber lain yang tidak terlibat. Jadi sekarang Anda harus memiliki minimal, semua pemeriksaan hash di pip dan pipenv entah bagaimana dirusak sedemikian rupa sehingga menghasilkan hash yang identik dengan yang Anda harapkan, tetapi menginstal hal-hal jahat lainnya?

Saya kira apa yang saya katakan adalah, jika mesin lokal Anda dikompromikan, tidak ada yang akan dilakukan pip atau pipenv untuk menyelamatkan Anda. Tetapi kami dapat memastikan bahwa paket yang Anda unduh adalah paket yang Anda cari, dari tempat Anda seharusnya mencarinya, yang dapat menyediakan satu elemen dalam rantai keamanan.

@ncoghlan @njsmith bagaimana ini semua faktor dengan langkah untuk mendorong kembali terhadap sudo pip install... dan pengertian umum saya pikir kita semua memiliki bahwa jika Anda akan menggunakan pip, Anda mungkin juga tidak harus menggunakan Anda manajer paket sistem untuk menginstal hal-hal python secara umum. Ini sebenarnya bukan pertanyaan pipenv mungkin, tapi di sinilah diskusi sekarang dan ini mungkin memandu langkah selanjutnya...

@techalchemy Saya sama sekali tidak melihat hubungan dengan topik ini? Saya pikir kesimpulan dari semua hal di atas adalah membiarkan pengguna mengganti mirror pipenv mana yang digunakan untuk PyPI tidak menimbulkan ancaman tambahan, dan melakukan sudo pipenv bahkan tidak masuk akal sejak awal, bukan?

@njsmith tidak, saya tidak berpikir siapa pun harus menggunakan sudo pipenv , seperti yang saya sebutkan itu tidak benar-benar sesuai topik, tetapi karena kami sedikit menuruni jalur model ancaman, saya pikir itu perlu ditelusuri. Secara khusus:

Dan bahkan skema penandatanganan seperti PEP 458 bukanlah pertahanan yang lengkap terhadap kejahatan semacam itu jika kunci publik yang digunakan untuk verifikasi itu sendiri disimpan di suatu tempat di dalam direktori home Anda daripada di direktori yang memerlukan hak istimewa yang lebih tinggi untuk dimodifikasi.
Ada alasan bagus mengapa organisasi dengan persyaratan keamanan yang ketat mengeksekusi build di server yang terkunci dengan hanya akses terbatas ke internet secara luas, atau memantau masalah semacam ini di tingkat jaringan :)

Jika pertahanan setidaknya dalam beberapa kapasitas bergantung pada kunci yang disimpan di lokasi yang diistimewakan, tetapi kami menyarankan untuk tidak menggunakan instalasi python yang diistimewakan, saya pikir itu mungkin layak untuk didiskusikan. Mungkin aku salah. Tapi sepertinya itu terkait dengan komentar @ncoghlan (tetapi bukan sudo pipenv , itu seharusnya tidak menjadi masalah)

Ya itu mungkin tampak seperti muncul entah dari mana, hanya pemikiran acak. Semoga konteks tambahan memperjelasnya

Saya memilih kami menjaga masalah ini pada topik membantu orang-orang yang perlu menggunakan cermin PyPI, daripada masuk ke diskusi spekulatif tentang bagaimana kami dapat menerapkan TUF. (Lagi pula, menurut saya tidak banyak yang dapat atau harus kita lakukan untuk mencoba mempertahankan diri dari penyerang yang memiliki akses tulis sewenang-wenang ke direktori home pengguna.)

Oke, jadi mari kita definisikan perilaku yang kita harapkan atau sukai. Pemahaman kerja saya saat ini adalah bahwa:

• Jika --pypi-mirror dilewatkan atau PIPENV_PYPI_MIRROR disetel, kita harus memilih itu
• Haruskah kita lebih memilihnya daripada PyPI saja? Bagaimana kami membuat penilaian apakah url indeks yang diberikan adalah 'PyPI' -- kami tidak dapat menanyakannya, jadi kami harus mempertahankan daftar
• Haruskah daftar berisi semua kemungkinan permutasi, atau haruskah kita puas dengan menggunakan dua url yang telah kita gunakan di masa lalu untuk menghasilkan Pipfiles sebagai hal-hal yang harus kita coba cermin yang disediakan terlebih dahulu?

Itu harus menimpa PyPI saja, bukan URL lain. Saya kira mungkin hanya ada beberapa URL PyPI berbeda yang digunakan, sehingga mereka dapat dicantumkan, dan jika kita melewatkan satu maka seseorang akan mengajukan bug, itu akan ditambahkan, dan segera kita akan memiliki semuanya.

Sepertinya pendekatan yang tepat untuk saya.

Apa yang dikatakan @njsmith cocok dengan perspektif saya juga. 3 URL repo yang saya sarankan untuk diganti dalam PR awal adalah:

• Tidak ada yang disetel (yaitu ketika mengandalkan pengaturan default pip )
• https://pypi.python.org/simple
• https://pypi.org/simple

Trailing-slash-or-not kemungkinan lebih baik ditangani sebagai langkah normalisasi URL, daripada dengan mencantumkan URL secara terpisah.

Perhatikan bahwa permintaan Pipfile memang memiliki garis miring (pada saat penulisan) , jadi kami mungkin perlu menangani ini dengan satu atau lain cara.

Benar, pikiran saya adalah:

• pertahankan daftar URL tanpa garis miring
• periksa URL yang masuk untuk garis miring, dan hapus jika ditemukan ( str.rstrip kemungkinan akan cukup baik untuk tugas tersebut, meskipun itu akan menghapus sejumlah garis miring yang berubah-ubah, atau kita bisa lebih ketat tentang hal itu, dan hapus paling banyak satu garis miring)

Luar biasa. Saya pikir ini cukup untuk dikerjakan dan cukup sederhana untuk dibangun. Terima kasih semuanya!

Semoga fitur cermin bisa segera ditambahkan~

Saya menghadapi masalah ini juga. Situasinya adalah:

• Memiliki server PyPI internal dengan beberapa paket pribadi.
• Memiliki beberapa aplikasi Python yang menggunakan Pipenv untuk mengelola dependensinya.
• Beberapa dependensi hidup di server PyPI internal, dan lainnya di komunitas PyPI. Yang internal dialihkan ke komunitas PyPI untuk paket apa pun yang tidak ditemukan.

Strategi penerapan saya sudah menyiapkan pip.conf seluruh sistem yang merujuk ke server PyPI internal. Anehnya, saya menemukan bahwa konfigurasi ini diabaikan oleh Pipenv.

Saya memperhatikan bahwa jika saya memindahkan/mengganti nama PyPI interal, maka beberapa aplikasi dengan Pipfiles harus diperbarui dan file Pipfile.lock mereka dibuat ulang. Opsi cermin akan menyediakan fungsionalitas yang diinginkan. Ini juga akan berfungsi dan terasa kurang berlebihan jika Pipenv bisa membaca konfigurasi sistem untuk Pip.

PR diterima untuk yang satu ini btw

Hai. Saya memiliki kebutuhan yang sama tetapi saya akan membagi fitur penggantian ini menjadi tiket lain.

Inilah proposal perilaku yang saya harapkan:

• file konfigurasi dapat ditentukan untuk mengatur setiap nilai yang ditentukan di bagian [[source]] Pipfile.
• bisa berupa file toml dengan hanya bagian [[source]] dari Pipfile
• Lokasi file ini sangat terinspirasi oleh aturan yang ditentukan untuk pip.conf (mis: /etc/pipenrc.toml, ~/.pipenvrc.toml
• variabel lingkungan juga dapat didefinisikan untuk menimpa nilai ini (pengingat: kita membutuhkan semua nilai [[sumber]]). Untuk didefinisikan
• perilaku pipenv saat ini adalah sekarang:
  
  
  
  • saat membuat Pipfile, dibutuhkan nilai dari file konfigurasi / variabel lingkungan
  
  
  • jika tidak ada file konfigurasi atau variabel lingkungan yang ditentukan, perilaku pipenv saat ini berlaku
  
  
  • pipenv terus menghasilkan bagian [[source]] dari Pipfile
  
  
  • jika bagian [[source]] dari Pipfile ada, pipenv tidak mencoba menimpa apa pun dengan nilai dari file konfigurasi.
  
  

Dan di tiket kedua, opsi —override dapat diimplementasikan. Masuk akal misalnya di dalam CI atau sesuatu.

Sebagai catatan tambahan: kami banyak menggunakan pipenv dalam produksi sekarang, tetapi saya perlu mengingatkan semua orang terlalu sering bahwa mereka perlu mengubah Pipfile mereka secara manual ketika mereka memulai proyek baru untuk mencapai repositori Arrifactory Pypi kami (untuk informasi, Nexus juga melakukan Pypi cache gratis dan t berfungsi dengan baik!). Kami memiliki firewall yang sangat membatasi dan merupakan praktik yang sangat baik di dalam perusahaan untuk menyimpan dependensi eksternal dalam cache, sehingga mereka dapat dicadangkan dan diperiksa untuk kerentanan misalnya.
Jika fitur sederhana mirip dengan file konfigurasi umum atau pengguna (seperti yang sudah kami lakukan untuk pip atau npm), sehingga kami menerapkannya di semua workstation kami sehingga pengembang kami melakukan lebih sedikit kesalahan, itu akan sempurna untuk saya)

Mungkin saya melewatkan sesuatu, tetapi ini sepertinya kemunduran. Kami telah menggunakan 11.6.0 untuk sementara waktu, dan pipenv dengan senang hati mendelegasikan pengaturan di pip.conf kami, yang mengarah ke cermin pypi internal.

Ada ide kapan ini pecah? Itu membuat pipenv sama sekali tidak dapat digunakan dalam konteks kita. Saya mengalami kesulitan melihat ini sebagai "fitur yang hilang" ketika tampaknya berfungsi dengan baik untuk waktu yang lama.

Untuk lebih jelasnya: setelah memutakhirkan ke 2018.05.18, bahkan dengan cermin yang ditentukan dalam Pipfile[.lock] kami, pipenv mencoba menginstal paket baru dari pypi.org.

Mungkin apa yang saya lihat adalah masalah yang terpisah dari yang satu ini...

@brettdh Sulit untuk mengatakan tanpa melihat lingkungan Anda, tapi saya pikir itu bukan masalah yang sama. Saya sarankan Anda melakukan pembagian dua antara rilis untuk melihat dengan tepat di mana ini berubah, dan membuka masalah baru untuk itu.

Saya sedang mengerjakan PR untuk ini.

Saya pikir ini mengalami kemunduran terhadap pengaturan default. Mungkin telah terjebak dalam gelombang pembaruan untuk pip 10 yang belum dirilis, tetapi saya yakin kita dapat mengambil ini tanpa terlalu banyak kesulitan jika @JacobHenner belum menambahkannya

Saya kira Anda sedang berbicara tentang menggunakan devpi sebagai proxy caching untuk PyPi resmi. Untuk pip itu sendiri, Anda perlu memodifikasi /etc/pip.conf dan /usr/lib64/python3.6/disutils/distutils.cfg agar pip dapat menggunakan server devpi lokal Anda untuk semua permintaan.

Namun, sepertinya pipenv mengabaikan pengaturan seluruh sistem ini, jadi Anda terpaksa mengubah pengaturan konfigurasi [[source]] di Pipfile untuk merujuk server devpi Anda. Tetapi kemudian jika Anda mempublikasikan Pipfile Anda secara eksternal, kontributor eksternal harus menghapus pengaturan [[source]] Anda untuk benar-benar membangun lingkungan mereka sendiri.

Saya pikir pipenv seharusnya hanya menghormati pengaturan global dari /etc/pip.conf dan /usr/lib.../distutils.cfg

@polski-g

Saya kira Anda sedang berbicara tentang menggunakan devpi sebagai proxy caching untuk PyPi resmi

Repositori Nexus, tapi ya, ide yang sama.

Namun, sepertinya pipenv mengabaikan pengaturan seluruh sistem ini

Seperti yang disebutkan @techalchemy , saya percaya bahwa pipenv (11.6.0) dulu menghormati pip.conf (homedir juga), tetapi versi terbaru tidak - khususnya, ada URL pypi.org hard-coded di suatu tempat (ketergantungan resolusi, IIRC) yang tidak dapat diganti.

Saya pikir pipenv seharusnya hanya menghormati pengaturan global dari /etc/pip.conf dan /usr/lib.../distutils.cfg

Setuju - meskipun secara pribadi saya tidak perlu mengubah distutils.cfg dalam kasus penggunaan saya.

IIRC ada resolusi untuk tidak menghormati pip.conf, tetapi Anda harus menggali lebih dalam ke pelacak masalah untuk menemukannya. Bagaimanapun, kapal telah berlayar, dan dengan pencerminan PyPI hampir selesai, ini tidak mungkin berubah dalam waktu dekat.

Saya cukup yakin fitur ini akan dikirimkan pada rilis berikutnya (yang akan dikirimkan dalam satu atau dua hari berikutnya dengan keberuntungan)

Saya juga tidak yakin tentang ini, tetapi mungkin kita hanya perlu memanggil .load() setelah kita membuat parser konfigurasi di sini untuk mendapatkan default konfigurasi

https://github.com/pypa/pipenv/blob/master/pipenv/project.py#L573 -#L577

@uranusjr selama konfigurasi mirroring berfungsi (yaitu tidak menggunakan URL pypi.org hardcoded yang saya sebutkan), saya tidak melihat ada masalah dengan pipenv yang memiliki konfigurasi sendiri untuk ini dan mengabaikan pip.

@brettdh Apakah Anda dapat memeriksa cabang saya dan mengonfirmasi bahwa itu memenuhi Anda
use case di lingkungan Anda?

>

@JacobHenner ya, terima kasih. Pengujian awal saya dengan opsi --pypi-mirror ( pipenv install , pipenv lock ) sepertinya berfungsi dengan baik. Saya meninggalkan saran kecil di PR.

Saya agak khawatir, bahwa URL hardcode ke pypi.org masih tampak tersebar di seluruh sumber pipenv. Saya tidak yakin mana yang ditimpa dengan benar dari entri [[source]] , dan saya tidak dapat mengingat dengan tepat alur kerja mana yang menyebabkan masalah saya di atas. Jadi sulit untuk mengatakan apakah itu sudah diperbaiki. 😬.

Ya setelah rilis ini saya merencanakan pembersihan kode utama. Barang-barang cli pindah ke cli, mengeluarkan pengecualian di sana dan menangani semua pintu keluar di sana, mengurangi kode duplikat, dll. Ini akan menjadi banyak pekerjaan dan bantuan akan dihargai jika ada yang ingin menjadi sukarelawan: p

Baru saja menarik versi terbaru dan masih melakukan hardcoding pypi.org di sources. Apakah tujuannya untuk mengambil variabel lingkungan atau pypi-mirror dan menjadikannya sebagai default untuk [[sumber]]?

edit:

Baru saja menggali kodenya.. Sepertinya sudah

if PIPENV_TEST_INDEX:
    DEFAULT_SOURCE = {
        u"url": PIPENV_TEST_INDEX,
        u"verify_ssl": True,
        u"name": u"custom",
    }
else:
    DEFAULT_SOURCE = {
        u"url": u"https://pypi.org/simple",
        u"verify_ssl": True,
        u"name": u"pypi",
    }

Saya pikir jika Anda mengubahnya Jika PIPENV_TEST_INDEX ke variabel lingkungan PIPENV_PYPI_MIRROR itu akan menjadi awal yang baik

Solusi yang dibahas di sini telah lama diterapkan. Cuplikan yang Anda kutip adalah default , yaitu digunakan jika Anda tidak memberikan sumber saat membuat Pipfile.

Tidak, sumber tidak boleh berubah di Pipfile. Tujuan dari perubahan ini
adalah untuk memungkinkan pengguna mengganti URL PyPI dengan cermin, _tanpa_ berubah
file Pip.

@JacobHenner Kode penanganan mirror mem-postprocess daftar sumber dan mengganti URL pypi.org dengan referensi ke mirror yang ditentukan.

Itulah yang memungkinkan penimpaan cermin berfungsi bahkan jika ada entri pypi.org eksplisit di Pipfile . pipenv kemudian bergantung pada logika yang sama untuk menimpa sumber defaultnya sendiri juga.

Jika saat ini ada kasus di mana postprocessing tidak diterapkan dengan benar, itu adalah laporan bug baru terhadap fitur yang sudah diterapkan, bukan permintaan fitur.

Saya pikir komentar terakhir ditujukan untuk @kylecribbs?

@JacobHenner Ah, maaf - saya salah menafsirkan komentar Anda dengan mengatakan bahwa perubahan ini tidak mencapai tujuan aslinya, bukan sebagai tanggapan terhadap Kyle yang bertujuan untuk mengklarifikasi apa sebenarnya hasil itu.