Pipenv: Perintah `pipenv install XYZ` terkadang hang tanpa batas waktu di "Mengunci dependensi [paket]"

Dibuat pada 21 Mar 2018  ·  78Komentar  ·  Sumber: pypa/pipenv

Mirip dengan masalah ini:

Ringkasan

Saat menggunakan pipenv install XYZ , proses hang tanpa batas di "Mengunci dependensi [paket]".

Ini tidak terjadi setiap saat, dan mungkin terkait dengan paket mana yang sedang diinstal. Pagi ini terjadi setiap kali saya mencoba menginstal tensorflow. Tadi malam itu terjadi untuk numpy juga, tapi hari ini numpy baik-baik saja.

Respons yang digantung tampaknya berlangsung tanpa batas waktu (meskipun saya menghentikan proses secara manual setelah satu jam). Pipfile.lock tidak ditulis, tetapi Pipfile ditulis dan paket yang diharapkan diinstal dan terdaftar ketika saya menjalankan pipenv run pip freeze .

Saya dapat mereproduksi ini menggunakan berbagai permutasi dari:

  • (L)ubuntu 16.04 dan (X)ubuntu 17.10
  • pipenv --three dan pipenv --two
  • pipenv diinstal melalui python 2.7 dan pipenv diinstal melalui python 3.5
  • ...dan saya mengunduh sumber pipenv dan menginstalnya di lingkungan yang terisolasi untuk melihat apakah masalahnya khusus untuk pipenv versi 11.8.3. Saya mengalami perilaku yang sama di 11.9.0.

Saya juga dapat mereproduksinya hanya dengan menjalankan pipenv lock atau pipenv update jika saya memiliki tensorflow (atau paket apa pun yang saat ini membuat saya bermasalah) yang terdaftar di Pipfile saya.

$ python -m pipenv.help keluaran

Versi Pipenv: '11.8.3'

Lokasi Pipenv: '/home/mary/.local/lib/python2.7/site-packages/pipenv'

Lokasi Python: '/usr/bin/python'

Instalasi Python lainnya di PATH :

  • 2.7 : /usr/bin/python2.7
  • 2.7 : /usr/bin/python2.7
  • 3.5 : /usr/bin/python3.5m
  • 3.5 : /usr/bin/python3.5

  • 2.7.12 : /usr/bin/python

  • 2.7.12 : /usr/bin/python2
  • 3.5.2 : /usr/bin/python3

Informasi PEP 508:

{'implementation_name': 'cpython',
 'implementation_version': '0',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '4.13.0-37-generic',
 'platform_system': 'Linux',
 'platform_version': '#42~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28 UTC 2018',
 'python_full_version': '2.7.12',
 'python_version': '2.7',
 'sys_platform': 'linux2'}

Variabel lingkungan sistem:

  • MANDATORY_PATH
  • _LXSESSION_PID
  • XDG_GREETER_DATA_DIR
  • PROJECT_HOME
  • LC_CTYPE
  • PYTHONDONTWRITEBYTECODE
  • XDG_CURRENT_DESKTOP
  • XDG_SESSION_TYPE
  • LOGNAME
  • XDG_SEAT
  • PATH
  • XDG_VTNR
  • QT_PLATFORM_PLUGIN
  • PYTHONUNBUFFERED
  • VIRTUALENVWRAPPER_SCRIPT
  • ZSH
  • DISPLAY
  • SSH_AGENT_PID
  • LANG
  • TERM
  • SHELL
  • XDG_SESSION_PATH
  • XAUTHORITY
  • LANGUAGE
  • SHLVL
  • QT_LINUX_ACCESSIBILITY_ALWAYS_ON
  • QT_QPA_PLATFORMTHEME
  • SESSION_FOLDER
  • QT_ACCESSIBILITY
  • WINDOWID
  • LIBVIRT_DEFAULT_URI
  • HOME
  • XDG_SESSION_DESKTOP
  • SAL_USE_VCLPLUGIN
  • XDG_RUNTIME_DIR
  • WORKON_HOME
  • SSH_AUTH_SOCK
  • VTE_VERSION
  • GDMSESSION
  • VIRTUALENVWRAPPER_WORKON_CD
  • XDG_SEAT_PATH
  • PIP_PYTHON_PATH
  • XDG_SESSION_ID
  • DBUS_SESSION_BUS_ADDRESS
  • _
  • VIRTUALENVWRAPPER_HOOK_DIR
  • VIRTUALENVWRAPPER_PROJECT_FILENAME
  • DESKTOP_SESSION
  • LSCOLORS
  • XDG_CONFIG_DIRS
  • DEFAULTS_PATH
  • XDG_CONFIG_HOME
  • OLDPWD
  • LS_COLORS
  • GDM_LANG
  • XDG_DATA_DIRS
  • PWD
  • XDG_MENU_PREFIX
  • LESS
  • PAGER
  • USER

Variabel lingkungan spesifik Pipenv:

Variabel lingkungan khusus debug:

  • PATH : /home/mary/bin:/home/mary/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
  • SHELL : /usr/bin/zsh
  • LANG : en_US.UTF-8
  • PWD : /home/mary/Development/Projects/poor_mans_smart_camera

Isi Pipfile ('/home/mary/Development/Projects/poor_mans_smart_camera/Pipfile'):

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

[dev-packages]

[packages]
numpy = "*"
tensorflow = "*"

[requires]
python_version = "3.5"


Hasil yang diharapkan

Saya berharap langkah di mana Pipfile.lock dihasilkan akan memakan waktu paling lama satu menit.

Saya memiliki perangkat keras yang bagus dengan banyak memori bebas dan kekuatan pemrosesan, jadi saya rasa ini bukan kendala sumber daya. Kecepatan internet saya 60 Mbps, jadi saya ragu ini masalah jaringan saat meminta paket.

Hasil sebenarnya

verbose_output.txt

Meskipun tangkapan layar ini tidak menunjukkan keluaran verbose seperti file di atas, tangkapan layar ini secara visual menunjukkan apa yang saya alami.
image

Langkah-langkah untuk meniru
  1. Putar virtualenv baru menggunakan pipenv --three atau pipenv --two .
  2. Konfirmasikan bahwa semuanya berfungsi seperti yang diharapkan dengan paket yang Anda tahu dapat diinstal dengan baik seperti pipenv install pylint .
  3. Sekarang menyebabkannya hang dengan menginstal paket yang tidak berfungsi karena alasan apa pun seperti pipenv install tensorflow .

Pipfile

Komentar yang paling membantu

Apakah layak untuk menampilkan paket yang sedang dikunci? Saya pikir itu setidaknya akan membantu menghentikan orang berpikir bahwa Pipenv sedang menggantung.

Semua 78 komentar

Bukannya ini harus terjadi dalam hal apa pun, tetapi perangkat keras apa yang Anda gunakan untuk menjalankan ini?

@uranusjr Silakan temukan laporan informasi perangkat keras terlampir.
hardinfo_report.txt

Apakah ini terjadi secara konsisten? Coba pipenv lock —verbose —clear

@techalchemy , saya menjalankan pipenv lock --verbose --clear , dan hasilnya serupa:

> pipenv lock --verbose --clear
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1                           
Current constraints:

Finding the best candidates:

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

Locking [packages] dependencies…

Itu tetap tergantung di "Mengunci [paket] dependensi".

Adakah keberuntungan mereproduksi ini di mesin Anda? Dengan tensorflow khususnya, itu terjadi setiap saat bagi saya.


