Pipenv: Dependensi tidak dapat diselesaikan. Regresi?

Sepertinya pipenv menambahkan pin ketat ke kandidat putaran saat ini.

Artinya, jika di babak berikutnya, paket lain membutuhkan versi yang tidak sesuai dengan kandidat saat ini, ia akan gagal (seperti ini) daripada mencoba mencari kandidat lain. Begitulah cara algoritma penyelesaian bekerja: Komputasi ulang penuh dengan batasan baru sampai stabil.

Saya tidak yakin apa yang menyebabkan ini.
Saya perhatikan bahwa untuk mereproduksi ini, saya harus menghapus cache ( --clear ) jika saya menggunakan pip-tools saja sebelumnya.
Saya dapat mengatakan ini bukan bug pip-tools , dan tidak terkait langsung dengan patch pip-tools (Saya menghapus semuanya untuk mencoba, dan ini masih terjadi).
Saya harap ini membantu.

Baiklah, temukan pelakunya:
https://github.com/kennethreitz/pipenv/blob/master/pipenv/patched/pip/req/req_set.py#L752

self.requirements.values() berisi req_to_install itu sendiri, disematkan, yang salah dikembalikan sebagai ketergantungan, dan dapat membuat resolusi ketergantungan gagal, seperti di sini, jika paket berikutnya memerlukan versi yang tidak sesuai dengan kandidat saat ini. Melakukan hal ini mengasumsikan bahwa calon pertama kita pasti orang yang benar, atau gagal ..

@kennethreitz Dari apa yang saya pahami, itu adalah melakukan "penyelesaian ekstra mendalam". Saya tidak yakin saya mengerti apa sebenarnya maksudnya itu. Saya siap untuk terus membahas ini, tetapi saya memerlukan beberapa info agar tidak salah arah.

Saya yakin saya melihat masalah yang sama:

$ pipenv --version
pipenv, version 8.2.7

$ pipenv install
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches django==2.0a1,>=1.8,>=1.8.0
Tried: 1.1.3, 1.1.4, 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6, 1.2.7, 1.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.4, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7, 1.4.8, 1.4.9, 1.4.10, 1.4.11, 1.4.12, 1.4.13, 1.4.14, 1.4.15, 1.4.16, 1.4.17, 1.4.18, 1.4.19, 1.4.20, 1.4.21, 1.4.22, 1.5, 1.5.1, 1.5.2, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.8, 1.5.9, 1.5.10, 1.5.11, 1.5.12, 1.5.12, 1.6, 1.6, 1.6.1, 1.6.1, 1.6.2, 1.6.2, 1.6.3, 1.6.3, 1.6.4, 1.6.4, 1.6.5, 1.6.5, 1.6.6, 1.6.6, 1.6.7, 1.6.7, 1.6.8, 1.6.8, 1.6.9, 1.6.9, 1.6.10, 1.6.10, 1.6.11, 1.6.11, 1.7, 1.7, 1.7.1, 1.7.1, 1.7.2, 1.7.2, 1.7.3, 1.7.3, 1.7.4, 1.7.4, 1.7.5, 1.7.5, 1.7.6, 1.7.6, 1.7.7, 1.7.7, 1.7.8, 1.7.8, 1.7.9, 1.7.9, 1.7.10, 1.7.10, 1.7.11, 1.7.11, 1.8a1, 1.8b1, 1.8b2, 1.8rc1, 1.8, 1.8, 1.8.1, 1.8.1, 1.8.2, 1.8.2, 1.8.3, 1.8.3, 1.8.4, 1.8.4, 1.8.5, 1.8.5, 1.8.6, 1.8.6, 1.8.7, 1.8.7, 1.8.8, 1.8.8, 1.8.9, 1.8.9, 1.8.10, 1.8.10, 1.8.11, 1.8.11, 1.8.12, 1.8.12, 1.8.13, 1.8.13, 1.8.14, 1.8.14, 1.8.15, 1.8.15, 1.8.16, 1.8.16, 1.8.17, 1.8.17, 1.8.18, 1.8.18, 1.9a1, 1.9b1, 1.9rc1, 1.9rc2, 1.9, 1.9, 1.9.1, 1.9.1, 1.9.2, 1.9.2, 1.9.3, 1.9.3, 1.9.4, 1.9.4, 1.9.5, 1.9.5, 1.9.6, 1.9.6, 1.9.7, 1.9.7, 1.9.8, 1.9.8, 1.9.9, 1.9.9, 1.9.10, 1.9.10, 1.9.11, 1.9.11, 1.9.12, 1.9.12, 1.9.13, 1.9.13, 1.10a1, 1.10a1, 1.10b1, 1.10b1, 1.10rc1, 1.10rc1, 1.10, 1.10, 1.10.1, 1.10.1, 1.10.2, 1.10.2, 1.10.3, 1.10.3, 1.10.4, 1.10.4, 1.10.5, 1.10.5, 1.10.6, 1.10.6, 1.10.7, 1.10.7, 1.10.8, 1.10.8, 1.11a1, 1.11b1, 1.11rc1, 1.11rc1, 1.11, 1.11, 1.11.1, 1.11.1, 1.11.2, 1.11.2, 1.11.3, 1.11.3, 1.11.4, 1.11.4, 1.11.5, 1.11.5, 1.11.6, 1.11.6, 2.0a1

