Pipenv: Penguncian lambat (dan melakukan unduhan yang berlebihan)

@colllin Sudahkah Anda memeriksa untuk melihat apakah perintah pip yang menghubungi server - seperti pip search (saya pikir) - juga lambat?

Saya melihat perilaku serupa, tetapi ini adalah masalah yang diketahui dan bergantung pada jaringan. Untuk beberapa alasan, akses ke pypi.org dari jaringan kerja saya sangat lambat tetapi biasanya cepat dari jaringan rumah saya. Saya pikir penguncian melakukan banyak transaksi pip di bawah tenda, jadi akses yang lambat ke server sangat memperlambat operasi.

EDIT: Mungkin juga Anda hanya memiliki banyak sub-dependensi untuk diselesaikan - seberapa besar lingkungan yang pernah dibuat (misalnya berapa banyak paket tingkat atas di pipfile Anda, dan berapa banyak paket yang dikembalikan oleh pip list setelah lingkungan di-bootstrap)?

Terima kasih atas tanggapan yang bijaksana.

pip search tidak terlalu cepat atau lambat bagi saya... ~1 detik?

Maafkan saya karena kurangnya pengetahuan domain saya: Apakah itu benar-benar perlu pencarian pip? Bukankah itu hanya menginstal semuanya? Bukankah hanya perlu menuliskan apa yang sudah terpasang? Atau... karena tetap memastikan keberadaan file kunci, dapatkah ia melakukan ini saat menginstal paket, atau sebelumnya?

Saya kira ... pipenv menggunakan pip di bawah tenda? jadi proses instalasi adalah kotak hitam, dan tidak dapat mengetahui grafik ketergantungan dari apa yang telah/akan diinstal tanpa melakukan ~pencarian pip~ kueri pipnya sendiri?

EDIT: Ada 1 paket tingkat atas, dan ~65 paket dikembalikan oleh pip list dalam repo khusus ini.

Saya bukan kontributor proyek dan saat ini saya tidak tahu semua secara spesifik, tetapi pemahaman saya adalah bahwa fase penguncian adalah di mana semua dependensi diselesaikan dan disematkan. Jadi, jika Anda memiliki satu paket tingkat atas dengan ~65 dependensi, selama fase penguncian semua dependensi paket pertama itu (secara rekursif) ditemukan, dan kemudian pohon dependensi digunakan untuk menyelesaikan paket mana yang perlu diinstal dan (mungkin) dalam urutan kasar apa mereka harus dipasang. Tidak begitu yakin tentang bagian terakhir.

Jika Anda menginstal pip dari Pipfile tanpa ada lockfile, Anda akan melihat bahwa ia melakukan fase penguncian sebelum menginstal paket ke dalam venv. Demikian pula jika Anda memiliki file kunci tetapi sudah kedaluwarsa. Saya menduga memiliki lockfile dan menginstal menggunakan opsi --deploy akan lebih cepat, seperti halnya opsi --no-lock ; dalam kasus sebelumnya Anda mendapatkan kesalahan jika lockfile kedaluwarsa, dalam kasus terakhir Anda kehilangan pemisahan logis dari paket tingkat atas (lingkungan yang dideklarasikan) dan lingkungan terinstal (terkunci) yang sebenarnya dari semua paket. Setidaknya beginilah cara saya memahaminya.

Apakah pipenv menggunakan pip di bawah tenda atau tidak - saya pikir itu - masih perlu mendapatkan informasi dari server pypi tentang dependensi paket dan sejenisnya, jadi pertanyaan saya tentang pencarian pip lebih merupakan proxy untuk seberapa cepat atau memperlambat jalur Anda ke server pypi lebih dari implikasi langsung tentang mekanisme yang pipenv lakukan.

Eksperimen yang menarik mungkin untuk membandingkan waktu yang diperlukan untuk mengunci pohon ketergantungan di pipenv, dan menginstal persyaratan ke venv baru menggunakan pip install -r requirements.txt . Saya pikir mereka harus melakukan hal yang sangat mirip selama fase resolusi ketergantungan.

Sudahkah kami menetapkan di suatu tempat bahwa ada unduhan yang berlebihan terjadi btw? Saya menduga itu masalahnya tetapi membuktikannya akan sangat membantu