EDIT: Saya menguji ini di komputer teman. Dia menjalankan Ubuntu 17.10, dan dia tidak mengalami masalah. Kedua komputer berada di jaringan yang sama. Satu perbedaan antara komputernya dan komputer saya adalah dia hanya menginstal pipenv daripada pipenv dan virtualenvwrapper. Saya akan memutar mesin virtual untuk melihat apakah ini entah bagaimana terhubung ke virtualenvwrapper dan/atau variabel lingkungan yang telah saya atur yang dibagikan di keduanya (yaitu $WORKON_HOME).

Saat ini saya melihat masalah yang sama; keluaran pipenv lock --verbose --clear saya terlihat persis seperti @MarenstainBear . Saya menjalankan Ubuntu dan menggunakan pyenv untuk mengelola virtualenvs.

hardinfo_report.txt

Saya melihat Anda menginstal Pipenv terhadap sistem Python. Apakah Anda memiliki pyopenssl (atau sesuatu yang berhubungan dengan SSL, sejujurnya saya tidak ingat, itu bagian dari requests[security] ) diinstal ke lingkungan yang sama? Ini diketahui membuat operasi menjadi sangat lambat.

Saya telah menginstal requests[security] dan pyopenssl di dalam virtualenv hanya untuk memastikan, tetapi masih menggantung. Debugging lebih lanjut, saya telah menemukan bahwa itu hang di dalam venv_resolve_deps untuk kedua kalinya, khususnya di baris 376, c = delegator.run(cmd, block=True) .

Yang lebih aneh adalah jika saya menjalankan perintah itu secara langsung ( python resolver.py ), dari baris perintah, itu berjalan dengan sempurna.

Ya, sepertinya saya melakukannya, tetapi hanya untuk python 2 saya, bukan untuk python 3 (dan instance pipenv saya diinstal melalui pip versi python 2):

mary<strong i="6">@marvel</strong>:~$ /usr/bin/python2.7 -m pip freeze | grep -i ssl
pyOpenSSL==17.5.0
mary<strong i="7">@marvel</strong>:~$ /usr/bin/python3 -m pip freeze | grep -i ssl
mary<strong i="8">@marvel</strong>:~$ 

Saya akan pergi ke laptop saya yang lain dan ke beberapa lingkungan virtual di mana saya tidak dapat mereproduksi ini untuk melihat apakah mereka _not_ memiliki pyOpenSSL.

EDIT: Menghapus beberapa paragraf tentang masalah lain yang saya lihat. Itu adalah kesalahan saya - saya sebenarnya berada di subdirektori tetapi tidak menyadarinya karena tanpa konfigurasi zsh normal saya dinonaktifkan untuk tujuan pengujian, saya tidak lagi memiliki indikator visual di Prompt saya dari cwd saya. Seperti yang @uranusjr nyatakan dengan benar "tetapi Pipenv melakukan banyak deteksi lingkungan, dan diketahui bekerja dengan aneh di Shell yang tidak dikonfigurasi dengan benar."... Saya memang salah mengonfigurasi Shell saya untuk sementara waktu.


@uranusjr
EDIT 2: Saya menguji ini pada mesin virtual dengan pengaturan yang sangat mirip dengan mesin Host saya (termasuk menginstal pipenv terhadap lingkungan python 2.7.12 yang berisi modul pyOpenSSL), dan pada mesin itu semuanya berfungsi dengan baik seperti yang diharapkan. Itu membuat saya ragu bahwa pyOpenSSL adalah masalahnya di sini. (Saya memang mencatat bahwa versi pipenv lebih tinggi di mesin virtual saya, jadi saya pikir saya akan memutakhirkan pipenv secara lokal untuk melihat apakah itu membuat perbedaan.)

$ python -m keluaran pipenv.help (dari mesin virtual)

Versi Pipenv: '11.9.0'

Lokasi Pipenv: '/home/mary/.local/lib/python2.7/site-packages/pipenv'

Lokasi Python: '/usr/bin/python'

Instalasi Python lainnya di PATH :

  • 2.7 : /usr/bin/python2.7
  • 2.7 : /usr/bin/python2.7
  • 3.5 : /usr/bin/python3.5m
  • 3.5 : /usr/bin/python3.5

  • 2.7.12 : /usr/bin/python

  • 2.7.12 : /usr/bin/python2
  • 3.5.2 : /usr/bin/python3

Informasi PEP 508:

{'implementation_name': 'cpython',
 'implementation_version': '0',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '4.13.0-36-generic',
 'platform_system': 'Linux',
 'platform_version': '#40~16.04.1-Ubuntu SMP Fri Feb 16 23:25:58 UTC 2018',
 'python_full_version': '2.7.12',
 'python_version': '2.7',
 'sys_platform': 'linux2'}

Variabel lingkungan sistem:

  • XDG_GREETER_DATA_DIR
  • GNOME_DESKTOP_SESSION_ID
  • PYTHONDONTWRITEBYTECODE
  • LESSOPEN
  • XDG_SESSION_TYPE
  • QT_IM_MODULE
  • LOGNAME
  • USER
  • PROMPT_COMMAND
  • HOME
  • XDG_VTNR
  • PATH
  • PYTHONUNBUFFERED
  • DISPLAY
  • SSH_AGENT_PID
  • LANG
  • TERM
  • SHELL
  • XDG_SESSION_PATH
  • QT_STYLE_OVERRIDE
  • LANGUAGE
  • SESSION_MANAGER
  • SHLVL
  • QT_LINUX_ACCESSIBILITY_ALWAYS_ON
  • GTK_CSD
  • QT_ACCESSIBILITY
  • XMODIFIERS
  • GIO_LAUNCHED_DESKTOP_FILE_PID
  • XDG_SESSION_DESKTOP
  • GIO_LAUNCHED_DESKTOP_FILE
  • XDG_RUNTIME_DIR
  • SSH_AUTH_SOCK
  • VTE_VERSION
  • GDMSESSION
  • XDG_SEAT_PATH
  • LESSCLOSE
  • GSETTINGS_SCHEMA_DIR
  • XDG_CURRENT_DESKTOP
  • XDG_SESSION_ID
  • DBUS_SESSION_BUS_ADDRESS
  • _
  • XAUTHORITY
  • DESKTOP_SESSION
  • XDG_CONFIG_DIRS
  • GTK_MODULES
  • GDM_LANG
  • PANTHEON_TERMINAL_ID
  • XDG_DATA_DIRS
  • PWD
  • PIP_PYTHON_PATH
  • XDG_MENU_PREFIX
  • LS_COLORS
  • XDG_SEAT

Variabel lingkungan spesifik Pipenv:

Variabel lingkungan khusus debug:

  • PATH : /home/mary/bin:/home/mary/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
  • SHELL : /bin/bash
  • LANG : en_US.UTF-8
  • PWD : /home/mary

@MarenstainBear Di Python mana Anda menginstal Pipenv? Atau apakah Anda menginstal Pipenv di Python lain, atau di dalam virtualenv? (Bukan proyek Anda, tetapi Pipenv itu sendiri.)

Perilaku yang Anda sebutkan di bawah memang membuat penasaran, tetapi Pipenv melakukan banyak deteksi lingkungan, dan diketahui bekerja secara aneh di shell yang tidak dikonfigurasi dengan benar. Saya tidak akan membacanya terlalu dalam; itu mungkin tersedak sesuatu yang lain.