di mana 2.0a1 jelas merupakan salah satu opsi yang tersedia.

Saya tidak dapat menguji resolusi ketergantungan di versi lama pipenv karena https://github.com/kennethreitz/pipenv/issues/786. Menurut pendapat saya, perbaikan bug kritis harus diterapkan setidaknya pada beberapa versi utama terbaru.

Masalah yang sama - ini mengeluh tentang permintaan secara khusus.

Ini adalah bug yang saya yakini terkait dengan komentar @vphilippon . Namun saya tidak berpikir ini terkait dengan # 909.

Tepat, tidak terkait dengan # 909.
Seperti yang saya katakan, saya memerlukan masukan dari salah satu @maintainers untuk memahami apa sebenarnya arti "penyelesaian ekstra dalam" di sini. Saya sudah memperbaikinya, tetapi saya ingin tahu lebih banyak untuk tidak merusak apa pun terlebih dahulu.

Atau saya bisa melanjutkan dan membuka PR dengan memperbaikinya dan berdiskusi di sana. Saya akan melihat dengan waktu luang saya.

@vphilippon Karena ini bukan organisasi, melainkan repo pribadi untuk Kenneth, sayangnya kami tidak memiliki tag @ yang berguna untuk mendapatkan kita semua. Saya sarankan untuk ping @erinxocon dan saya sendiri.

Sayangnya, patch to pip di sini terkunci di suatu tempat di kepala Kenneth. Saya rasa saya tidak mengerti, atau punya waktu untuk melihat, apa yang terjadi di sini. Jika Anda menemukan waktu untuk mengumpulkan apa yang menurut Anda mungkin terjadi, saya dapat mencoba membantu memverifikasi asumsi. Sampai saat itu, ini adalah sesuatu yang harus kita lakukan dengan ringan sebelum membuat perubahan.

@nateprewitt Baiklah , saya akan menambahkan sebanyak yang saya bisa. Ambil kursi.

Apa yang salah?

Di https://github.com/kennethreitz/pipenv/issues/875#issuecomment -335570812, saya mencatat sumber kesalahan: kandidat terpilih dalam babak penyelesaian ditambahkan sebagai ketergantungan yang disematkan dari kandidat itu sendiri secara langsung, yang salah ( lebih lanjut tentang itu akan datang)

Di https://github.com/kennethreitz/pipenv/issues/875#issuecomment -336609268, saya menemukan sumber pin itu: self.requirements.values() yang ditambahkan ke nilai yang dikembalikan menyertakan pin ke paket saat ini . Dengan kata lain, _prepare_file harus mengembalikan dependensi dari sebuah paket (atau "Daftar InstallRequirements tambahan untuk juga diinstal"), tetapi sekarang termasuk dirinya sendiri, disematkan, sebagai dependensinya sendiri.

Untuk membantu mendemonstrasikan mengapa memiliki paket itu sendiri, yang disematkan, sebagai dependensinya sendiri, benar-benar salah, berikut ini cara kerja algoritma penyelesaian dependensi, singkatnya:

