Pipenv: Pembaruan kunci sangat lambat

Kami sadar dan memiliki banyak masalah dalam melacak topik ini. Lihat #1785 #1886 #1891 dan PR #1896

npm dan yarn memiliki keuntungan karena tidak harus sepenuhnya mengunduh dan mengeksekusi setiap paket prospektif untuk menentukan grafik dependensinya karena dependensi ditentukan dalam plaintext. Ketergantungan Python mengharuskan kita untuk sepenuhnya mengunduh dan menjalankan file pengaturan dari setiap paket untuk diselesaikan dan dihitung. Itu hanya kenyataannya, itu agak lambat. Jika Anda tidak bisa menunggu 2 menit atau Anda merasa itu tidak sepadan dengan pengorbanannya, Anda selalu dapat melewati --skip-lock .

Penutupan untuk melacak dalam masalah lain.

Sama di sini saya mencobanya sekarang dan menginstal Django sudah 10 menit dan pergi

tampaknya jika Anda mencoba dan menginstal beberapa sekaligus lambat tetapi jika Anda melakukannya satu per satu bekerja sedikit lebih cepat

Jika Anda dapat memberikan Pipfile yang mereproduksi perilaku lambat itu akan sangat membantu -- terima kasih

Ketergantungan Python mengharuskan kita untuk sepenuhnya mengunduh dan menjalankan file pengaturan dari setiap paket untuk diselesaikan dan dihitung

Apakah ini masih terjadi ketika paket memiliki Pipfile.lock , atau akankah pipenv menggunakannya jika memungkinkan untuk menentukan dependensi?

akankah pipenv menggunakannya jika memungkinkan untuk menentukan dependensi?

Tidak. Pipenv adalah alat resolusi ketergantungan aplikasi. Ketika ketergantungan digunakan sebagai paket Python oleh aplikasi lain, itu bukan lagi sebuah aplikasi. Ketergantungannya ditentukan oleh setup.py (atau setup.cfg atau apa pun yang Anda gunakan untuk mengunggah ke PyPI). Memuat dependensi dari file kunci adalah rute pasti menuju neraka ketergantungan, kemungkinan besar kita tidak akan pernah melakukannya.

Masih sangat lambat

@iddan Terima kasih untuk pengingatnya, Kapten Jelas!

Maaf, sebagai pengelola OSS, saya tahu bagaimana terkadang masalah bisa diabaikan karena usia. Hanya ingin menyatakan bahwa bahkan masalah tersebut mendapat diskusi, itu masih relevan

@techalchemy catatan --skip-lock atas luar biasa. Ini harus menjadi pilihan yang lebih mudah diakses atau dipublikasikan. Bisakah kita mengaturnya sebagai default di suatu tempat?

@techalchemy bagaimana jika dibutuhkan 20 menit dengan mac pro baru saya?

@techalchemy catatan --skip-lock atas luar biasa. Ini harus menjadi pilihan yang lebih mudah diakses atau dipublikasikan. Bisakah kita mengaturnya sebagai default di suatu tempat?

Sejauh yang saya kumpulkan, manfaat luar biasa dari pipenv adalah dependensi jaminan akan bermain dengan baik bersama - tidak hanya untuk Anda, tetapi untuk siapa pun yang kemudian berurusan dengan kode Anda. Produk jaminan itu, file kunci, benar-benar membutuhkan lebih banyak waktu daripada yang diharapkan atau diinginkan siapa pun, _termasuk pengembang_ — lihat #2200.

Namun, saya pikir Anda juga dapat memahami peluang yang pipenv miliki untuk menggiring para pengembang yang bermaksud baik di komunitas Python pada umumnya menuju alur kerja yang memaksakan lebih sedikit masalah pada kontributor masa depan — yang mungkin hanya menjadi pengunjung jika mereka menyerah selama " cari tahu cara mengatur tahap lingkungan dev"; dan lebih sedikit tangan yang dilemparkan oleh pengelola masa depan — yang mungkin hanya menjadi penulis PR jika mereka menyerah selama tahap "serius mengacaukan internal proyek yang dalam".