FYI membandingkan pip install -r requirements.txt dengan waktu yang diperlukan untuk mengunci grafik ketergantungan tidak akan informatif sebagai titik perbandingan. Pip sebenarnya tidak _memiliki_ resolver, tidak dalam arti sebenarnya. Saya pikir saya bisa menggambarkan perbedaannya. Ketika pip menginstal requirements.txt , itu mengikuti proses dasar ini:

• Temukan persyaratan pertama yang tercantum
  
  
  
  • Temukan semua dependensinya
  
  
  • Instal semuanya
  
  
• Temukan persyaratan kedua yang tercantum
  
  
  
  • Temukan semua dependensinya
  
  
  • Instal semuanya
  
  
• Temukan persyaratan ketiga yang tercantum
  
  
  
  • Temukan semua dependensinya
  
  
  • Instal semuanya
  
  

Ini ternyata cukup cepat karena pip tidak terlalu peduli jika dependensi _package 1_ bertentangan dengan dependensi _package 3_, itu hanya menginstal yang di _package 3_ terakhir jadi itulah yang Anda dapatkan.

Pipenv mengikuti proses yang berbeda -- kami menghitung grafik resolusi yang mencoba memenuhi _semua_ dependensi yang Anda tentukan, sebelum kami membangun lingkungan Anda. Itu berarti kita harus mulai mengunduh, membandingkan, dan sering kali bahkan _membangun_ paket untuk menentukan seperti apa lingkungan Anda nantinya, semuanya bahkan sebelum kita memulai proses penginstalan yang sebenarnya (ada banyak posting blog tentang mengapa ini adalah kasus di python jadi saya tidak akan membahasnya lebih lanjut di sini).

Setiap langkah dari proses resolusi itu dibuat lebih mahal secara komputasi dengan membutuhkan hash, yang merupakan praktik terbaik. Kami meng-hash paket yang masuk setelah kami menerimanya, kemudian kami membandingkannya dengan hash yang menurut PyPI harus kami harapkan, dan kami menyimpan hash tersebut di lockfile sehingga di masa mendatang, orang yang ingin membangun lingkungan yang identik dapat melakukannya dengan jaminan kontraktual bahwa paket yang mereka buat adalah paket yang sama dengan yang Anda gunakan.

Pencarian pip adalah tolok ukur yang buruk untuk semua ini, sebenarnya alat pip mana pun adalah tolok ukur yang buruk untuk melakukan pekerjaan ini -- kami menggunakan pip untuk setiap bagiannya, tetapi menggabungkannya bersama-sama dan melintasi banyak dependensi untuk dibentuk dan dikelola lingkungan dan grafik adalah tempat nilai pipenv ditambahkan.

Satu poin klarifikasi -- setelah Anda menyelesaikan grafik ketergantungan penuh, urutan penginstalan seharusnya tidak menjadi masalah lagi. Di bawah tenda, kami benar-benar meneruskan --no-deps ke setiap instalasi.

Sebagai catatan kecil, pencarian pip saat ini adalah satu-satunya alat pip yang bergantung pada antarmuka XMLRPC yang sekarang tidak digunakan lagi, yang tidak dapat di-cache dan sangat lambat. Itu akan selalu lebih lambat daripada operasi lainnya.

Mengunci numpy (dan tidak ada yang lain) membutuhkan waktu 220 detik di mesin saya (lihat di bawah). Sebagian besar waktu tampaknya dihabiskan untuk mengunduh lebih dari 200MB data, yang cukup membingungkan mengingat seluruh sumber numpy memiliki 4 MB. Meskipun jelas bahkan jika itu instan, masih ada 25 detik pemrosesan yang sebenarnya, dan bahkan itu tampaknya berlebihan untuk menghitung beberapa hash. Penguncian berikutnya, bahkan setelah menghapus Pipenv.lock, membutuhkan waktu 5 detik.