1. Dapatkan initial_constraints_set , daftar InstallRequirements (misal: requests>=2.18 ).
2. Tentukan additional_constraints dan candidate sebagai set kosong.
3. Pilih satu set candidate (misal: requests==2.18.4 ) yang menghormati penyatuan initial_constraints_set dan additional_constraints
4. Untuk setiap kandidat, dapatkan dan gabungkan kumpulan dependensi dari semua kandidat, sebagai additional_constraints (misal: certifi>=2017.4.17 )
5. Jika additional_constraints telah berubah, hapus candidate dan kembali ke 3.
6. Kembalikan kumpulan kandidat, selesai.

Sekarang, mari kita mereproduksi masalah Dengan mengingat hal di atas.

Untuk mereproduksi masalah, Anda memerlukan Pipfile (karena `django-cms 3.4.5 dengan dukungan Django 1.11 dirilis):

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

[packages]
django-cms = "==3.4.4"
django = "*"

Dan sekarang pipenv lock --verbose --clear :

Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project.
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…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1
Current constraints:
  django
  django-cms==3.4.4

Finding the best candidates:
  found candidate django==1.11.6 (constraint was <any>)
  found candidate django-cms==3.4.4 (constraint was ==3.4.4)

Finding secondary dependencies:
  django-cms==3.4.4 not in cache, need to check index
  django-cms==3.4.4         requires django-classy-tags>=0.7.2, django-cms==3.4.4, django-formtools>=1.0, django-sekizai>=0.7, django-treebeard>=4.0.1, Django<1.11,>=1.8, djangocms-admin-style>=1.0
  django==1.11.6 not in cache, need to check index
  django==1.11.6            requires django==1.11.6, pytz

New dependencies found in this round:
  adding [u'django', '<1.11,==1.11.6,>=1.8', '[]']
  adding [u'django-classy-tags', '>=0.7.2', '[]']
  adding [u'django-cms', '==3.4.4', '[]']
  adding [u'django-formtools', '>=1.0', '[]']
  adding [u'django-sekizai', '>=0.7', '[]']
  adding [u'django-treebeard', '>=4.0.1', '[]']
  adding [u'djangocms-admin-style', '>=1.0', '[]']
  adding [u'pytz', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 1: not stable

                          ROUND 2
Current constraints:
  django<1.11,==1.11.6,>=1.8
  django-classy-tags>=0.7.2
  django-cms==3.4.4
  django-formtools>=1.0
  django-sekizai>=0.7
  django-treebeard>=4.0.1
  djangocms-admin-style>=1.0
  pytz

Finding the best candidates:
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches django<1.11,==1.11.6,>=1.8
Tried: 1.1.3, 1.1.4, 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6, 1.2.7, 1.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.4, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7, 1.4.8, 1.4.9, 1.4.10, 1.4.11, 1.4.12, 1.4.13, 1.4.14, 1.4.15, 1.4.16, 1.4.17, 1.4.18, 1.4.19, 1.4.20, 1.4.21, 1.4.22, 1.5, 1.5.1, 1.5.2, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.8, 1.5.9, 1.5.10, 1.5.11, 1.5.12, 1.5.12, 1.6, 1.6, 1.6.1, 1.6.1, 1.6.2, 1.6.2, 1.6.3, 1.6.3, 1.6.4, 1.6.4, 1.6.5, 1.6.5, 1.6.6, 1.6.6, 1.6.7, 1.6.7, 1.6.8, 1.6.8, 1.6.9, 1.6.9, 1.6.10, 1.6.10, 1.6.11, 1.6.11, 1.7, 1.7, 1.7.1, 1.7.1, 1.7.2, 1.7.2, 1.7.3, 1.7.3, 1.7.4, 1.7.4, 1.7.5, 1.7.5, 1.7.6, 1.7.6, 1.7.7, 1.7.7, 1.7.8, 1.7.8, 1.7.9, 1.7.9, 1.7.10, 1.7.10, 1.7.11, 1.7.11, 1.8a1, 1.8b1, 1.8b2, 1.8rc1, 1.8, 1.8, 1.8.1, 1.8.1, 1.8.2, 1.8.2, 1.8.3, 1.8.3, 1.8.4, 1.8.4, 1.8.5, 1.8.5, 1.8.6, 1.8.6, 1.8.7, 1.8.7, 1.8.8, 1.8.8, 1.8.9, 1.8.9, 1.8.10, 1.8.10, 1.8.11, 1.8.11, 1.8.12, 1.8.12, 1.8.13, 1.8.13, 1.8.14, 1.8.14, 1.8.15, 1.8.15, 1.8.16, 1.8.16, 1.8.17, 1.8.17, 1.8.18, 1.8.18, 1.9a1, 1.9b1, 1.9rc1, 1.9rc2, 1.9, 1.9, 1.9.1, 1.9.1, 1.9.2, 1.9.2, 1.9.3, 1.9.3, 1.9.4, 1.9.4, 1.9.5, 1.9.5, 1.9.6, 1.9.6, 1.9.7, 1.9.7, 1.9.8, 1.9.8, 1.9.9, 1.9.9, 1.9.10, 1.9.10, 1.9.11, 1.9.11, 1.9.12, 1.9.12, 1.9.13, 1.9.13, 1.10a1, 1.10a1, 1.10b1, 1.10b1, 1.10rc1, 1.10rc1, 1.10, 1.10, 1.10.1, 1.10.1, 1.10.2, 1.10.2, 1.10.3, 1.10.3, 1.10.4, 1.10.4, 1.10.5, 1.10.5, 1.10.6, 1.10.6, 1.10.7, 1.10.7, 1.10.8, 1.10.8, 1.11a1, 1.11b1, 1.11rc1, 1.11rc1, 1.11, 1.11, 1.11.1, 1.11.1, 1.11.2, 1.11.2, 1.11.3, 1.11.3, 1.11.4, 1.11.4, 1.11.5, 1.11.5, 1.11.6, 1.11.6

• Dalam satu putaran penyelesaian, kami mendeteksi bahwa kami harus menginstal django==* dan django-cms==3.4.4 .
• Kami memilih kandidat: django==1.11.6 , django-cms==3.4.4 .
• Kami mendapatkan dependensi (saya akan fokus pada bagian penting):
  
  
  
  • django-cms==3.4.4 membutuhkan django<1.11,>=1.8
  
  
  • django membutuhkan django==1.11.6 (Ini tidak benar, django tidak membutuhkan dirinya sendiri! Tidak ada paket yang membutuhkan dirinya sendiri!)
  
  
• Kami menggabungkan penentu dependensi bersama:
  
  
  
  • Kami sekarang membutuhkan django <1.11,==1.11.6,>=1.8 (Anda dapat melihat kemana arahnya ...)
  
  
• Kendala telah berubah, kembali ke pemilihan kandidat.
• Cobalah untuk menemukan kandidat untuk django yaitu <1.11,==1.11.6,>=1.8 :
  
  
  
  • Could not find a version that matches django<1.11,==1.11.6,>=1.8 [...]
  
  

Apa yang seharusnya terjadi (seperti yang terjadi di pip-tools , dengan pip ditambal, dengan --rebuild untuk membersihkan cache):

• Dalam satu putaran penyelesaian, kami mendeteksi bahwa kami harus menginstal django==* dan django-cms==3.4.4 .
• Kami memilih kandidat: django==1.11.6 , django-cms==3.4.4 .
• Kami mendapatkan dependensi (saya akan fokus pada bagian penting):
  
  
  
  • django-cms==3.4.4 membutuhkan django<1.11,>=1.8
  
  
  • django membutuhkan pytz , tetapi bukan django==1.11.6
  
  
• Kami menggabungkan penentu dependensi bersama:
  
  
  
  • Kami sekarang membutuhkan django <1.11,>=1.8 (Jauh lebih baik ...)
  
  
• Kendala telah berubah, kembali ke pemilihan kandidat.
• Cobalah untuk menemukan kandidat untuk django yaitu <1.11,>=1.8 :
  
  
  
  • Memilih kandidat django , kemungkinan besar django==1.10.8
  
  
• Menghitung ketergantungan, terus berjalan dan menyelesaikan dengan senang hati.

Apa yang harus dilakukan dari sini?

Nah, menghapus self.requirements.values() dari pengembalian _prepare_file memperbaiki masalah ini, saya bisa mengkonfirmasinya. Sayangnya, saya belum tahu persis mengapa itu ditambahkan di sana.

Mungkin Kenneth ingin mengembalikan objek InstallRequirement untuk kandidat itu sendiri setelah melakukan beberapa operasi padanya untuk mendapatkan informasi yang berkaitan dengan "penyelesaian ekstra mendalam" (saya benar-benar akan melakukan peregangan di sini). Saya dapat mencoba untuk menambal tambalan untuk menyimpan objek InstallRequirement itu dalam nilai yang dikembalikan, tetapi melepaskannya terlebih dahulu. Aku cukup yakin bahwa itu tidak disengaja, dan bahkan jika itu, yang rusak.

Saya pikir itu saja. ☕️

@vphilippon , terima kasih banyak telah menjelaskan secara mendetail! Ini jelas menjelaskan segalanya bagi saya.

Menggali kembali log komit, ini telah ditambahkan di ae4591b2 dan seperti yang Anda katakan, cukup tidak jelas mengapa ini ditambahkan. Saya pikir langkah selanjutnya adalah mengumpulkan kasus uji yang gagal untuk ini, dan kasus uji yang berfungsi untuk menginstal "dependensi yang dalam". Tidak ada tiket yang mengangkat masalah ini dan pesan komit tidak membantu jadi kami hanya menebak-nebak saat ini.

Melihat kodenya, saya pikir ini mencoba menyelesaikan memiliki deklarasi seperti requests[security] yang mungkin memiliki ketergantungan certifi[some-extra] yang juga perlu diselesaikan. Setidaknya itulah satu-satunya hal yang dapat saya pikirkan. Saya bertaruh ada sesuatu di alam semesta Django yang melakukan ini, dan jika kita dapat menemukan contoh yang akan memungkinkan kita menulis tes.

Begitu! Jika ada yang ingin mengerjakan pengujian ini bersama-sama, memastikan yang pertama gagal dan "ketergantungan mendalam" berfungsi, kita dapat melihat cara menghapus deklarasi self.requirements.values() .

@nateprewitt Berikut adalah sesuatu yang menurut saya menggambarkan apa yang Anda maksud:
https://github.com/vphilippon/testdeepextra

Tapi, resolusi dalam "foo [a] tergantung pada bar [b]" tampaknya sudah oke di pip-tools , karena dapat diuji dengan repo itu.
Jadi tambalan itu mungkin tidak persis seperti itu, karena saya akan berasumsi ini untuk sesuatu yang awalnya tidak berfungsi di pip-tools . Kecuali untuk beberapa kasus tertentu, saya tidak dapat menguji di sini.

Bagaimanapun, kami masih dapat menguji perilaku penyelesaian ekstra pipenv dengan repo itu (yang saya tidak punya waktu untuk segera melakukannya), dengan dan tanpa tambalan itu, dan melihat apakah itu memiliki efek, dan / atau bandingkan dengan keluaran pip-tools . Setidaknya kita punya titik awal.

Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches sanic-plugins-framework==0.5.0.dev20171225,>=0.5.0.dev20171225
Tried: 0.2.0.dev20171102, 0.2.0.dev20171102, 0.3.0.dev20171102, 0.3.0.dev20171102, 0.3.1.dev20171102, 0.3.1.dev20171102, 0.3.2.dev20171102, 0.3.2.dev20171102, 0.3.3.dev20171102, 0.3.3.dev20171102, 0.4.0.dev20171103, 0.4.0.dev20171103, 0.4.1.dev20171103, 0.4.1.dev20171103, 0.4.2.dev20171106, 0.4.2.dev20171106, 0.4.4.dev20171107, 0.4.4.dev20171107, 0.4.5.dev20171113, 0.4.5.dev20171113, 0.5.0.dev20171225, 0.5.0.dev20171225, 0.5.2.dev20180201, 0.5.2.dev20180201

1. Saya mendapat kesalahan ini ketika versi paket sama dengan '*', tetapi ketika saya mengubahnya ke versi yang dikenal, seperti '== 0.1.2', itu bekerja dengan baik.
2. Sayangnya, ketika saya mengetik pipenv install sanic-plugins-framework==0.5.0.dev20171225 , saya mendapatkan kembali pesan kesalahan besar ini. Mungkin semua versi di atas tidak lebih besar dari '0.5.0.dev20171225'
3. Bagaimana saya harus melakukannya untuk menutupi ini

pipenv lock —pre —clear

Terima kasih @Jasonsey untuk membagikan sedikit Anda dan kepada @techalchemy atas jawaban Anda.
Saya memiliki masalah khusus dengan sanic-plugins-framework , dan menambahkan --pre (_Allow pre-release._ flag) membantu saya menginstal paket 🙌

Apakah ini pernah diperbaiki? Saya masih mendapatkan perilaku keliru yang sama.
https://github.com/pypa/pipfile/issues/114