@roddds resolver.py mengambil ketergantungan yang ingin diselesaikan sebagai variabel lingkungan. Tanpa menyetel $PIPENV_PACKAGES sebelum menjalankannya, itu hanya akan menyelesaikan daftar kosong—secepat kilat sebagaimana mestinya karena tidak ada yang harus diselesaikan.

Coba setel PIPENV_PACKAGES terlebih dahulu (formatnya mirip dengan requirements.txt ) dan lihat apa yang terjadi.

+1 Saya melihat masalah yang sama saat mencoba menginstal numpy di MacOS. Terverifikasi Saya tidak melihat masalah ini saat menginstal boto3.

% uname -a
Darwin f45c898a1d21.ant.amazon.com 15.6.0 Darwin Kernel Version 15.6.0: Tue Jan  9 20:12:05 PST 2018; root:xnu-3248.73.5~1/RELEASE_X86_64 x86_64

@uranusjr inilah yang saya dapatkan ketika memeriksa PIPENV_PACKAGES dengan nilai yang sama yang ditetapkan di dalam venv_resolve_deps :

Keluaran pemecah masalah

 $ PIPENV_PACKAGES=='django -i https://pypi.python.org/simple\ngraphene -i https://pypi.python.org/simple\ngraphene-django -i https://pypi.python.org/ simple\npsycopg2 -i https://pypi.python.org/simple\npsycopg2-binary -i https://pypi.python.org/simple\nipython -i https://pypi.python.org/simple\ndjango -manifold==0.1.6 -i https://pypi.python.org/simple\nscipy -i https://pypi.python.org/simple\npython-dateutil -i https://pypi.python.org /simple\ndjango-extensions -i https://pypi.python.org/simple' python /home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv /resolver.py

 Traceback (panggilan terakhir terakhir):
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/packaging/requirements.py", baris 92, di __init__
 req = REQUIREMENT.parseString(requirement_string)
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", baris 1617, di parseString
 naikkan exc
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", baris 1607, di parseString
 loc, token = self._parse( instring, 0 )
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", baris 1379, di _parseNoCache
 loc,token = self.parseImpl( instring, preloc, doActions )
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", baris 3376, di parseImpl
 loc, exprtokens = e._parse( instring, loc, doActions )
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", baris 1379, di _parseNoCache
 loc,token = self.parseImpl( instring, preloc, doActions )
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", baris 3698, di parseImpl
 kembalikan self.expr._parse( instring, loc, doActions, callPreParse=False )
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", baris 1379, di _parseNoCache
 loc,token = self.parseImpl( instring, preloc, doActions )
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", baris 3359, di parseImpl
 loc, daftar hasil = self.exprs[0]._parse( instring, loc, doActions, callPreParse=False )
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", baris 1383, di _parseNoCache
 loc,token = self.parseImpl( instring, preloc, doActions )
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", baris 2670, di parseImpl
 naikkan ParseException(instring, loc, self.errmsg, self)
 pip9._vendor.pyparsing.ParseException: Diharapkan W:(abcd...) (pada char 0), (baris:1, col:1)

 Selama penanganan pengecualian di atas, pengecualian lain terjadi:

 Traceback (panggilan terakhir terakhir):
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", baris 82, di __init__
 req = Persyaratan (req)
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/packaging/requirements.py", baris 96, di __init__
 requirement_string[e.loc:e.loc + 8]))
 pip9._vendor.packaging.requirements.InvalidRequirement: Persyaratan tidak valid, parse error di "'=django'"

 Selama penanganan pengecualian di atas, pengecualian lain terjadi:

 Traceback (panggilan terakhir terakhir):
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/resolver.py", baris 83, di
 utama()
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/resolver.py", baris 71, di main
 jelas = lakukan_hapus,
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/resolver.py", baris 63, dalam penyelesaian
 verbose = bertele-tele,
 File "/home/rodrigo/.pyenv/versions/val/lib/python3.6/site-packages/pipenv/utils.py", baris 426, di resolve_deps
 pra,
 File "/home/rodrigo/.pyenv/versions/val/lib/python3.6/site-packages/pipenv/utils.py", baris 294, di sebenarnya_resolve_reps
 c untuk c di req.parse_requirements(t, session=pip_requests)
 File "/home/rodrigo/.pyenv/versions/val/lib/python3.6/site-packages/pipenv/utils.py", baris 294, di
 c untuk c di req.parse_requirements(t, session=pip_requests)
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_file.py", baris 93, di parse_requirements
 untuk req di req_iter:
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_file.py", baris 158, di process_line
 terisolasi=terisolasi, opsi=req_options, wheel_cache=wheel_cache
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", baris 235, di from_line
 wheel_cache=cache_roda, kendala=kendala)
 File "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", baris 91, di __init__
 "Persyaratan tidak valid: '%s'\n%s" % (permintaan, add_msg))
 pip9.exceptions.InstallationError: Persyaratan tidak valid: '= Django'
 = bukan operator yang valid. Apakah maksud Anda == ?

File Pip saya

 [[sumber]]
 url = "https://pypi.python.org/simple"
 verifikasi_ssl = benar
 nama = "pipi"

 [paket]
 django = "*"
 grafena = "*"
 graphene-django = "*"
 "psycopg2" = "*"
 "psycopg2-biner" = "*"
 ipython = "*"
 django-manifold = "==0.1.6"
 sip = "*"
 python-dateutil = "*"
 django-extensions = "*"

 [paket dev]

 [memerlukan]
 python_version = "3.6"

@roddds Anda memiliki = yang berlebihan di lingkungan. Dia

$ PIPENV_PACKAGES='django -i [too long, snipped]

Tapi kamu punya

$ PIPENV_PACKAGES=='django ...

= kedua digabungkan dengan django setelahnya, menghasilkan kesalahan sintaks yang Anda lihat.

Saya pikir saya melihat masalah yang sama pada instalasi baru Mac (macOS 10.12, Homebrew Python 3), dan menemukan beberapa masalah terkait di sini.

Ini adalah mesin yang gemuk, saya memiliki akses Internet yang baik – tidak yakin apa yang menyebabkannya begitu lama, tetapi pada akhirnya file kunci ditulis setelah sekitar tiga menit.

Sama disini. Setiap kali saya menjalankan pipenv install xxx dibutuhkan waktu yang sangat lama (2-3 menit) tepat setelah itu mencetak Locking [packages] dependencies…

Mengunci hanya membutuhkan waktu lama orang. Karena manajemen ketergantungan python, kita harus mengunduh setiap paket dan menjalankan setup.py untuk mendapatkan dependensi sesuai kebutuhan. Untuk perpustakaan seperti tensorflow dan numpy Anda mungkin berakhir dengan sdist yang berarti Anda sedang membangun dari sumber. Itu lambat. Saya telah melihatnya butuh 10 menit. Ini berjalan lebih cepat jika Anda memanaskan cache.

Saya akan menutup masalah ini untuk saat ini sampai seseorang benar-benar dapat menunjukkan kepada saya bahwa proses mereka macet atau tidak melakukan apa-apa. Kami sedang mempertimbangkan cara untuk meningkatkan proses ini

Apakah layak untuk menampilkan paket yang sedang dikunci? Saya pikir itu setidaknya akan membantu menghentikan orang berpikir bahwa Pipenv sedang menggantung.

Kami sedang mempertimbangkan cara untuk meningkatkan proses ini

Saya menyarankan untuk mencetak pesan yang memberi tahu pengguna bahwa $something sedang dilakukan, yang mungkin "memakan waktu beberapa menit". Saat ini sepertinya prosesnya macet, yang menurut saya membuat orang mengajukan laporan bug atau memberi +1 pada masalah (non-) ini.