11:46 ~/Co/Ce/torchdft time pipenv install
Creating a virtualenv for this project…
Using /usr/local/Cellar/pipenv/2018.5.18/libexec/bin/python3.6 (3.6.5) to create virtualenv…
⠋Already using interpreter /usr/local/Cellar/pipenv/2018.5.18/libexec/bin/python3.6
Using real prefix '/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6'
New python executable in /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t/bin/python3.6
Also creating executable in /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t
Creating a Pipfile for this project…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (ca72e7)!
Installing dependencies from Pipfile.lock (ca72e7)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 0/0 — 00:00:00
To activate this project's virtualenv, run the following:
 $ pipenv shell
        7.81 real         6.39 user         1.64 sys
11:46 ~/Co/Ce/torchdft time pipenv install numpy --skip-lock
Installing numpy…
Collecting numpy
  Using cached https://files.pythonhosted.org/packages/f6/cd/b2c50b5190b66c711c23ef23c41d450297eb5a54d2033f8dcb3b8b13ac85/numpy-1.14.5-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
Installing collected packages: numpy
Successfully installed numpy-1.14.5

Adding numpy to Pipfile's [packages]…
        4.97 real         2.88 user         1.81 sys
11:46 ~/Co/Ce/torchdft time pipenv lock --verbose
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1                           
Current constraints:

Finding the best candidates:

Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done

Locking [packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1                           
Current constraints:
  numpy

Finding the best candidates:
  found candidate numpy==1.14.5 (constraint was <any>)

Finding secondary dependencies:
  numpy==1.14.5 not in cache, need to check index
  numpy==1.14.5             requires -
------------------------------------------------------------
Result of round 1: stable, done

Updated Pipfile.lock (4fccdf)!
      219.24 real        25.14 user         5.77 sys

Numpy seharusnya jauh lebih cepat sekarang (sebenarnya saya telah menggunakan contoh Anda sebagai kasus uji!). Pada pengujian terbaru saya, saya memilikinya di ~ 30 detik pada cache dingin di vm.

Bisakah Anda mengonfirmasi peningkatan apa pun dengan rilis terbaru?

Ini telah meningkat secara substansial bagi saya juga. Saya sekarang duduk di koneksi yang sangat cepat, dan mendapat serendah 14 dtk, tetapi saat itulah unduhan berjalan pada 30 MB/dtk. Apa yang sedang diunduh selain satu salinan kode sumber numpy?

Saya pikir kami sedang mengunduh roda yang berlebihan (tidak yakin). Kami sudah mengevaluasi situasinya.

Saya mengubah Pipfile.lock saya secara drastis dengan menghapus perubahan fe dan sekarang menerapkannya pada mesin yang berbeda membeku. Adakah perbaikan khusus untuk ini?

Anda tidak disarankan untuk mengedit file kunci Anda secara manual. Tanpa informasi lebih lanjut, tidak mungkin untuk membantu. Silakan buka edisi terpisah.

Jika Anda ingin membandingkan kinerja kunci pipenv, Anda harus mencoba menambahkan pytmx ke dependensi Anda ...
pipenv lock digunakan untuk mengambil 1 jam atau lebih untuk kami (kami memiliki internet yang cukup lambat), dan setelah menghapus pytmx, kami turun menjadi sekitar 5 menit dan akhirnya pipenv lebih dapat digunakan.
Saya tahu pytmx adalah paket besar karena ini adalah lib monolitik besar dan tergantung pada opengl/pygame dan hal-hal terkait lainnya, tetapi tidak perlu 1 jam untuk mengunci pipenv tidak peduli seberapa besar paketnya

Tidak butuh satu jam untukku

$ cat Pipfile
[packages]
pytmx = "*"

$ time pipenv lock --clear
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
Updated Pipfile.lock (eb50ab)!

real    0m2.827s
user    0m2.287s
sys 0m0.390s

Juga PyTMX kurang dari 20kb pada PyPI, dan hanya memiliki satu ketergantungan hingga enam (yang sangat kecil), jadi jaringan seharusnya tidak menjadi masalah. Kemungkinan ada hal lain yang terjadi di lingkungan Anda.

Anda benar itu lebih kecil dari yang saya kira tidak tergantung secara eksplisit pada pygame dan semacamnya, tidak yakin mengapa butuh waktu lama!
Saya akan mencoba mencari informasi lebih lanjut tetapi saya memiliki CPU dan SSD teratas jadi saya masih berpikir masalahnya terkait dengan internet kami yang lambat

@techalchemy Saya tidak mengedit file secara manual. Saya menghapus banyak dependensi menggunakan pipenv uninstall package_name dan kemudian menjalankannya di server. Itu tetap dalam keadaan terkunci untuk waktu yang sangat lama.

Saya tidak tertarik menghabiskan energi untuk diskusi ini dengan bidikan acak dalam gelap. Harap berikan kasus uji yang dapat direproduksi.

Inilah yang saya harap adalah kasus uji yang dapat direproduksi
https://github.com/Mathspy/tic-tac-toe-NN/tree/ab6731d216c66f5e09a4dabbe383df6dc745ba18

Mencoba melakukan
pipenv install
dalam repositori tanpa kunci ini sejauh ini telah mengunduh lebih dari 700MB atau lebih saat ditampilkan
Locking [packages] dependencies...

Akan menyerah sedikit dan jalankan kembali dengan --skip-lock sampai diperbaiki

Saya perhatikan bahwa lock sangat lambat dan mengunduh sejumlah besar data dari files.pythonhosted.org , lebih dari 800MB untuk proyek kecil yang bergantung pada scipy flask dll.

Jadi saya mengendus permintaan yang dibuat ke files.pythonhosted.org , dan ternyata pip atau pipenv melakukan unduhan yang sama sekali tidak perlu, yang membuat lock sangat lambat.

Misalnya, versi yang sama numpy telah diunduh beberapa kali secara penuh. Dan itu mengunduh roda untuk windows / linux, meskipun saya menggunakan Mac.

Pengaturan saya:

$ pipenv --version
pipenv, version 2018.05.18

$ pip -V
pip 18.0 from /usr/local/lib/python2.7/site-packages/pip (python 2.7)

apakah Pipfile tambahan berguna untuk debugging di sini?

Kemungkinan besar @AlJohri , juga info tentang menjalankan proses / kunci / io akan membantu

Sudah terjebak di sini selama sekitar 5 menit. Pertama kali mengira itu mungkin semacam masalah pemasangan pip dan menginstal ulang semuanya baru melalui Homebrew, tetapi masih masalah yang sama. Ada ide kenapa?

Akhirnya selesai setelah sekitar 6 - 7 menit. Cukup baru untuk Python dan Pipenv, jadi sedikit bantuan tentang di mana menemukan file yang diperlukan untuk debugging akan sangat bagus! :)