Jika --skip-lock menjadi bendera permanen di Pipfile atau pengaturan dalam konfigurasi pipenv, persepsi pipenv perlahan akan meluncur ke arah "pip yang lebih baik", dan hanya batu loncatan lain yang memudar ke cakrawala saat komunitas akhirnya mendarat penerus spiritual yang kurang kompromi.

Lebih baik membiarkannya hanya tersedia sebagai env var, atau beberapa metode lain yang aplikasinya terletak tepat di wilayah _"konfigurasi lokal khusus pengguna Anda, kesalahan Anda"_, memungkinkan pipenv untuk mengatasi fase yang lewat dari kelambatan pembuatan file kunci tanpa menyerah pergeseran budaya yang benar-benar bermanfaat menuju _eksplisititas daripada implisit_ dalam manajemen paket.

Pustaka standar Python yang sangat luas adalah aset yang sangat besar, yang sejarahnya telah mengalami banyak era konsistensi yang mengesankan. Bahwa sebagian besar paket standar bermain dengan baik bersama-sama adalah prestasi besar yang melibatkan pertimbangan selama bertahun-tahun oleh banyak orang. Suatu hari, kemampuan bermain-bagus itu akan meluas ke sebagian besar proyek Python yang ditemui di web — jauh, jauh dari stdlib, dan dengan jauh, jauh lebih sedikit PEP yang dibutuhkan (_dan jauh, jauh lebih sedikit BDFL yang kosong karena frustrasi_). Dampak dari pengalaman mentega sepihak seperti itu sulit diukur, tetapi beberapa bahasa saat ini _did_ menolak untuk mengkompromikan integritas konseptual untuk kenyamanan langsung... dan oh, tempat yang akan mereka tuju .

Jadi _yes_, menghasilkan lockfile lambat, dan _yes_, itu membuat frustrasi ketika Anda hanya menginginkan pip install --save . Tapi itu hanya karena kami telah menyapu seekor gajah ke dalam lemari selama bertahun-tahun — percaya bahwa kami tidak memiliki harapan dan niat yang kacau balau dari ketergantungan eksternal, karena _"itu terpasang dengan baik di mesin saya"_.

Pembuatan file kunci lambat _only_ karena membuat eksplisit apa yang kita semua anggap remeh. Tapi _karena_ sakit , kami akan menyesuaikan hal-hal agar tidak. Kami mematahkan lengan kami karena kami memaksakan diri melakukan hal-hal yang kami yakini. Tentu, kami dapat menghindari rasa sakit dengan tidak pernah menggunakan lengan itu lagi— atau kami dapat memasang gips selama penyembuhan.

Saya akan menjadi orang terakhir yang memberi tahu Anda untuk tidak membuat pipenv nyaman untuk diri Anda sendiri hari ini (jika tidak, saya akan menjadi pengembang yang menyebalkan — _meskipun, juri masih keluar_), tetapi saya mohon Anda untuk melihat frustrasi pembuatan lockfile sebagai pertumbuhan rasa sakit sementara komunitas Python berkembang menjadi tubuh yang kuat dan sehat dengan anggota tubuh yang berfungsi lebih penuh daripada yang diharapkan saat melepas gips. Kami berhasil mencapai Python 3. Mari kita membuatnya ke manajemen ketergantungan di stdlib.

Ini membutuhkan waktu 38 menit di mesin saya untuk membuat file kunci. Menjalankan Windows 10 dan menggunakan Python 3.7

Hanya numpy dan bantal yang sudah terpasang dan butuh waktu <1 detik untuk memasang numba dan 25 menit untuk menguncinya. Apakah pipenv secara paksa mengkompilasi setiap lib pada kunci atau bagaimana cara kerjanya?

FYI persisten skip lock hanya menunggu seseorang untuk membalik tombol untuk auto_envvar_prefix yang merupakan pengaturan klik. Saya telah 100% fokus pada fungsionalitas inti, jadi saya belum memiliki kesempatan untuk melihat ini, tetapi saya kira itu tidak terlalu sulit