@slhck Saya akan tertarik untuk mengetahui mengapa ini harus memakan waktu lama untuk memulai. Pekerjaan apa yang perlu dilakukan pipenv dalam periode itu?

@anowlcalljosh Saya suka saran ini, dan mungkin bertanya-tanya apa yang dikunci sendiri. Tidak yakin mengapa kami tidak pernah berpikir untuk mencetaknya.

@Victor-Savu seperti yang saya sebutkan. kompilasi sesuatu seperti numpy atau tensorflow.

@techalchemy Proses saya, sejauh yang saya tahu, sebenarnya menggantung. Aku sudah membiarkannya pergi selama lima jam sebelum membunuhnya. Melihat top , saya tidak melihat indikasi apa pun yang sebenarnya sedang diproses. Sebaliknya, ketika saya menginstal tensorflow di virtualenv saya dengan pip alih-alih pipenv, dibutuhkan hanya beberapa detik.

Seperti yang Anda lihat dalam tangkapan terminal saya ini, sistem saya membutuhkan 12,25 detik untuk memutar python3 virtualenv baru dan menggunakan pip untuk menginstal tensorflow menggunakan perintah /usr/bin/time -v pipenv run pip install tensorflow .

Jika saya malah menjalankan perintah /usr/bin/time -v pipenv install tensorflow , prosesnya tampaknya berhenti tanpa batas di "Mengunci [paket] dependensi..." setelah instalasi berhasil.

Anda dapat melihat dari gambar ini bahwa setelah sekitar 59 detik melakukan sesuatu secara aktif, subproses yang terkait dengan resolver.py berhenti secara aktif menggunakan sumber daya sistem dan, sejauh yang saya tahu, tidak akan pernah selesai. Saat saya mengambil screenshot ini, prosesnya sudah berjalan selama 16 menit.

image

@MarenstainBear Pipenv memunculkan subproses di dalam virtualenv untuk melakukan penguncian. Apakah Anda dapat memverifikasi apakah subproses (virtualenv python menjalankan pipenv/resolver.py berjalan ketika Pipenv macet? Saya ingin tahu apakah itu macet di dalam resolver, setelah resolver kembali, atau selama delegator.run

(bahkan lebih idealnya Anda dapat mencoba mencari tahu apakah resolver mencapai akhirnya)

@uranusjr Saya memasukkan beberapa pernyataan tulis ke dalam kode resolver.py, dan tampaknya tergantung di suatu tempat di panggilan pipenv.utils.resolve_deps di baris ini .

Dengan kata lain, resolver.py tampaknya tidak mencapai tujuannya.

@MarenstainBear Itu bagus(?) untuk didengar, setidaknya itu berarti dapat di-debug. Seberapa jauh ia berhasil masuk ke dalam resolve_deps ? Ini adalah fungsi yang cukup panjang…

Ya dan untuk berapa lama itu berjalan? Bagi saya itu masih terdengar seperti yang saya katakan sebelumnya — menyelesaikan grafik ketergantungan yang lambat

@techalchemy @uranusjr Saya akan menggali apa yang terjadi di fungsi resolve_deps akhir pekan ini. Sementara itu, inilah hasil dari proses yang saya mulai kemarin. Setelah 24 jam, itu tidak diselesaikan, dan itu benar-benar tidak menggunakan sumber daya sistem apa pun, jadi saya pikir itu tidak mencoba untuk menyelesaikan dependensi dan malah hanya menggantung. (Saya mematikan proses untuk melihat output dari perintah time .)

Perintah keluar dengan status bukan nol 1
Perintah diatur waktunya: "pipenv install tensorflow"
Waktu pengguna (detik): 13,63
Waktu sistem (detik): 1,99
Persentase CPU yang didapat pekerjaan ini: 0%
Waktu berlalu (jam dinding) (j:mm:dd atau m:dd): 25:45:02
Rata-rata ukuran teks bersama (kbytes): 0
Rata-rata ukuran data yang tidak dibagikan (kbyte): 0
Ukuran tumpukan rata-rata (kbyte): 0
Ukuran total rata-rata (kbyte): 0
Ukuran set penduduk maksimum (kbyte): 297772
Ukuran set penduduk rata-rata (kbyte): 0
Kesalahan halaman utama (memerlukan I/O): 0
Kesalahan halaman kecil (mengklaim kembali bingkai): 467309
Sakelar konteks sukarela: 15781
Sakelar konteks yang tidak disengaja: 207
Tukar: 0
Input sistem file: 0
Keluaran sistem file: 1654976
Pesan soket terkirim: 0
Pesan soket diterima: 0
Sinyal yang dikirim: 0
Ukuran halaman (byte): 4096
Status keluar: 1

@techalchemy apa artinya "memanaskan cache"?

@MarenstainBear terima kasih telah melakukan semua itu. Masalah Anda pasti bug. Orang lain di utas saya belum yakin. Bisakah Anda menginstal dari master dan melihat apakah kami telah memperbaikinya?

@techalchemy Saya menginstal dari master di commit 8a67a21d61a2383253fe0dd5e7a8d79d51d30d2d (tanggal Sabtu 31 Maret 01:13:26 2018 -0400). Masalah saya _not_ teratasi. Saya melihat perilaku yang sama di sini di versi 11.9.1 seperti yang saya lihat di 11.9.0.

Saya secara singkat mencoba cara berbeda untuk men-debug masalah ini menggunakan strace. Perintah strace pipenv install tensorflow tergantung pada poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}], 2, -1) . Ketika saya mencari deskriptor file itu, tidak ada banyak hal yang menarik selain konfirmasi bahwa sistem sedang menunggu I/O.

mary<strong i="10">@marvel</strong>:/proc/8471/fd
> lsof -n -P | grep 1428937     
pipenv     8474                  mary    5r     FIFO               0,12       0t0    1428937 pipe
sh         8543                  mary    1w     FIFO               0,12       0t0    1428937 pipe
python     8544                  mary    1w     FIFO               0,12       0t0    1428937 pipe

mary<strong i="11">@marvel</strong>:/proc/8471/fd
> lsof -n -P | grep 1428938
pipenv     8474                  mary    7r     FIFO               0,12       0t0    1428938 pipe
sh         8543                  mary    2w     FIFO               0,12       0t0    1428938 pipe
python     8544                  mary    2w     FIFO               0,12       0t0    1428938 pipe

Catatan tambahan - Akan sangat membantu jika kita entah bagaimana bisa mengalirkan output dari
resolver daripada memblokir sampai resolver kembali (hanya untuk membuatnya
lebih mudah menggunakan verbose untuk men-debug tempat hang terjadi)
Pada Minggu, 1 April 2018 pukul 17.21 MarenstainBear [email protected]
menulis:

Saya menginstal dari master di komit 8a67a21
https://github.com/pypa/pipenv/commit/8a67a21d61a2383253fe0dd5e7a8d79d51d30d2d
(tanggal Sab 31 Mar 01:13:26 2018 -0400). Masalah saya tidak terselesaikan. Saya
melihat perilaku yang sama di sini di versi 11.9.1 seperti yang saya lihat di 11.9.0.

Saya secara singkat mencoba cara berbeda untuk men-debug masalah ini menggunakan strace. Itu
perintah strace pipenv install tensorflow digantung di poll([{fd=5,
peristiwa=POLLIN}, {fd=7, peristiwa=POLLIN}], 2, -1). Ketika saya melihat itu
deskriptor file, tidak banyak yang menarik selain
konfirmasi bahwa sistem sedang menunggu I/O.