ini sangat buruk sampai-sampai saya takut menginstal lib python baru atau memutakhirkan yang sudah ada.

Setelah menonton salah satu ceramah dari pembuatnya, saya memutuskan untuk menggunakan pipenv . Tapi itu terlalu lambat.

Terima kasih atas masukan Anda yang berwawasan.

@techalchemy Jika ada sesuatu yang bisa saya lakukan untuk membantu dan memperbaikinya. Saya sangat senang berkontribusi.

Saya perhatikan bahwa lock sangat lambat dan mengunduh sejumlah besar data dari files.pythonhosted.org , lebih dari 800MB untuk proyek kecil yang bergantung pada scipy flask dll.

Saya memiliki kecurigaan, meskipun bukan bukti yang meyakinkan, bahwa scipy berkorelasi dengan waktu penguncian pipenv sangat lama.

terkadang sangat menyakitkan, saya menginstal PyPDF2 dan teks; pipenv membutuhkan waktu ~10 menit untuk mengunci.

Lambatnya pipenv sangat menghambat proses dev bagi kami. Saya sekarang menyarankan semua orang untuk tetap menggunakan pip + virtualenv sampai masalah ini teratasi.

Ada berita tentang ini? Ada cara untuk membantu?
penipuan https://github.com/pypa/pipenv/issues/1914

/ edit: btw, mengapa pipenv install memperbarui versi di lockfile? o.Ò Saya baru saja menjalankannya setelah waktu penguncian habis dan sekarang saya melihat file kunci baru saya melihat pandas telah diperbarui dari 0.23.4 ke 0.24.0, numpy dari 0.16.0 ke 0.16.1, dll... Tidak jangan berharap itu terjadi kecuali saya melakukan pipenv update ...

Saya menemukan itu menginstal dengan cepat dan mengunci perlahan, jadi segera setelah Anda mendapatkan Installation Succeeded pesan Anda baik untuk terus bekerja... kecuali jika Anda ingin menginstal sesuatu yang lain...