TLDR; Pemanggilan pipenv install tipikal: Waktu : 144,82 real 33,68 pengguna 5,77 sys. Dengan --skip-lock : Waktu : 4,54 real 5,33 pengguna 0,87 sys.

Instalasi Pandas-datareader gagal pada upaya pertama, mungkin menyebabkan lock hang. Apakah ini masalah yang dilihat orang lain dengan paket lain?

Menggunakan versi 2018.11.26

$ pipenv --version
pipenv, version 2018.11.26

Isi requirements.txt

sklearn
pandas
numpy
matplotlib
statsmodels

Pemanggilan pipenv install . Eksekusi berjangka waktu menggunakan time (BSD).

Hasil : 144,82 real 33,68 pengguna 5,77 sys

$ time pipenv install -r requirements.txt
Requirements file provided! Importing into Pipfile…
Pipfile.lock (0fdb67) out of date, updating to (a65489)…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
✔ Success!
Updated Pipfile.lock (0fdb67)!
Installing dependencies from Pipfile.lock (0fdb67)…
  🎅   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 15/15 — 00:00:04
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
      144.82 real        33.68 user         5.77 sys

Memanggil w\ --skip-lock

Hasil : 4,54 nyata 5,33 pengguna 0,87 sistem

$ time pipenv install -r requirements.txt --skip-lock
Requirements file provided! Importing into Pipfile…
Installing dependencies from Pipfile…
  🎅   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 6/6 — 00:00:01
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
        4.54 real         5.33 user         0.87 sys

Saya pikir https://github.com/pandas-dev/pandas/ mungkin menjadi masalah? Ini adalah poin yang sama dengan waktu bagi saya juga.

Meskipun pytest mungkin juga menjadi masalah :\

Itu bahkan tidak akan selesai di mesin saya:

Installing pandas…
Adding pandas to Pipfile's [packages]…
Installation Succeeded
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Traceback (most recent call last):
  File "c:\python36\lib\site-packages\pipenv\vendor\pexpect\expect.py", line 109, in expect_loop
    return self.timeout()
  File "c:\python36\lib\site-packages\pipenv\vendor\pexpect\expect.py", line 82, in timeout
    raise TIMEOUT(msg)
pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x00000292ADCCCDD8>
searcher: searcher_re:
    0: re.compile('\n')

@black-snow Saya akan merekomendasikan mencobanya di shell yang berbeda. Tanpa menyelam terlalu jauh ke dalam berbagai hal, sepertinya peexpect (perpustakaan untuk antarmuka program dengan program CLI interaktif) digunakan untuk mendeteksi shell pipenv sedang dieksekusi, dan itu mungkin macet. peexpect agak berlebihan untuk hal seperti itu, tapi saya tidak mengetahui keseluruhan konteksnya.

@theY4Kman terima kasih atas sarannya. pipenv berfungsi dengan baik di pc lain dengan versi ubuntu dan bash yang sama ...

Baca ini sambil menunggu pipfile untuk mengunci... :) Akan lebih bagus jika ada solusi.

Sepertinya kita membutuhkan semacam API untuk mengurai dan men-cache deps paket Python dan mendistribusikannya dalam format yang ramah mesin. Jadi kita tidak perlu lagi mengunduh seluruh paket dan menguraikannya.

Saya percaya bundler dan permata ruby ​​mempertahankan dan menggunakan sesuatu seperti itu.

Java juga memiliki file POM (XML) yang berisi dependensi paket dan informasi lain tentang paket tersebut. Mereka diunggah secara terpisah dari JAR yang dikompilasi.

Setiap manajer paket yang lebih baru memiliki beberapa file meta terpisah (npm/benang, komposer, gradle/maven, kargo, permata ruby/bundler, ...).

masalah terkait:
https://github.com/pypa/warehouse/issues/474