mary@marvel :/proc/8471/fd

lsof -n -P | grep 1428937
pipenv 8474 mary 5r FIFO 0,12 0t0 1428937 pipa
sh 8543 mary 1w FIFO 0,12 0t0 1428937 pipa
python 8544 mary 1w FIFO 0,12 0t0 1428937 pipa

mary@marvel :/proc/8471/fd

lsof -n -P | grep 1428938
pipenv 8474 mary 7r FIFO 0,12 0t0 1428938 pipa
sh 8543 mary 2w FIFO 0,12 0t0 1428938 pipa
python 8544 mary 2w FIFO 0,12 0t0 1428938 pipa


Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/pypa/pipenv/issues/1816#issuecomment-377828171 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/ABhjq95pb8cZ7BbzrjPxBq3SLeirzFehks5tkW8KgaJpZM4S0kt-
.

Saya mempunyai masalah yang sama. Itu digantung tanpa batas di masa lalu, tetapi terakhir kali berakhir dengan pengecualian karena suatu alasan. Mungkin ini akan membantu. (Versi adalah 11.9.0)

❯ pipenv install Pipfile.lock not found, creating… Locking [dev-packages] dependencies… Locking [packages] dependencies… y", line 63, in resolve verbose=verbose, File "/usr/local/lib/python3.6/site-packages/pipenv/utils.py", line 494, in resolve_deps list(resolver.resolve_hashes([result]).items())[0][1] File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/resolver.py", line 72, in resolve_hashes return {ireq: self.repository.get_hashes(ireq) for ireq in ireqs} File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/resolver.py", line 72, in <dictcomp> return {ireq: self.repository.get_hashes(ireq) for ireq in ireqs} File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 276, in get_hashes for candidate in matching_candidates File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 276, in <setcomp> for candidate in matching_candidates File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 282, in _get_file_hash for chunk in iter(lambda: fp.read(8096), b""): File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 282, in <lambda> for chunk in iter(lambda: fp.read(8096), b""): File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/requests/packages/urllib3/response.py", line 324, in read flush_decoder = True File "/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/contextlib.py", line 99, in __exit__ self.gen.throw(type, value, traceback) File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/requests/packages/urllib3/response.py", line 237, in _error_catcher raise ReadTimeoutError(self._pool, None, 'Read timed out.') pip9._vendor.requests.packages.urllib3.exceptions.ReadTimeoutError: HTTPSConnectionPool(host='pypi.python.org', port=443): Read timed out.

@MarenstainBear Terima kasih telah berusaha keras dalam men-debug masalah ini.

Setelah penginstalan paket tensorflow-gpu versi saat ini gagal berkali-kali dengan cara yang sama seperti yang dijelaskan, saya telah berhasil menyelesaikan penginstalannya dengan menyematkannya ke versi 1.5

pipenv install tensorflow-gpu==1.5

Meskipun tidak menjelaskan kegagalan penginstalan NumPy dan paket lainnya, ini mungkin ada hubungannya dengan fakta bahwa sejak versi 1.6, binari tensorflow menggunakan instruksi AVX. Bagaimanapun, versi 1.5 diinstal dengan sangat cepat dan berfungsi dengan baik.

@paraschas Saya mencoba tip Anda, dan sayangnya tidak berhasil. Terima kasih telah menyarankan sesuatu! :-)

@MarenstainBear ini bisa dengan mudah karena pipenv membocorkan deskriptor file di suatu tempat di sepanjang rantai dan kemudian menunggu mereka... Selama instalasi, kami biasanya melakukan banyak subproses untuk menangani unduhan bersamaan dan semacamnya. Apa yang terjadi jika Anda menggunakan pipenv install --sequential ? Terima kasih telah mendukung kami, jangan ragu untuk mampir ke saluran slack kami (tautannya adalah https://pyslackers.com/ => daftar dan bergabunglah #pipenv) jika Anda ingin melakukan lebih banyak hal secara real time

@techalchemy Dari apa yang saya tahu, ketika hang tidak pernah keluar dari blok coba ini:
@ techttps://github.com/pypa/pipenv/blob/8a67a21d61a2383253fe0dd5e7a8d79d51d30d2d/pipenv/utils.py#L491 -L494

Kode itu memanggil kembali ke resolver.py, jadi saya akan melihat apa yang terjadi di sana dalam metode resolve_hashes() .

PS - Saya memang bergabung dengan saluran slack. Terima kasih untuk undangan nya!

Saya menghadapi masalah yang sama di sini. Python 3.6.4, pipenv 11.9.0.
Itu tidak hang jika saya menginstal dengan --skip-lock .

@techalchemy @uranusjr

Saya dapat menggunakan ipdb untuk mempersempit masalah saya secara signifikan ...

Dari kode pypi.py asli di sini , jika saya menambahkan dua baris, seperti yang ditunjukkan di bawah ini, maka pipenv saya tidak lagi rusak .

  1. Baris pertama alt_session = PipSession() membuat objek PipSession vanilla
  2. Dan baris kedua self.session.adapters["https://"] = alt_session.adapters["https://"] mengambil adaptor https dari sesi vanilla itu dan menimpa adaptor https PyPIRepository. Ini berarti beralih dari menggunakan pip9._vendor.cachecontrol.adapter.CacheControlAdapter alih-alih menggunakan pip9._vendor.requests.adapters.HTTPAdapter .
def _get_file_hash(self, location):
    h = hashlib.new(FAVORITE_HASH)
    alt_session = PipSession()
    self.session.adapters["https://"] = alt_session.adapters["https://"]
    with open_local_or_remote_file(location, self.session) as fp:
        for chunk in iter(lambda: fp.read(8096), b""):
            h.update(chunk)
    return ":".join([FAVORITE_HASH, h.hexdigest()])

Adakah ide tentang mengapa ini berhasil untuk saya dan apa artinya ini tentang sumber bug saya?

Dugaan saya mungkin rusak karena mencoba mengambil terlalu banyak barang pada saat yang bersamaan. Beralih ke adaptor yang di-cache mengurangi permintaan yang dibutuhkan (karena di-cache) dan membuatnya berfungsi. Ini hampir sepenuhnya tebakan (saya tidak melihat ke dalam pip internal dan saya berbicara murni berdasarkan ingatan saya ke sumber pip). Namun, jika ini benar, ini akan menjadi perbaikan yang sangat bagus. Maukah Anda mengecilkan tambalan menjadi permintaan tarik?

@uranusjr Sebenarnya sebaliknya. Kode asli menggunakan adaptor yang di-cache--adaptor yang di-cache adalah yang TIDAK berfungsi untuk saya. Adaptor HTTP biasa berfungsi saat saya menggunakannya.

@uranusjr @techalchemy Sekarang saya memikirkannya, saya ingin tahu apakah ada semacam data yang rusak di cache saya. Saya akan melihat cara menghapus cache (pip?) saya untuk melihat apakah itu menyelesaikan masalah bagi saya.

Mungkin, saya tidak tahu (pip internal sangat sulit). cache pip berada di ~/.cache/pip secara default, tetapi mungkin ada cache lain. sejujurnya saya tidak tahu.

@uranusjr @techalchemy @jtratner

Ember suci, Batman! Itu berhasil!

mary<strong i="10">@marvel</strong>:~
> sudo rm ~/.cache/pip* -rf
[sudo] password for mary: 

mary<strong i="11">@marvel</strong>:~
> mktmpenv 
Using base prefix '/usr'
New python executable in /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/python3
Also creating executable in /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/python
Installing setuptools, pip, wheel...done.
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/predeactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/postdeactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/preactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/postactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/get_env_details
This is a temporary environment. It will be deleted when you run 'deactivate'.
(tmp-60224356c1829db) 
mary<strong i="12">@marvel</strong>:~/Development/.virtualenvs/tmp-60224356c1829db
> pipenv install protobuf
Creating a Pipfile for this project…
Installing protobuf…
Collecting protobuf
  Downloading protobuf-3.5.2.post1-cp35-cp35m-manylinux1_x86_64.whl (6.4MB)
Requirement already satisfied: setuptools in ./lib/python3.5/site-packages (from protobuf)
Collecting six>=1.9 (from protobuf)
  Downloading six-1.11.0-py2.py3-none-any.whl
Installing collected packages: six, protobuf
Successfully installed protobuf-3.5.2.post1 six-1.11.0

Adding protobuf to Pipfile's [packages]…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (735738)!
Installing dependencies from Pipfile.lock (735738)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 2/2 — 00:00:00
(tmp-60224356c1829db) 
mary<strong i="13">@marvel</strong>:~/Development/.virtualenvs/tmp-60224356c1829db
> 

Mari kita lihat apakah solusi ini berfungsi untuk beberapa orang lain yang melaporkan masalah yang sama.
@roddds @jlhood @roveo @claytonaalves Jika Anda masih dapat mereproduksi pipenv yang tergantung tanpa batas di "Kunci... [paket] dependensi", coba bersihkan cache pip (dan pipenv?) Anda di ~/.cache/.pip dan laporkan kembali apakah itu menyelesaikan masalah dengan pipenv hang. :-)