... atau perlu mendorong file kunci ke beberapa repo.

Haruskah install menjadi kunci pra-bentuk, melihat bahwa lock sudah merupakan perintah yang terpisah? Sementara itu deskripsi opsi install harus menentukan bahwa penguncian juga terjadi, dan bahkan mungkin merekomendasikan --skip-lock .

Juga, bagaimana dengan menyematkan masalah ini?

Pipenv adalah alat yang sangat bagus dan saya pernah merekomendasikannya, tetapi proyek dengan 8 modul tidak dapat mengunci... waktu habis. Tampaknya tidak ada minat untuk memecahkan masalah ini dan itu sangat membuat frustrasi. Saya membaca Anda bisa mendapatkan dependensi tanpa mengunduh dari pypy sekarang, apakah itu solusi untuk masalah ini? Tidak ada pembicaraan tentang opsi itu di sini. Saat ini alat tersebut tidak dapat digunakan untuk tujuan saya.

pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x10e12e400> searcher: searcher_re: 0: re.compile('\n') <pexpect.popen_spawn.PopenSpawn object at 0x10e12e400> searcher: searcher_re: 0: re.compile('\n') pipenv lock -r 87.22s user 18.57s system 11% cpu 15:02.77 total

Bagaimana ini bukan prioritas utama untuk proyek ini? Pipenv sangat lambat sehingga tidak dapat digunakan. Tidak hanya di beberapa kasus penggunaan yang tidak biasa, itu

Tanpa mengetahui terlalu banyak tentang apa yang terjadi di bawah tenda, saya berpikir bahwa ini mungkin diselesaikan dengan baik dengan cache lokal dari grafik ketergantungan.

Pikirkan tentang hal ini: jika kita men-cache paket itu x-1.2.3 bergantung pada y>=3.4 , kita dapat secara lokal melakukan banyak pekerjaan yang saat ini dilakukan dalam mengunduh paket satu per satu, memperluasnya, dan memeriksa dependensi . Fase lock akan sesederhana:

• Bandingkan Pipfile dengan cache dan pastikan kami memiliki semua yang kami butuhkan.
• Jika tidak, unduh sesuatu yang baru dan hitung dependensi di sana
  
  
  
  • Cache perubahannya
  
  
• Install.

Dalam setiap kasus, sementara pertama kali mungkin lambat, kunci berikutnya tidak akan menimbulkan rasa sakit, bukan?

Saya baru saja memutuskan untuk menggunakan pipenv daripada pip untuk proyek kecil. Hal pertama yang saya lakukan adalah pipenv install -r requirements.txt . Sudah mengunci dependensi selama sekitar 10 menit sekarang. Oleh karena itu, saya akan kembali ke pip.

Kawan, masalah ini merugikan banyak pengguna. Saya mengusulkan untuk mengatasinya dengan cepat.

Dalam kasus saya, menginstal dependensi di server membuat server hang selama berjam-jam. Saya menggunakan instance AWS EC2 t2.micro dengan RAM 1 GB. RAM sebesar ini cukup untuk satu aplikasi dengan sedikit ketergantungan tetapi penginstalan mengambil semua memori dan hanya ada satu cara untuk membuatnya bekerja dengan memulai ulang server.

Masalah ini tertunda selama bertahun-tahun dan tidak ada perbaikan yang dilakukan untuk ini. Saya melihat banyak masalah ditutup tanpa penyelesaian apa pun.

Alat yang bagus seperti itu diabaikan. Saya akan berhenti berlangganan dari masalah ini karena saya melihatnya tidak akan pernah terselesaikan. Akan menempel pada sesuatu seperti conda atau melakukannya secara manual menggunakan virtualenv.

Kira saya akan mencoba https://github.com/sdispater/poetry :|

Bisakah admin menutup utas ini dengan komentar? Sepertinya tidak ada konten tambahan bermanfaat yang ditambahkan ke diskusi.

Saya akan dengan senang hati berlangganan tiket yang melacak upaya untuk memperbaiki masalah tersebut.

Terima kasih!