Anda bisa mendapatkan informasi ketergantungan dari PyPi tanpa mengunduh seluruh bundel (lihat PEP 566, yang menggantikan PEP 426).

package_name = 'Django'
PYPI_API_URL = 'https://pypi.python.org/pypi/{package_name}/json'
package_details_url = PYPI_API_URL.format(package_name=package_name)
response = requests.get(package_details_url)
data = json.loads(response.content)
data['info'].get('requires_dist')
data['info'].get('requires')
data['info'].get('setup_requires')
data['info'].get('test_requires')
data['info'].get('install_requires')

@techalchemy apakah Anda melihat komentar di atas?

Ini cukup konsisten terjadi, pada dasarnya pipenv pergi berkeliling kota sambil "mengunci" sesuatu: mengapa masalah ini ditutup?

Pahami --skip-lock adalah cara yang harus dilakukan, tetapi tidak jelas sama sekali mengapa "menginstal" membutuhkan waktu beberapa detik, dan "mengunci" membutuhkan waktu lama: akan lebih bagus jika setidaknya perintah kunci akan mengeluarkan beberapa kemajuan / perbarui log: seperti yang terjadi, bahkan tidak jelas apakah itu macet di semacam while True selamanya...

Setidaknya saya ingin tahu apakah saya melakukan sesuatu yang salah, atau hanya "fitur" pipenv.

Dalam proyek kami pipenv lock sangat lambat. Itu pasti memengaruhi penggunaan normal kami. Menambahkan paket baru menjadi hal yang sangat menyakitkan bagi kami sekarang. Apakah ada cara kita bisa men-debug perilaku ini?

Saya mencoba menginstal PyTorch dan butuh 20 menit untuk mengunci dan kemudian menarik kesalahan berikut

Installing initially failed dependencies…
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 1992, in do_install
[pipenv.exceptions.InstallError]:       skip_lock=skip_lock,
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 1253, in do_init
[pipenv.exceptions.InstallError]:       pypi_mirror=pypi_mirror,
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 859, in do_install_dependencies
[pipenv.exceptions.InstallError]:       retry_list, procs, failed_deps_queue, requirements_dir, **install_kwargs
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 763, in batch_install
[pipenv.exceptions.InstallError]:       _cleanup_procs(procs, not blocking, failed_deps_queue, retry=retry)
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 681, in _cleanup_procs
[pipenv.exceptions.InstallError]:       raise exceptions.InstallError(c.dep.name, extra=err_lines)
[pipenv.exceptions.InstallError]: ['Collecting pytorch==1.0.2 (from -r /tmp/pipenv-pb00kf8t-requirements/pipenv-vae35p2d-requirement.txt (line 1))', '  Using cached https://files.pythonhosted.org/packages/ee/67/f403d4ae6e9cd74b546ee88cccdb29b8415a9c1b3d80aebeb20c9ea91d96/pytorch-1.0.2.tar.gz', 'Building wheels for collected packages: pytorch', '  Building wheel for pytorch (setup.py): started', "  Building wheel for pytorch (setup.py): finished with status 'error'", '  Running setup.py clean for pytorch', 'Failed to build pytorch', 'Installing collected packages: pytorch', '  Running setup.py install for pytorch: started', "    Running setup.py install for pytorch: finished with status 'error'"]
[pipenv.exceptions.InstallError]: ['ERROR: Complete output from command /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/bin/python3 -u -c \'import setuptools, tokenize;__file__=\'"\'"\'/tmp/pip-install-hix3yz6v/pytorch/setup.py\'"\'"\';f=getattr(tokenize, \'"\'"\'open\'"\'"\', open)(__file__);code=f.read().replace(\'"\'"\'\\r\\n\'"\'"\', \'"\'"\'\\n\'"\'"\');f.close();exec(compile(code, __file__, \'"\'"\'exec\'"\'"\'))\' bdist_wheel -d /tmp/pip-wheel-f_h8w1pz --python-tag cp36:', '  ERROR: Traceback (most recent call last):', '    File "<string>", line 1, in <module>', '    File "/tmp/pip-install-hix3yz6v/pytorch/setup.py", line 15, in <module>', '      raise Exception(message)', '  Exception: You tried to install "pytorch". The package named for PyTorch is "torch"', '  ----------------------------------------', '  ERROR: Failed building wheel for pytorch', '    ERROR: Complete output from command /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/bin/python3 -u -c \'import setuptools, tokenize;__file__=\'"\'"\'/tmp/pip-install-hix3yz6v/pytorch/setup.py\'"\'"\';f=getattr(tokenize, \'"\'"\'open\'"\'"\', open)(__file__);code=f.read().replace(\'"\'"\'\\r\\n\'"\'"\', \'"\'"\'\\n\'"\'"\');f.close();exec(compile(code, __file__, \'"\'"\'exec\'"\'"\'))\' install --record /tmp/pip-record-xr7o93_5/install-record.txt --single-version-externally-managed --compile --install-headers /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/include/site/python3.6/pytorch:', '    ERROR: Traceback (most recent call last):', '      File "<string>", line 1, in <module>', '      File "/tmp/pip-install-hix3yz6v/pytorch/setup.py", line 11, in <module>', '        raise Exception(message)', '    Exception: You tried to install "pytorch". The package named for PyTorch is "torch"', '    ----------------------------------------', 'ERROR: Command "/home/alex/.local/share/virtualenvs/pytorch-umelu-tG/bin/python3 -u -c \'import setuptools, tokenize;__file__=\'"\'"\'/tmp/pip-install-hix3yz6v/pytorch/setup.py\'"\'"\';f=getattr(tokenize, \'"\'"\'open\'"\'"\', open)(__file__);code=f.read().replace(\'"\'"\'\\r\\n\'"\'"\', \'"\'"\'\\n\'"\'"\');f.close();exec(compile(code, __file__, \'"\'"\'exec\'"\'"\'))\' install --record /tmp/pip-record-xr7o93_5/install-record.txt --single-version-externally-managed --compile --install-headers /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/include/site/python3.6/pytorch" failed with error code 1 in /tmp/pip-install-hix3yz6v/pytorch/']
ERROR: ERROR: Package installation failed...