Jadi prompt Anda mengatakan @marvel tetapi Anda mengutip Robin…hmm

lol ... jadi membersihkan cache pip Anda memperbaikinya ... hidup itu lucu ...

Saya mengalami masalah yang sama dengan Python, pip, dan pipenv terbaru saat menginstal pendulum dan, sayangnya, membersihkan cache pip dan pipenv dengan menjalankan `Sudo rm ~/.cache/pip* -rf' tidak menyelesaikan masalah.

Jadi masalahnya, setidaknya bagi saya, masih berlanjut.

@paraschas dapatkah Anda memberi kami pipfile dan output dari python -m pipenv.help

Isi dari Pipfile adalah:

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

[packages]
pandas = "*"
"h5py" = "*"
Keras = "*"
tensorflow-gpu = "==1.5"
sklearn = "*"
pendulum = "*"

[dev-packages]

[requires] = "3.6"

Dan output dari python -m pipenv.help terlampir:

pipenv.help.txt

Setiap ide tentang cara melewati masalah, bahkan secara manual, akan sangat dihargai.

Bisakah Anda menjalankan pipenv-resolver —debug pendulum

Ini dia, tidak yakin mengapa gagal:

pipenv-resolver_pendulum.txt

Saat men-debug akan sangat membantu jika Anda tidak memotong perintah yang Anda jalankan juga karena saya juga tidak tahu mengapa ini gagal. Apakah lokal Anda dikonfigurasi dengan benar, dll?

Saya menyalin perintah yang sekarang saya lihat menyertakan tanda hubung alih-alih dua tanda hubung.

Saya sekarang telah menjalankan pipenv-resolver --debug pendulum yang berjalan dengan benar dan menghasilkan hasil berikut:
pipenv-resolver_pendulum.txt

Maaf tentang itu saya melakukan triase banyak hal di ponsel dan itu otomatis dikonversi menjadi tanda hubung. Jadi ini menunjukkan masalah instalasi. Versi apa yang muncul di lockfile Anda? Bisakah Anda pip install versi pendulum itu secara langsung?

Jangan khawatir, saya melihat Anda berusaha keras untuk proyek ini.

Saya berhasil menginstal pendulum dengan pipenv tetapi melewatkan pembuatan file kunci. Setelah sehari dan dengan boot baru, file kunci juga dibuat dengan benar, dan versi pendulum adalah "==1.5.1"

Hal buruknya adalah sejauh ini tidak ada cara untuk mereproduksi masalah ini, yang membuatnya sulit untuk diperbaiki, tetapi mudah-mudahan sesuatu akan muncul.

Rilis berikutnya akan sedikit membantu dalam hal ini. Harus memilikinya dalam beberapa jam.

Saya mengalami masalah yang sama ketika menginstal pandas. Karena saya menghadapi masalah dengan panda dan pip versi terbaru, jadi saya memutuskan untuk menurunkan versi pip ke 9.0.3 dan masalah dengan pipenv juga terpecahkan.
Periksa masalah ini untuk referensi Anda: https://github.com/pandas-dev/pandas/issues/20666

pipenv instal scrapy
hang lebih dari 10 menit

python --versi
3.6.5
pip --versi
10.0.1

kucing Pipfile

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

[packages]
scrapy = "*"

[dev-packages]

[requires]
python_version = "3.6"

Saya memiliki masalah yang sama. Di sinilah itu tergantung untuk saya:

$ pipenv lock -vv
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…
$ pipenv-resolver --debug requests
DEBUG:pip9.vcs:Registered VCS backend: git
DEBUG:pip9.vcs:Registered VCS backend: hg
DEBUG:pip9.vcs:Registered VCS backend: svn
DEBUG:pip9.vcs:Registered VCS backend: bzr
DEBUG:notpip.index:2 location(s) to search for versions of requests:
DEBUG:notpip.index:* https://pypi.python.org/simple/requests/
DEBUG:notpip.index:* https://pypi.boughtbymany.com/5c0a44cd-ec93-412c-b3a9-c3dfb72c22ee/requests/
DEBUG:notpip.index:Getting page https://pypi.python.org/simple/requests/
DEBUG:pip9._vendor.cachecontrol.controller:Looking up "https://pypi.python.org/simple/requests/" in the cache
DEBUG:pip9._vendor.cachecontrol.controller:Returning cached "301 Moved Permanently" response (ignoring date and etag information)
DEBUG:pip9._vendor.cachecontrol.controller:Looking up "https://pypi.org/simple/requests/" in the cache
WARNING:pip9._vendor.cachecontrol.controller:Cache entry deserialization failed, entry ignored
DEBUG:pip9._vendor.urllib3.connectionpool:Starting new HTTPS connection (1): pypi.org
DEBUG:pip9._vendor.urllib3.connectionpool:https://pypi.org:443 "GET /simple/requests/ HTTP/1.1" 200 16346
DEBUG:pip9._vendor.cachecontrol.controller:Updating cache with response from "https://pypi.org/simple/requests/"
DEBUG:pip9._vendor.cachecontrol.controller:Caching due to etag

Masalahnya ada hubungannya dengan pip yang mencoba menulis sesuatu ke cache-nya. Saya dapat menyelesaikannya dengan membersihkan cache pip saya - yang untuk pengguna Mac adalah rm -rf ~/Library/Caches/pip .

Terima kasih kepada semua kontributor untuk masalah ini!

Menghapus cache pip juga berhasil untuk saya! Terima kasih banyak kepada @MarenstainBear @uranusjr @techalchemy @jtratner untuk pekerjaan Anda!

Hal yang sama di sini, pip env tergantung di Mac OS. Saya telah mencoba membuat pipenv install flask sederhana pada folder baru hanya untuk kepentingan pengujian. Itu menggantung, tetapi saya perhatikan itu tidak menggunakan direktori cache pip, tetapi miliknya sendiri:

Building wheels for collected packages: itsdangerous, MarkupSafe
  Running setup.py bdist_wheel for itsdangerous: started
  Running setup.py bdist_wheel for itsdangerous: finished with status 'done'
  Stored in directory: /Users/renzo/Library/Caches/pipenv/wheels/2c/4a/61/5599631c1554768c6290b08c02c72d7317910374ca602ff1e5
  Running setup.py bdist_wheel for MarkupSafe: started
  Running setup.py bdist_wheel for MarkupSafe: finished with status 'done'
  Stored in directory: /Users/renzo/Library/Caches/pipenv/wheels/33/56/20/ebe49a5c612fffe1c5a632146b16596f9e64676768661e4e46

Jadi yang berhasil untuk saya adalah

rm -rf ~/Library/Caches/pipenv

Benar-benar perilaku yang aneh. Menemukan perilaku ini setelah memutakhirkan python dari 3.6.3 ke 3.7.0

pipenv --clear akan menangani ini untukmu

Kesalahan: tidak ada opsi seperti itu: --clear

Tingkatkan ke versi terbaru terlebih dahulu.

edit kecuali ini tidak dirilis dan hanya di master. Dalam hal ini tunggu sampai saya memotong rilis mungkin minggu ini, atau gunakan versi yang tersedia di master :D tidak ingat apakah ini benar-benar membuat cutoff...

@tekalkimia
Ini pasti belum dirilis karena saya memiliki versi terbaru 2018.7.1 dan saya juga tidak memiliki opsi --clear

Untuk masalah khusus ini, pipenv lock --clear sudah cukup.

pipenv lock --clear berfungsi. Terima kasih!

masih TIDAK bekerja untuk saya untuk pipenv lock --clear

macOS Sierra Tinggi 10.13.6
Python: Python 3.6.4
pipenv: versi 2018.7.1

Semoga memperbaiki ini Locking [packages] dependencies... hang selamanya ASAP

@crifan Saya telah menemukan bahwa ada bug yang menghentikan pipenv lock --clear agar tidak berfungsi (https://github.com/pypa/pipenv/issues/2628).

Coba hapus cache Anda secara manual - saya menggunakan rm -r ~/Library/Caches/pip* .

Terjadi di Dockerfile berbasis linux alpine ini (anak dari ini ):

FROM frolvlad/alpine-python3

RUN pip install pipenv

COPY ./app /app
COPY Pipfile /app/
WORKDIR /app

RUN pipenv install

Dengan Pipfile ini:

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

[dev-packages]

[packages]
numpy = "*"
pandas = "*"
tensorflow = "*"
flask = "*"

[requires]
python_version = "3.6"
~/devel/dopper:fixes: pipenv lock --clear --verbose
Locking [dev-packages] dependencies...
Locking [packages] dependencies...

hang selamanya.

File Pip:

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

[packages]
proto = {editable = true, path = "."}
halt = {editable = true, path = "/home/carlos/devel/halt"}
gcd = {editable = true, path = "/home/carlos/devel/gcd"}

[dev-packages]

[requires]
python_version = "3.6"

File kunci yang hanya berisi hal-hal yang ada di mesin lokal Anda sama tidak membantunya dengan tidak memberikan informasi apa pun. Kecuali Anda menawarkan informasi debug baru atau hal baru yang dapat kami ambil dan produksi ulang, harap berhati-hati dengan gangguan pelacak masalah.

Itu adalah proyek ketergantungan sederhana yang dapat dengan mudah saya instal secara manual dengan menjalankan pip install -e . pada masing-masing proyek, tetapi menjalankan pipenv install -e . pada proyek utama hang tanpa batas waktu, jadi saya menemukan masalah ini dan mencoba pipenv lock --clear yang juga hang. Saya mengerti tidak banyak yang dapat Anda lakukan tanpa informasi lebih lanjut, tetapi setidaknya ini adalah bukti bahwa hal-hal yang berjalan dengan lancar dengan cara lama tergantung dengan pipenv dan bahwa solusi yang diusulkan tidak berfungsi di mana-mana. Maaf saya tidak bisa memberikan informasi lebih lanjut. Mungkin jika mode --verbose memang bertele-tele di sini.

Mungkin ini bisa memberi pencerahan:

~/devel/dopper:fixes: pipenv --rm
Removing virtualenv (/home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s)...
~/devel/dopper:fixes: rm -rf Pipfile 
~/devel/dopper:fixes: pipenv --three
Creating a virtualenv for this project...
Pipfile: /home/carlos/devel/dopper/Pipfile
Using /usr/bin/python3 (3.6.6) to create virtualenv...
⠋Running virtualenv with interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s/bin/python3
Also creating executable in /home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s/bin/python
Installing setuptools, pip, wheel...done.
Setting project for dopper-0v9QQl0s to /home/carlos/devel/dopper

Virtualenv location: /home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s
Creating a Pipfile for this project...
~/devel/dopper:fixes: pipenv install numpy
Installing numpy...
Collecting numpy
  Using cached https://files.pythonhosted.org/packages/88/29/f4c845648ed23264e986cdc5fbab5f8eace1be5e62144ef69ccc7189461d/numpy-1.15.0-cp36-cp36m-manylinux1_x86_64.whl
Installing collected packages: numpy
Successfully installed numpy-1.15.0

Adding numpy to Pipfile's [packages]...
Pipfile.lock not found, creating...
Locking [dev-packages] dependencies...
Locking [packages] dependencies...

Menunggu selamanya...

Misalkan ini masalah jaringan, sekarang mengapa ini berhasil? :

~:: pip install --force --upgrade --user numpy
Collecting numpy
  Downloading https://files.pythonhosted.org/packages/88/29/f4c845648ed23264e986cdc5fbab5f8eace1be5e62144ef69ccc7189461d/numpy-1.15.0-cp36-cp36m-manylinux1_x86_64.whl (13.9MB)
    100% |████████████████████████████████| 13.9MB 386kB/s 
Installing collected packages: numpy
  Found existing installation: numpy 1.15.0
    Uninstalling numpy-1.15.0:
      Successfully uninstalled numpy-1.15.0
Successfully installed numpy-1.15.0

Setelah banyak upaya (menginstal dependensi satu per satu, menghindari dependensi lokal, menghindari dependensi yang dapat diedit, menginstal dengan skip lock lalu mengunci, dll) saya tidak dapat menemukan pola apa pun. Kadang-kadang berfungsi dalam jumlah waktu yang masuk akal, kadang-kadang dibatalkan setelah beberapa menit dengan kesalahan batas waktu, kadang-kadang hang "selamanya" (yang definisinya bergantung pada kesabaran saya yang berkurang). Saya menganggap masalah saya terkait dengan banyak masalah yang melaporkan beberapa varian "penguncian terlalu lambat".

Sekali lagi, tolong berhenti menebak-nebak secara acak dan memposting cuplikan acak dari hasil Anda. Jika Anda ingin bantuan dengan masalah tertentu, isi masalah dengan seluruh template masalah. Kami tidak akan mengejar siapa pun dalam masalah ini sementara mereka secara selektif memposting keluaran yang sebagian besar tidak terkait dengan pipenv. Kami telah melihat seperti apa tampilan layar saat hang. Menempelkan itu kepada kami tidak berguna.

Oke, jika menurut Anda gagal menginstal numpy di lingkungan yang bersih adalah
masalah acak Saya tahu saya mengambil risiko saat menggunakan pipenv, terima kasih untuk
kepala ke atas dan aku akan tutup mulut.

Pada Rabu, 25 Juli 2018 pukul 18:27, Dan Ryan [email protected] menulis:

Sekali lagi, tolong berhenti menebak-nebak secara acak dan memposting cuplikan acak dari
keluaran Anda. Jika Anda ingin bantuan dengan masalah tertentu, isi masalah
dengan seluruh template masalah. Kami tidak akan mengejar angsa liar dengan
siapa pun dalam masalah ini sementara mereka secara selektif memposting keluaran yang sebagian besar
tidak terkait dengan pipenv. Kami telah melihat seperti apa tampilan layar saat hang.
Menempelkan itu kepada kami tidak berguna.


Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/pypa/pipenv/issues/1816#issuecomment-407901419 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/ACtq-WfYHCgtRnbIu_yljQV7m0JvwxA7ks5uKOKqgaJpZM4S0kt-
.

@memeplex ini bukan tentang masalah acak, ini tentang output yang tidak membantu untuk pemecahan masalah. Saya tidak pernah menyebut masalah Anda secara acak -- saya memberi tahu Anda secara spesifik apa yang dapat Anda lakukan jika Anda tertarik untuk melakukan percakapan yang produktif tentang masalah yang Anda hadapi, karena tidak mungkin memecahkan masalah atau mendiagnosis sistem dengan fragmen terminal yang dipilih keluaran yang hanya menyertakan pesan yang kami tulis sendiri dan yang sebenarnya tidak menyertakan kesalahan apa pun atau cara apa pun bagi kami untuk mereproduksinya.

Sejauh ini kita tahu:

  1. Tidak ada tentang lingkungan Anda
  2. Tidak ada tentang keadaan tambahan apa pun di sekitar sistem Anda
  3. Klaim berlebihan bahwa Anda 'menunggu selamanya' tetapi tanpa info tambahan tentang apakah proses itu melakukan sesuatu, apakah ada lingkungan dengan apa pun di dalamnya, versi pipenv apa yang Anda jalankan, apakah ini terjadi dengan hal-hal selain numpy, bagaimana Anda menginstal python, seperti apa perangkat keras Anda, seperti apa konfigurasi sistem Anda, saya bisa melanjutkan.

Kami melakukan triase sejumlah besar masalah, itulah sebabnya kami menggunakan template masalah untuk membantu kami mengumpulkan informasi ini dengan cepat guna membantu menilai apa yang mungkin terjadi. Ketika orang hanya menempelkan '[mengunci]...' dan memberi tahu kami 'ini butuh selamanya', kami merasakannya untuk Anda, tetapi itu semacam indikasi awal bahwa Anda sebenarnya tidak di sini untuk menjadi produktif. Saya mencoba memberikan manfaat dari keraguan dan mendorong orang untuk mengajukan masalah dengan templat masalah dan kasus uji yang dapat direproduksi, tetapi jika Anda tidak dapat melakukannya, saya hanya dapat berasumsi bahwa niat Anda sebenarnya bukan untuk memecahkan masalah dan bahwa Anda hanya ingin menjadi negatif. Itu tidak benar-benar diterima di pelacak masalah, ada banyak tempat lain yang bisa Anda lakukan itu.

Pelacak ini digunakan untuk mengidentifikasi dan memecahkan masalah dengan basis kode, bukan untuk menumpuk kapan pun Anda melihat sesuatu yang Anda alami. Aturan dasarnya adalah bahwa jika Anda tidak dapat atau tidak mau berkontribusi apa pun selain menyatakan kembali sesuatu dan memberi tahu kami bahwa kami perlu memperbaikinya sebelum waktunya, Anda mungkin harus menahan diri untuk tidak memposting. Kami adalah sukarelawan dan kami melakukan ini di waktu luang kami; jika Anda datang ke pelacak, Anda langsung meminta kami untuk menghabiskan waktu kami untuk Anda. Kami biasanya dapat melakukan itu, tetapi kami meminta Anda untuk mengikuti proses kami untuk membantu kami melakukan triase secara efisien.

Saya benar-benar tidak ingin melanjutkan diskusi ini karena orang lain berlangganan utas, saya akan menjawab yang ini dan kemudian Anda memiliki perkataan terakhir jika Anda menginginkannya. Saya memposting beberapa bukti anekdot, saya segera menyadari itu tidak lebih dari itu dan mencoba untuk menghilangkan aspek yang paling bergantung dengan menginstal dependensi lokal dengan cara lain dan memeriksa tidak ada masalah dengan mereka dan akhirnya dengan menghapus setiap ketergantungan sama sekali, memulai env dari awal dan menginstal hanya numpy. Langkah-langkah itu (membuat env dan menginstal numpy) dapat direproduksi, saya dengan tulus minta maaf saya tidak dapat memberi Anda informasi yang lebih berguna karena saya sendiri tidak dapat menemukan pola apa pun, seperti yang saya katakan saat mendaftar upaya saya (dan saya juga tidak dapat lampirkan iso dari seluruh pengaturan saya). Jadi, pada akhirnya, saya menyarankan hubungan dengan sejumlah masalah, terlalu mirip, yang dilaporkan dan ditutup, dengan mengakui bahwa kesan pertama saya salah. Saya mengerti bahwa direproduksi lebih baik tetapi saya bahkan tidak dapat memposting keluaran verbose karena perintah hanya menunjukkan keluaran minimal yang saya (selektif atau acak atau apa pun) diposting. Pada awalnya saya pikir masalah saya dapat dikaitkan dengan masalah ini dan setelah upaya saya yang gagal untuk menemukan beberapa pola, saya sekarang merasa lebih cenderung untuk percaya bahwa itu ada di sisi "penguncian terlalu lambat". Alasan saya tidak membuat masalah baru adalah karena ada banyak dari mereka yang ditutup dengan alasan yang sama yang dengannya Anda pasti akan menutup masalah saya jika saya mempostingnya. Sekarang, saya pikir ini adalah masalah penting, saya tidak dapat secara konsisten menginstal paket populer di sebagian besar pengaturan standar, ini bukan tentang font emoji ular yang tidak berfungsi pada emulator terminal hipster baru saya dan, sementara saya memahami posisi Anda , Mau tak mau aku merasa bahwa kamu terlalu keras. Yang mengatakan saya sangat menghargai penjelasan terperinci Anda setelah komentar terakhir saya yang pemarah. Btw, klaim bahwa saya 'menunggu selamanya', selain sebagai kiasan, memang dilunakkan oleh saya, lidah di pipi, dengan mendefinisikan selamanya sebagai batas kesabaran saya, tetapi saya memberikan masukan bahwa itu di atas beberapa menit ; karena kita berbicara tentang sesuatu yang seharusnya memakan waktu paling lama beberapa detik di sini, satu-satunya relevansi ketidaktepatan saya adalah bahwa Anda menafsirkannya sebagai gejala awal niat buruk saya yang tidak ada di sana untuk memulai. Saya meminta maaf kepada semua orang di sini, setidaknya kepada semua orang dengan kesabaran untuk membaca hingga titik ini.

Jika Anda merasa memiliki sesuatu yang baru untuk ditambahkan pada topik ini, silakan buat edisi baru dan isi template masalah secara lengkap. Kami menyadari masalah dan berbagai manifestasinya, dan kami memiliki beberapa perbaikan dalam proses

Apakah halaman ini membantu?
0 / 5 - 0 peringkat