Saya menduga 99% orang yang menggunakan alat ini dan mengeluh di utas ini adalah programmer. Alih-alih merengek, luangkan waktu Anda di mana mulut Anda berada dan kirimkan PR.

Halo @idvorkin ,

Saya sudah mencoba sekali .
Butuh waktu berminggu-minggu untuk mencapai penggabungan perbaikan sepele .
Bandingkan saja jumlah diskusi dengan ukuran perbaikan yang sebenarnya.

Saya pasti tidak ingin mengirimkan perbaikan lagi untuk proyek ini.

Jadi saran Anda tidak sebagus yang Anda bayangkan.

@Jamim atas nama banyak pengguna (dan saya menduga admin juga), terima kasih atas kontribusi Anda. Saya membaca PR Anda, dan saya bisa berempati dengan frustrasi. Namun, saya harus setuju dengan @techalchemy yang satu ini:

Tentu saja kami peduli dengan perpustakaan yang kami kelola, tetapi saya menyarankan bahwa ungkapan mungkin bukan cara paling efektif untuk memiliki interaksi positif.

Saya belum pernah bertemu dengan admin, tetapi jika mereka seperti saya (dan mungkin Anda) mereka adalah manusia dengan kehidupan sibuk yang hidupnya penuh dengan komitmen bahkan sebelum mereka memiliki energi untuk dibelanjakan pada proyek ini.

Demikian pula, saya yakin jika Anda (atau siapa pun) memperbaiki masalah kinerja, Anda akan memiliki banyak orang yang akan membantu Anda mengembangkan, menguji, menggabungkannya, atau jika diperlukan (dan saya sangat meragukannya) membuat garpu .

Saya berterima kasih atas waktu yang dihabiskan oleh pengembang proyek ini untuk hal ini, tetapi saya menyarankan bahwa harus diperingatkan dengan huruf tebal bahwa proyek ini belum siap produksi tepat di atas testimonial pengguna di README.md , saat ini sedang menyesatkan orang untuk menghabiskan waktu berharga untuk mengganti tumpukan pip/virtualenv mereka saat ini dengan pipenv sampai mereka mengetahui tentang penguncian lambat ini dan mereka mengerti bahwa mereka tidak dapat menggunakannya.

sampai mereka mengetahui tentang penguncian lambat ini dan mereka mengerti bahwa mereka tidak dapat menggunakannya.

Sementara saya sangat senang untuk mendapatkan kecepatan karena memang sangat lambat, tidak perlu hiperbola seperti itu.

Saya menggunakan pipenv dengan baik setiap hari. Peningkatan alur kerja yang diberikannya sangat melebihi kelambatan sesekali. Mengunci bukanlah sesuatu yang saya lakukan sepanjang waktu, berbeda dengan menjalankan skrip misalnya.

Seberapa sering Anda mengunci sehingga benar-benar menjadi masalah sehingga Anda merasa tidak dapat menggunakannya? :Buka mulut:

@bochecha pernyataan saya mungkin hiperbola menurut Anda tetapi itu fakta berdasarkan pengalaman saya, saya mendengar tentang pipenv dari beberapa rekan kerja, hari ini saya mencoba memperbarui proyek lama, memperbarui dependensinya, dll. Saya pikir mari perbarui dari pip/virtualenv ke pipenv sebagai bagian dari proses pembaruan. Saya harus memperbarui ketergantungan, memeriksa cara kerjanya, memperbarui bagian kode jika diperlukan dan kemudian memperbarui ketergantungan lain, setiap kali saya menjalankan pipenv install <something> Saya harus menunggu sangat lama, pertama saya pikir itu menghitung sesuatu dan itu akan menyimpannya untuk masa depan karena saya tidak percaya itu masalah dalam mengklaim sebagai manajer paket siap produksi. Setelah menginstal ~ paket ke-10 saya mulai mencari tentangnya dan saya menemukan utas ini, saya menghapus Pipfile dan Pipfile.lock dan kembali ke alur kerja pip/virtualenv saya. Saya tergoda untuk mencoba puisi tetapi saya tidak bisa mengambil risiko satu jam lagi.