Kesalahannya belum dibaca, tidak tahu apa yang salah. Menginstal dengan pip di lingkungan berfungsi dengan baik! Ini benar-benar penghenti pertunjukan. Kembali ke requirements.txt...

Ini adalah solusi yang saya gunakan untuk saat ini:

export PIPENV_SKIP_LOCK=true

Maka pipenv install foo tidak akan mengunci dan Anda dapat mengunci secara manual ketika Anda punya waktu dengan menjalankan pipenv lock .

@awhillas Cukup yakin baris terakhir mengatakan semua yang Anda butuhkan:

Anda mencoba menginstal "pytorch". Paket bernama untuk PyTorch adalah "obor"

Mengunci dependensi itu penting jadi saya tidak berpikir "lewati kunci" adalah solusi yang bertahan lama. Pada saat yang sama, saya hanya tidak membeli bahwa "mengunci dependensi" (apa pun yang mungkin diperlukan di bawah tenda) dioptimalkan secara maksimal seperti sekarang dan secara fungsional membutuhkan banyak menit atau jam untuk menyelesaikannya. Memang, kunci pipenv saya berjalan selama beberapa menit pada Pipfile yang memiliki 5 dependensi yang menggelikan sebelum gagal — tumpukan terpasang di bagian bawah — dan selama waktu itu hanya menggunakan 10-15% dari CPU yang tersedia dan sedikit memori.

Bisakah kita setidaknya melakukan beberapa upaya kelompok untuk membuat profil dan menentukan hambatan? Saya merasa hanya ada beberapa buah gantung rendah konyol di sana yang menunggu untuk membawa proses ini ke runtime yang masuk akal.

pipenv version 2018.11.26

Untuk Pipfile:

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]