Hal ini terjadi di komunitas JS misalnya tetapi saya tidak mengharapkannya di komunitas Python, kami tidak memiliki masalah seperti ini di komunitas kami dan kami harus mencoba menghindarinya, penafian di README.md dapat menghindari ketidaknyamanan ini jadi saya menyarankannya dalam komentar saya. Itu bisa menghemat waktu saya hari ini dan saya pikir itu akan menghemat waktu untuk pendatang baru lainnya dan mereka tidak akan memiliki pengalaman buruk dengan proyek ini sehingga mereka dapat tetap sebagai calon pengguna masa depan.

Saya agak setuju dengan sassanh. Tidak semua orang sama-sama terpengaruh oleh masalah ini, tetapi beberapa dari kita terpengaruh dengan sangat buruk. Saya telah membuat proyek sumber terbuka yang tidak benar-benar berfungsi penuh atau siap produksi dan ketika itu terjadi saya meletakkan penafian di atasnya sehingga saya tidak membuang waktu orang jika mereka tidak siap untuk gundukan.

Saya tidak marah pada orang-orang yang mengerjakan proyek ini tetapi saya agak marah pada orang yang membuat pembicaraan publik tentangnya, menjualnya sebagai alat yang hebat dengan 0 penafian. Akibatnya, saya membuang cukup banyak waktu berharga saya untuk mencoba membuat alat berfungsi, berharap untuk menghemat waktu dalam jangka panjang, tetapi saya akhirnya harus kembali ke pip dan skrip saya sendiri, karena pipenv tidak berfungsi di lingkungan saya yang dibatasi waktu dan bandwidth.

setiap kali saya menjalankan pipenv install

Tahukah Anda tentang pipenv install -r requirements.txt untuk mengunci/menginstal hanya sekali dari proyek yang ada saat Anda mencoba memindahkannya ke pipenv? Jika tidak, masalahnya mungkin salah satu dokumentasi?

Sebelum apa pun saya yakin bahwa pipenv akan menjadi pengganti yang baik untuk alur kerja pip/virtualenv, saya kira kita semua tahu bahwa kita membutuhkannya dan saya pikir hari pipenv siap produksi itu akan sangat membantu banyak orang/proyek.

@bochecha seperti yang saya jelaskan saya harus menginstal versi paket yang lebih baru, melakukan beberapa hal dan kemudian pergi dengan paket berikutnya, mungkin jika saya melakukan proses ini dengan pip dan kemudian bermigrasi ke pipenv saya tidak akan melihat masalah sama sekali, tetapi saya pertama kali bermigrasi ke pipenv dan kemudian melakukan pembaruan paket satu per satu dan itu sangat mengganggu. Saya senang ini berfungsi untuk kasus penggunaan Anda, tetapi saya yakin itu tidak berfungsi untuk banyak orang seperti saya (lihat komentar di atas). Itu harus disebutkan dalam README.md , setidaknya harus disebutkan bahwa "setiap penguncian mungkin memakan waktu lama, jadi jika usecase Anda termasuk menginstal/menghapus banyak paket dengan cepat, Anda harus menghindari penggunaan pipenv sampai masalah ini selesai. diselesaikan" (sekali lagi dalam huruf tebal, dan di atas testimonial) jika Anda mengumumkan masalah sebelum ada yang terpengaruh olehnya, semua orang akan berterima kasih, jika masalah memengaruhi orang lain dan Anda tidak memperingatkan mereka, semua orang akan marah.

Sepakat. Saya mulai mencari puisi dan meskipun menambahkan pengguna lain ke OS saya per proyek alih-alih menggunakan pipenv lagi. Jika tidak berfungsi dengan baik untuk kasus penggunaan biasa dengan pengaturan default itu rusak imho .
Ini adalah alat yang sangat berguna! Hanya ada satu hal yang membuatnya sangat tidak berguna bagiku. Dan sayangnya saya hanya punya sedikit waktu untuk berkontribusi :|

Tentu, itu menjengkelkan menunggu kunci ketika harus melakukan beberapa pemasangan di pertengahan sesi pengembangan, tetapi ini dapat dikelola.

Yang penting adalah file kunci dibuat sebelum mendorong perubahan lokal ke repo. Saya menggunakan flag —skip-lock dengan bijaksana selama sesi dev, dan pipenv lock sekali di akhir sebelum saya komit.