[dev-packages]
keras = "*"
tensorflow = "~=1.13"
setuptools = "*"
wheel = "*"
twine = "*"

[requires]
python_version = ">=3.6"

Pipfile.lock (63b275) out of date, updating to (5e165c)…
Locking [dev-packages] dependencies…
Traceback (most recent call last):
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 109, in expect_loop
    return self.timeout()
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 82, in timeout
    raise TIMEOUT(msg)
pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x105a17210>
searcher: searcher_re:
    0: re.compile('\n')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/bin/pipenv", line 11, in <module>
    load_entry_point('pipenv==2018.11.26', 'console_scripts', 'pipenv')()
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/decorators.py", line 64, in new_func
    return ctx.invoke(f, obj, *args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/cli/command.py", line 254, in install
    editable_packages=state.installstate.editables,
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/core.py", line 1992, in do_install
    skip_lock=skip_lock,
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/core.py", line 1221, in do_init
    pypi_mirror=pypi_mirror,
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/core.py", line 1068, in do_lock
    lockfile=lockfile
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/utils.py", line 649, in venv_resolve_deps
    c = resolve(cmd, sp)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/utils.py", line 517, in resolve
    result = c.expect(u"\n", timeout=environments.PIPENV_INSTALL_TIMEOUT)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/delegator.py", line 215, in expect
    self.subprocess.expect(pattern=pattern, timeout=timeout)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/spawnbase.py", line 341, in expect
    timeout, searchwindowsize, async_)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/spawnbase.py", line 369, in expect_list
    return exp.expect_loop(timeout)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 119, in expect_loop
    return self.timeout(e)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 82, in timeout
    raise TIMEOUT(msg)
pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x105a17210>
searcher: searcher_re:
    0: re.compile('\n')

Sebagai tambahan untuk komentar sebelumnya, menjalankan pip lock secara terpisah membutuhkan waktu yang cukup lama, ~15 detik, setelah pertama kali dijalankan pip install --skip-lock . Jadi mungkin pemanggilan kunci pasca pemasangan sudah kedaluwarsa atau rusak. :)

FYI saya menemukan tensorflow adalah penyebab kunci lambat/waktu habis, jika itu membantu profil pipenv! (Masih menganggap ini sebagai masalah pipenv ...)

Tensorflow adalah salah satu dari banyak paket yang dapat menyebabkan pipenv pada dasarnya menjadi alat yang tidak berguna. Saya suka saran pembuatan profil grup. Saya pikir itu ide yang bagus untuk mulai mengatasi masalah ini. Hanya untuk mengulangi, PEP 566 mengaktifkan ketergantungan penghitungan (melalui pypi) tanpa memuat seluruh sumber, yang mungkin membantu: https://github.com/pypa/pipenv/issues/1914#issuecomment -457965038

@brandonrobertz dari apa yang saya lihat, mengunduh semua paket dependensi adalah tempat di mana sebagian besar waktu dihabiskan. Ini juga sudah dikonfirmasi sebelumnya.

Cara memverifikasi ini:

• Coba buat Pipfile dan instal scipy (misalnya) di dalamnya dengan penguncian diaktifkan
• Tunggu hingga penguncian selesai. (Memakan waktu sekitar 5 menit di mesin saya)
• hapus Pipfile.lock
• jalankan pipenv lock - penguncian sekarang akan memakan waktu yang sangat sedikit (6 detik pada mesin saya), karena semua paket sudah diunduh dan disimpan dalam cache Pipenv yang biasanya di ~/.cache/pipenv

Inilah Dockerfile yang saya gunakan untuk menguji ini:

FROM python:3.6
ENV WORKDIR=/work/
WORKDIR /work/
RUN python3 -m pip install --upgrade pip
RUN python3 -m pip install pipenv
RUN PIPENV_SKIP_LOCK=true pipenv install scipy
RUN date
RUN pipenv lock
RUN date
RUN rm Pipfile.lock
RUN pipenv lock
RUN date

@shtratos Ya, itu masuk akal dan yang lain menyarankan itu di utas masalah ini. Mengunduh dan menguraikan dependensi itu mahal. Beberapa dari langkah-langkah itu sepertinya dapat dihilangkan dengan menarik dari API ketergantungan pypi.

Untuk beberapa perpustakaan ini mungkin tidak akan berfungsi, karena kualitas yang buruk dan praktik yang buruk (tidak menggunakan setup.py atau requirements.txt). Tetapi karena beberapa pelanggar utama tampaknya merupakan perpustakaan yang sangat populer (tensorflow, numpy), menerapkan ini dengan mundur ke proses yang sangat lambat mungkin merupakan jalan yang baik ke depan.

Bisakah Anda mengarahkan saya ke arah di mana menemukan kode itu? Saya bisa mencoba memparalelkannya dengan garpu.

Saya pikir https://github.com/pandas-dev/pandas/ mungkin menjadi masalah? Ini adalah poin yang sama dengan waktu bagi saya juga.

Meskipun pytest mungkin juga menjadi masalah :\

Saya rasa tidak, ini berfungsi dengan baik di mesin saya, masalahnya tampaknya lebih umum dari itu

Dalam kasus saya masalahnya tampaknya pylint. Itu selalu macet saat mengunci saat menjalankan pipenv install pylint lihat https://github.com/pypa/pipenv/issues/2284#issuecomment -569457752

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

Contoh kerja minimal

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...

Kami sadar dan memiliki banyak masalah dalam melacak topik ini. Lihat #1785 #1886 #1891 dan PR #1896

npm dan yarn memiliki keuntungan karena tidak harus sepenuhnya mengunduh dan mengeksekusi setiap paket prospektif untuk menentukan grafik dependensinya karena dependensi ditentukan dalam plaintext. Ketergantungan Python mengharuskan kita untuk sepenuhnya mengunduh dan menjalankan file pengaturan dari setiap paket untuk diselesaikan dan dihitung. Itu hanya kenyataannya, itu agak lambat. Jika Anda tidak bisa menunggu 2 menit atau Anda merasa itu tidak sepadan dengan pengorbanannya, Anda selalu dapat melewati --skip-lock .

Penutupan untuk melacak dalam masalah lain.

3 dari 4 masalah lainnya sekarang telah ditutup dan satu lagi belum melihat aktivitas apa pun sejak 2018. Masalah ini masih berlanjut, jadi mungkin membuka kembali itu akan menjadi ide yang bagus?

Ketergantungan Python mengharuskan kita untuk sepenuhnya mengunduh dan menjalankan file pengaturan dari setiap paket untuk diselesaikan dan dihitung

Saya tidak berpikir itu masih berlaku untuk roda, yang seharusnya menjadi mayoritas paket sekarang?

Saya tahu saya setidaknya harus membangun roda untuk dlib setiap saat, yang menghebohkan.

Proses penyelesaian dependensi harus di-cache di suatu tempat berdasarkan versi per-paket, bahkan jika itu memerlukan pencarian jarak jauh lain pada klien setiap kali untuk mendapatkan pohon (seharusnya tidak, Anda bisa juga menyimpannya secara lokal juga setelah fakta ). Misalnya, paket repo dapat dengan mudah menyimpan pohon dep yang diselesaikan. Hit jaringan tambahan untuk dep tree yang diselesaikan dalam cache akan selalu lebih cepat daripada mengunduh seluruh paket dan komputasi.

FWIW Saya telah menghapus pipenv dari semua proyek saya (ini menjadi satu alasan utama, ada yang lain).

virtualenv + pip (dengan requirements.txt ) sekarang bekerja dengan cukup baik, bahkan untuk penerapan Prod; dan dalam hal apa pun, seseorang menyebarkan wadah yang sepenuhnya terbentuk akhir-akhir ini; setelah benar-benar masuk ke pipenv, saya tidak lagi mengerti maksudnya.

Silakan buka kembali masalah ini.
Jika tidak, pipenv tidak akan pernah menjadi alat pengemasan referensi