Terima kasih untuk proyeknya. Tetapi,
Penguncian verrrrrrrrrrrrrrrrrrrrrrrrrrrrry lambat

PIP_NO_CACHE_DIR=off
Env ini membuat penguncian lebih cepat, jika sudah menginstal cache paket pip.

Hai @yssource dan semuanya,

Terima kasih untuk proyeknya. Tetapi,
Penguncian verrrrrrrrrrrrrrrrrrrrrrrrrrrrry lambat

Proyek ini tampaknya sudah mati, jadi jika Anda ingin menghilangkan masalah kecepatan, pertimbangkan untuk bermigrasi ke Poetry yang secara signifikan lebih cepat.

@Jamim , terima kasih telah menyarankan Puisi. Secara pribadi, untuk beberapa alasan saya tidak menemukannya. Setelah membaca readme-nya sepertinya pantas untuk dicoba. Ini juga mencantumkan beberapa manfaat dibandingkan Pipenv (https://github.com/sdispater/poetry/#what-about-pipenv).

Karena itu, proyek yang mati adalah pernyataan yang berlebihan, dan jika saya berada di posisi penulis pipenv, saya akan menganggapnya tidak sopan. Penulis menjawab di bagian masalah baru kemarin. Hanya saja masalah penguncian ini diabaikan, mungkin karena sulit untuk diperbaiki.

Sebagai catatan, Puisi menderita masalah kinerja juga:
https://github.com/sdispater/poetry/issues/338

Saya memiliki masalah yang sama di semua proyek saya.
Penyebabnya tampaknya pylint.
Pipenv (pip) dapat menginstalnya dengan sukses, tetapi penguncian membutuhkan waktu lama!
pipenv, version 2018.11.26

djbrown@DESKTOP-65P6D75:~$ mkdir test
djbrown@DESKTOP-65P6D75:~$ cd test
djbrown@DESKTOP-65P6D75:~/test$ pipenv install --dev pylint --verbose
Creating a virtualenv for this project…
Pipfile: /home/djbrown/test/Pipfile
Using /usr/bin/python3 (3.6.9) to create virtualenv…
⠸ Creating virtual environment...Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/python3
Also creating executable in /home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/python
Installing setuptools, pip, wheel...done.

✔ Successfully created virtual environment!
Virtualenv location: /home/djbrown/.local/share/virtualenvs/test-PW-auWy_
Creating a Pipfile for this project…
Installing pylint…
⠋ Installing...Installing 'pylint'
$ ['/home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/pip', 'install', '--verbose', '--upgrade', 'pylint', '-i', 'https://pypi.org/simple']
Adding pylint to Pipfile's [dev-packages]…
✔ Installation Succeeded
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
⠇ Locking...

Saya mendengar tentang pipenv banyak dan mencobanya hari ini,
pengunciannya juga sangat lambat bagi saya. Sudah sekitar 2 menit, masih stuck di locking.
Mengunduh cukup cepat, tetapi masalahnya adalah penguncian.
Apakah masalah ini terselesaikan?
Saya menggunakan Pop os 19.10, pipenv, versi 11.9.0 dari apt, python 3.7.5.

Saya ingin menarik perhatian pada komentar luar biasa dari #1914 tentang topik yang sama https://github.com/pypa/pipenv/issues/1914#issuecomment -457965038 yang menyarankan bahwa mengunduh dan menjalankan setiap ketergantungan tidak diperlukan lagi.

Saya ingin tahu apakah ada pengembang yang dapat mengomentari kelayakan pendekatan ini.

Saya perhatikan bahwa sebenarnya lebih cepat untuk menghapus lingkungan dan membuatnya kembali dari awal untuk memperbarui file kunci.
Ini berlaku untuk menjalankan pipenv lock dan pipenv install some-package

Saya sangat suka pipenv tetapi tidak sebanyak yang saya suka bandwidth dan waktu saya. Jadi saya akhirnya menyelesaikan masalah menggunakan:

$ pipenv --rm
$ virtualenv .
$ source bin/activate
$ # Create a requirement file (Cause pipenv lock -r > requirements.txt... you know!)
$ pip install -r requirement.txt

Semoga para developer sukses...

@ravexina terima kasih atas sarannya, saya pasti akan mencoba