Pipenv: Tidak dapat membangun kunci meskipun ketergantungan ditemukan.

Dibuat pada 18 Okt 2017  ·  50Komentar  ·  Sumber: pypa/pipenv

Pastikan untuk memeriksa masalah yang ada, baik yang terbuka maupun yang tertutup.

Jelaskan masalahnya secara singkat di sini.

Jelaskan lingkungan Anda
  1. macOS Sierra
  2. Python 3.5.2
  3. pipenv, versi 8.2.7
Hasil yang diharapkan

Saya ingin menginstal shakedown dengan pipenv --three install dcos-shakedown . Ini harus membuat Pipfile dan kunci.

Hasil sebenarnya

Saya mendapatkan hasil sebagai berikut

CRITICAL:pip.index:Could not find a version that satisfies the requirement dcoscli==0.5.5 (from versions: 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6, 0.1.7, 0.1.8, 0.1.9, 0.1.10, 0.1.11, 0.1.12, 0.1.13, 0.1.14, 0.1.15, 0.2.0, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.4.0, 0.4.1, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6, 0.4.10, 0.4.11, 0.4.12, 0.4.13, 0.4.14)
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.
No matching distribution found for dcoscli==0.5.5

Ini aneh karena pipenv --three install dcoscli dapat menginstal 0.5.5 dan membuat kunci. Ada dcoscli-0.5.5 di PyPi. Saya berasumsi bahwa pipenv mencoba membuat penutupan untuk Python 2 juga tetapi tidak ada dcoscli 0.5.5 untuk Python 2.

Langkah-langkah untuk mereplikasi

Jalankan saja pipenv --three install --verbose dcos-shakedown dengan Python 3.5.

Discussion Possible Bug

Semua 50 komentar

Paket penggeledahan mungkin hanya Python 3. Namun, menurut saya pipenv harus membuat kunci hanya untuk versi Python tertentu jika Pipefile menyertakan versi Python yang diperlukan.

Berikut adalah keluaran verbose dari kunci tersebut

pipenv --three lock --verbose
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:
  dcos-shakedown from git+https://github.com/dcos/shakedown.git#egg=dcos-shakedown

Finding the best candidates:
  found candidate -e git+https://github.com/dcos/shakedown.git#egg=dcos-shakedown (constraint was <any>)

Finding secondary dependencies:

New dependencies found in this round:
  adding [u'click', '', '[]']
  adding [u'dcos-shakedown', '', '[]']
  adding [u'dcoscli', '==0.5.5', '[]']
  adding [u'paramiko', '', '[]']
  adding [u'pytest', '', '[]']
  adding [u'pytest-timeout', '', '[]']
  adding [u'retrying', '', '[]']
  adding [u'scp', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 1: not stable

                          ROUND 2
Current constraints:
  click
  dcos-shakedown from git+https://github.com/dcos/shakedown.git#egg=dcos-shakedown
  dcoscli==0.5.5
  paramiko
  pytest
  pytest-timeout
  retrying
  scp

Finding the best candidates:
  found candidate click==6.7 (constraint was <any>)
  found candidate -e git+https://github.com/dcos/shakedown.git#egg=dcos-shakedown (constraint was <any>)
  found candidate dcoscli==0.5.5 (constraint was ==0.5.5)
  found candidate paramiko==2.3.1 (constraint was <any>)
  found candidate pytest==3.2.3 (constraint was <any>)
  found candidate pytest-timeout==1.2.0 (constraint was <any>)
  found candidate retrying==1.3.3 (constraint was <any>)
  found candidate scp==0.10.2 (constraint was <any>)

Finding secondary dependencies:
  click==6.7                requires click==6.7
  scp==0.10.2 not in cache, need to check index
  scp==0.10.2               requires paramiko, scp==0.10.2
  pytest-timeout==1.2.0     requires pytest-timeout==1.2.0, pytest>=2.8.0
  dcoscli==0.5.5 not in cache, need to check index
CRITICAL:pip.index:Could not find a version that satisfies the requirement dcoscli==0.5.5 (from versions: 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6, 0.1.7, 0.1.8, 0.1.9, 0.1.10, 0.1.11, 0.1.12, 0.1.13, 0.1.14, 0.1.15, 0.2.0, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.4.0, 0.4.1, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6, 0.4.10, 0.4.11, 0.4.12, 0.4.13, 0.4.14)
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.
No matching distribution found for dcoscli==0.5.5

Ini aneh. Ketika saya menginstal dcsocli dengan pipenv --three install dcoscli saya mengerti

Installing dcoscli…
Collecting dcoscli
  Using cached dcoscli-0.5.5-py3-none-any.whl
````

followed by

                      ROUND 1

Kendala saat ini:
dcos-shakedown dari git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown
dcoscli.dll

Menemukan kandidat terbaik:
menemukan kandidat -e git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown (kendala adalah)
kandidat yang ditemukan dcoscli == 0.4.14 (kendala adalah)

Menemukan dependensi sekunder:
dcoscli == 0.4.14 membutuhkan dcos == 0.4.14, dcoscli == 0.4.14, docopt <1.0,> = 0.6, pkginfo == 1.2.1, toml <1.0,> = 0.9, virtualenv <16.0,> = 13.0
``

mengapa mencoba menginstal 0.4.14 dari dcoscli? Terutama ketika pipenv --three run dcos --version menghasilkan dcoscli.version=0.5.5 .

Ini bukan. Ini adalah proses penguncian. Itu melakukan resolusi ketergantungan berdasarkan apa yang diketahui dan apa yang telah Anda cache. Coba kunci pipenv —jelas

Pada 18 Okt 2017, pukul 6:16 pagi, Karsten Jeschkies [email protected] menulis:

Ini aneh. Ketika saya menginstal dcsocli dengan pipenv --tiga install dcoscli saya mengerti

Menginstal dcoscli…
Mengumpulkan dcoscli
Menggunakan cache dcoscli-0.5.5-py3-none-any.whl
diikuti oleh

                      ROUND 1

Kendala saat ini:
dcos-shakedown dari git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown
dcoscli.dll

Menemukan kandidat terbaik:
menemukan kandidat -e git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown (kendala adalah)
kandidat yang ditemukan dcoscli == 0.4.14 (kendala adalah)

Menemukan dependensi sekunder:
dcoscli == 0.4.14 membutuhkan dcos == 0.4.14, dcoscli == 0.4.14, docopt <1.0,> = 0.6, pkginfo == 1.2.1, toml <1.0,> = 0.9, virtualenv <16.0,> = 13.0
mengapa mencoba menginstal 0.4.14 dari dcoscli? Terutama ketika pipenv --tiga run dcos --version menghasilkan dcoscli.version = 0.5.5.

-
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub, atau nonaktifkan utasnya.

Anda harus memberikan hasil kunci pipenv —verbose dan pipenv —versi

Pada 18 Okt 2017, pukul 6:16 pagi, Karsten Jeschkies [email protected] menulis:

Ini aneh. Ketika saya menginstal dcsocli dengan pipenv --tiga install dcoscli saya mengerti

Menginstal dcoscli…
Mengumpulkan dcoscli
Menggunakan cache dcoscli-0.5.5-py3-none-any.whl
diikuti oleh

                      ROUND 1

Kendala saat ini:
dcos-shakedown dari git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown
dcoscli.dll

Menemukan kandidat terbaik:
menemukan kandidat -e git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown (kendala adalah)
kandidat yang ditemukan dcoscli == 0.4.14 (kendala adalah)

Menemukan dependensi sekunder:
dcoscli == 0.4.14 membutuhkan dcos == 0.4.14, dcoscli == 0.4.14, docopt <1.0,> = 0.6, pkginfo == 1.2.1, toml <1.0,> = 0.9, virtualenv <16.0,> = 13.0
mengapa mencoba menginstal 0.4.14 dari dcoscli? Terutama ketika pipenv --tiga run dcos --version menghasilkan dcoscli.version = 0.5.5.

-
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub, atau nonaktifkan utasnya.

Menghapus cache kunci tidak membantu. Ini adalah hasil lengkap dari pipenv --three lock --verbose

› pipenv --three lock --verbose
Virtualenv already exists!
Removing existing virtualenv…
Warning: PYENV_ROOT is not set. New python paths will probably not be exported properly after installation.
Creating a virtualenv for this project…
Using /Users/kjeschkies/.pyenv/shims/python3 to create virtualenv…
⠋Running virtualenv with interpreter /Users/kjeschkies/.pyenv/shims/python3
Using base prefix '/Users/kjeschkies/.pyenv/versions/3.5.2'
New python executable in /Users/kjeschkies/.local/share/virtualenvs/marathon-ldTRsJsI/bin/python3
Also creating executable in /Users/kjeschkies/.local/share/virtualenvs/marathon-ldTRsJsI/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/kjeschkies/.local/share/virtualenvs/marathon-ldTRsJsI
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:
  dcos-shakedown

Finding the best candidates:
  found candidate dcos-shakedown==1.4.8 (constraint was <any>)

Finding secondary dependencies:
  dcos-shakedown==1.4.8     requires click, dcos-shakedown==1.4.8, dcoscli==0.5.5, paramiko, pytest, pytest-timeout, retrying, scp

New dependencies found in this round:
  adding [u'click', '', '[]']
  adding [u'dcos-shakedown', '==1.4.8', '[]']
  adding [u'dcoscli', '==0.5.5', '[]']
  adding [u'paramiko', '', '[]']
  adding [u'pytest', '', '[]']
  adding [u'pytest-timeout', '', '[]']
  adding [u'retrying', '', '[]']
  adding [u'scp', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 1: not stable

                          ROUND 2
Current constraints:
  click
  dcos-shakedown==1.4.8
  dcoscli==0.5.5
  paramiko
  pytest
  pytest-timeout
  retrying
  scp

Finding the best candidates:
  found candidate click==6.7 (constraint was <any>)
  found candidate dcos-shakedown==1.4.8 (constraint was ==1.4.8)
  found candidate dcoscli==0.5.5 (constraint was ==0.5.5)
  found candidate paramiko==2.3.1 (constraint was <any>)
  found candidate pytest==3.2.3 (constraint was <any>)
  found candidate pytest-timeout==1.2.0 (constraint was <any>)
  found candidate retrying==1.3.3 (constraint was <any>)
  found candidate scp==0.10.2 (constraint was <any>)

Finding secondary dependencies:
  pytest-timeout==1.2.0 not in cache, need to check index
  pytest-timeout==1.2.0     requires pytest-timeout==1.2.0, pytest>=2.8.0
  paramiko==2.3.1           requires bcrypt>=3.1.3, cryptography>=1.5, paramiko==2.3.1, pyasn1>=0.1.7, pynacl>=1.0.1
  click==6.7 not in cache, need to check index
  click==6.7                requires click==6.7
  pytest==3.2.3             requires py>=1.4.33, pytest==3.2.3, setuptools
  dcos-shakedown==1.4.8     requires click, dcos-shakedown==1.4.8, dcoscli==0.5.5, paramiko, pytest, pytest-timeout, retrying, scp
  retrying==1.3.3           requires retrying==1.3.3, six>=1.7.0
  dcoscli==0.5.5 not in cache, need to check index
CRITICAL:pip.index:Could not find a version that satisfies the requirement dcoscli==0.5.5 (from versions: 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6, 0.1.7, 0.1.8, 0.1.9, 0.1.10, 0.1.11, 0.1.12, 0.1.13, 0.1.14, 0.1.15, 0.2.0, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.4.0, 0.4.1, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6, 0.4.10, 0.4.11, 0.4.12, 0.4.13, 0.4.14)
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.
No matching distribution found for dcoscli==0.5.5

FYI setiap kali Anda lulus --tiga Anda memberi tahu pipenv untuk menghancurkan virtualenv Anda yang ada, tidak yakin apakah itu dimaksudkan tetapi hanya FYI. Saya akan melihat ini sedikit lebih banyak tetapi sekilas karena Anda telah menginstal pyenv, Anda harus mengatur variabel lingkungan PYENV_ROOT per pesan kesalahan juga.

@techalemy , terima kasih. Saya tidak tahu bahwa --three akan membuat env baru setiap saat. Saya pikir itu hanya akan memberi tahu pipenv untuk hanya menggunakan Python 3. Saya menetapkan PYENV_ROOT sekali tetapi kemudian pipenv membuat virtuelenv dengan Python 3.6, bukan 3.5 seperti yang didefinisikan dalam pyenv lokal saya.

Saya masih berpikir bahwa masalahnya adalah pipenv mencoba membuat penutupan untuk Python 2 dan penggeledahan itu tidak terbatas pada Python 3.

Melontarkan pengamatan saya pada perilaku resolusi ketergantungan:
Sepertinya Python 2 atau pip2 yang dapat dieksekusi digunakan untuk resolusi ketergantungan di sini.
Saya merasa saya telah melihat masalah serupa akhir-akhir ini, tetapi belum punya waktu untuk memeriksanya.

Mengambil tebakan di sini di lingkungan di sini, saya akan mengatakan pipenv diinstal secara global (yang ok), dan python global atau root adalah Python 2. @jeschkies Dapatkah Anda mengonfirmasi apakah itu benar? Catatan, saya tidak berbicara tentang versi python dari virtualenv yang dibuat oleh pipenv , saya berbicara tentang python yang dapat dieksekusi yang digunakan untuk menjalankan pipenv .
Saya juga mencatat bahwa Anda tampaknya menggunakan pyenv , saya tidak yakin apakah ada efek samping di sini pada python yang dapat dieksekusi yang digunakan oleh pipenv itu sendiri ..

Saya bukan ahli (belum) tentang bagaimana pipenv menentukan versi python / pip mana yang akan digunakan untuk dirinya sendiri, tetapi jika ia secara membabi buta memilih root python dari lingkungan tempat ia diinstal untuk dirinya sendiri, maka kita tahu mengapa kita mendapatkan hasil python 2 di sini.

Terima kasih atas petunjuknya @vphilippon. Saya telah merobek versi pyenv lama saya dan menginstal yang terbaru dan Python 3.5.2. Saya kemudian memperbarui pip ke 9.0.1 di luar virtualenv. Saya juga menambal penggeledahan untuk meminta versi Python tertentu dan menggunakan dependensi git. Lihat
https://github.com/jeschkies/shakedown/blob/master/setup.py
https://github.com/mesosphere/marathon/blob/karsten/use-pipenv/Pipfile

Saya bertanya-tanya bagaimana kuncinya bekerja karena tidak menyebutkan hash komit sejauh yang saya tahu. Juga, kunci menyatakan versi cli dc sebagai 0.4.14 tetapi pipenv run dcos --version keluaran 0.5.5.

Secara keseluruhan saya bertanya-tanya bagaimana pipenv menangani versi Python yang berbeda dan apa yang diharapkan dari pipenv dalam hal itu.

Hm kunci tidak berfungsi untuk dependensi:

system in marathon/ on karsten/use-pipenv
› pipenv --rm
Removing virtualenv (/Users/kjeschkies/.local/share/virtualenvs/marathon-ldTRsJsI)…

system in marathon/ on karsten/use-pipenv
› pipenv install
Creating a virtualenv for this project…
Using /Users/kjeschkies/.pyenv/versions/3.5.2/bin/python3.5m to create virtualenv…
⠋Running virtualenv with interpreter /Users/kjeschkies/.pyenv/versions/3.5.2/bin/python3.5m
Using base prefix '/Users/kjeschkies/.pyenv/versions/3.5.2'
New python executable in /Users/kjeschkies/.local/share/virtualenvs/marathon-ldTRsJsI/bin/python3.5m
Also creating executable in /Users/kjeschkies/.local/share/virtualenvs/marathon-ldTRsJsI/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/kjeschkies/.local/share/virtualenvs/marathon-ldTRsJsI
Installing dependencies from Pipfile.lock (0d5d00)…
Ignoring ipaddress: markers 'python_version < "3"' don't match your environment
Ignoring enum34: markers 'python_version < "3"' don't match your environment
Ignoring futures: markers 'python_version == "2.7"' don't match your environment
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 34/34 — 00:00:08
To activate this project's virtualenv, run the following:
 $ pipenv shell

system in marathon/ on karsten/use-pipenv
› pipenv run dcos --version
dcoscli.version=0.4.14
dcos.version=1.9.4
dcos.commit=f843772e2740889cc4bba263db44f1403e670037
dcos.bootstrap-id=79f6d6e1c406bffd3fab28b36815220575ae5995

Jadi pada dasarnya menginstal dengan pipenv install -e git+https://github.com/jeschkies/shakedown#egg=dcos-shakedown membuat Pipefile.lock yang kurang akurat.

Nah perintah yang Anda jalankan baru saja menggunakan kembali lockfile yang sudah Anda berikan, saya percaya pipenv pertama-tama perlu diberi tahu versi python mana yang seharusnya digunakan jika Anda memerlukan versi yang berbeda dari default untuk kasus penggunaan Anda

Melihat itu, defaultnya, venv tampaknya menggunakan Python 3.5.2, dan mengevaluasi marker seperti itu. Sepertinya itu satu langkah maju.

@jeschkies Saya akan menghapus Pipfile.lock dan menjalankan pipenv lock --clear untuk melakukan penguncian fersh. Jika masalah root python tidak lagi menjadi penyebabnya, itu harus dilakukan.

Saya setuju dengan @vphilippon tetapi jika Anda memiliki masalah lebih lanjut, saya akan bertanya apakah Anda dapat memberikan Pipfile dan Pipfile.lock sehingga kami dapat membantu proses pemecahan masalah lebih lanjut

Saya memulai baru tanpa Pipfile.lock dan kemudian menggunakan file kunci untuk membuat ulang env. Saya akan mencobanya sekali lagi laporan kembali.

Baik. Saya telah mereproduksi masalah di folder yang bersih. Anda melihat semua perintah keluar dari keluaran dalam inti ini .

Inilah yang saya coba lakukan dan apa yang terjadi:

  1. Instal penggeledahan dari git untuk Python 3.5 dengan pipenv --three -e git+https://github.com/jeschkies/shakedown.git#egg=dcos-shakedown
  2. dcos-cli, salah satu ketergantungan shakedown adalah install dengan versi 0.5.5. Ini seperti yang diharapkan.
  3. Hapus virtualenv dengan pipenv --rm .
  4. Buat virtualenv baru dengan pipenv --three install .
  5. dcos-cli 0.4.14 diinstal. Ini tidak diharapkan.

Benar, tetapi saya masih ingin Anda menyertakan pipfile.lock untuk membantu memecahkan masalah. Bisakah Anda juga memberikan output pipenv lock —verbose setelah Anda melihat info versi yang salah

Berikut adalah output dari pipenv lock --verbose dan Pipfile.lock dihasilkan

Termasuk Pipfile.lock

"dcos": {
    "hashes": [
                "sha256:3d48d0773b5dd5e82ddb9cfa946f17755789e8c2ff53ecc75b32194b41248611"
            ],
    "version": "==0.4.14"
}

tetapi pipenv run dcos --version menghasilkan dcoscli.version=0.5.5 .

Baiklah, keluaran verbose yang diberikan ini koheren dan sesuai dengan konten dari Pipfile.lock .
Namun, versi terpasang yang dilaporkan (dari dcos --version ) tidak cocok.

Saya mencoba langkah-langkah tersebut dan tidak dapat mereproduksi. Saya mendapat:

"dcos": {
    "hashes": [
        "sha256:01d722e13296bd38c2b391ffbd5bc111fa7b5ec09bb058651713bce62a2d45a7"
    ],
    "version": "==0.5.5"
},
"dcos-shakedown": {
    "editable": true,
    "git": "https://github.com/jeschkies/shakedown.git",
    "ref": "012841a38a59d00043c15a66400501811715ab86"
},
"dcoscli": {
    "hashes": [
        "sha256:47b442a2823ab3b27cd520f5c3762ab0e630eca473a273e111619bd5c1a16ea6"
    ],
    "version": "==0.5.5"
},

dan, dari pipenv run dcos --version

dcoscli.version=0.5.5
dcos.version=N/A
dcos.commit=N/A
dcos.bootstrap-id=N/A

baik pada pemasangan pertama, dan pada pemasangan ulang dari Pipfile.lock .

@jeschkies Dalam perintah dari intinya, saya tidak melihat pipenv lock --clear (perhatikan --clear ). Apakah Anda menjalankannya seperti yang saya sarankan sebelumnya? Jika tidak, silakan lakukan, karena ini masih bisa menjadi masalah dengan cache ketergantungan. (Dan tidak ada salahnya mengulanginya menjadi 100% yakin.)

Sebaliknya, jika kami yakin 100% cache ketergantungan telah dihapus, berikan output pipenv run pip freeze .

@vphilippon apakah Anda menggunakan pyenv ? Saya curiga inilah masalahnya di sini. Saya tidak bisa mengunci dcos-cli 0.5.5 dengan yang berikut:

  • mkdir pipenv-test && cd pipenv-test
  • pyenv local 3.5.2
  • pipenv --three install -e git+https://github.com/jeschkies/shakedown.git#egg=dcos-shakedown

Pipfile.lock akan memiliki 0.4.14. Apa yang kulewatkan di sini? Apakah pipenv mengambil dari versi Python atau paket dcos-cli yang salah?

@jeschkies Tidak, saya tidak menggunakan pyenv . Itu adalah hal berikutnya yang akan saya periksa, setelah memastikan itu bukan masalah cache ketergantungan. Saya juga ingin melihat daftar lengkap versi paket yang diinstal, itulah sebabnya saya meminta output pipenv run pip freeze .

Kami membutuhkan seseorang untuk mencoba menggunakan pyenv dan mencoba mereproduksi, meskipun jika semua lingkungan python Anda ada di Py 3+ sekarang, itu seharusnya tidak menjadi masalah yang menyebabkan ketergantungan Py 2 dihitung.

Saya tidak percaya pipenv menghormati pengaturan pyenv lokal, yang berpotensi menimbulkan masalah bagi Anda. Ketika saya mencoba menjalankan pipenv install... sistem saya mencoba untuk kembali ke python 2.7.

Menjalankan perintah sebagai pipenv --python=3.5.2 install -e git+https://github.com/jeschkies/shakedown.git#egg=dcos-shakedown berfungsi dengan baik (dan merupakan cara yang disarankan untuk menentukan versi python ke pipenv alih-alih berharap itu mengambil file lokal):

        "dcos": {
            "hashes": [
                "sha256:01d722e13296bd38c2b391ffbd5bc111fa7b5ec09bb058651713bce62a2d45a7"
            ],
            "version": "==0.5.5"
        },
        "dcos-shakedown": {
            "editable": true,
            "git": "https://github.com/jeschkies/shakedown.git",
            "ref": "012841a38a59d00043c15a66400501811715ab86"
        },
        "dcoscli": {
            "hashes": [
                "sha256:47b442a2823ab3b27cd520f5c3762ab0e630eca473a273e111619bd5c1a16ea6"
            ],
            "version": "==0.5.5"
        },

FYI ini adalah masalah yang terkait dengan bagaimana pipenv menyelesaikan jalur pyenv pyenv, karena tidak tahu tentang pengaturan lokal pyenv, ia akan menggunakan tebakannya sendiri di interpreter python mana yang akan digunakan di virtualenv dibandingkan dengan untuk resolusi ketergantungan. Ini akan menjadi berbeda karena satu akan diselesaikan oleh pyenv shims dan yang lainnya tidak.

@ Techalchemy apakah ini bug di pipenv atau pyenv atau keduanya ???

Ini adalah hasil dari pipenv run pip freeze setelah saya menjalankan pipenv --python=3.5.2 install -e git+https://github.com/jeschkies/shakedown.git#egg=dcos-shakedown . Berikut adalah konten Pipfile.lock tersebut

       "dcos": {
            "hashes": [
                "sha256:3d48d0773b5dd5e82ddb9cfa946f17755789e8c2ff53ecc75b32194b41248611"
            ],
            "version": "==0.4.14"
        },
        "dcos-shakedown": {
            "editable": true,
            "git": "https://github.com/jeschkies/shakedown.git",
            "ref": "012841a38a59d00043c15a66400501811715ab86"
        },
        "dcoscli": {
            "hashes": [
                "sha256:1d7506df5e32fc96566169896fb42ba80aba4687d1c65eb2b52b320b5cfad0ca"
            ],
            "version": "==0.4.14"
        },

Ini sangat aneh. Bahkan dengan pyenv global 3.5.2 itu tidak bekerja.

@jeschkies coba pipenv lock —clear per @vphillipon di atas sekarang setelah Anda secara eksplisit memberi tahu pipenv untuk menggunakan 3.5.2 dan lihat apakah Anda mendapatkan resolusi yang benar

@erinxocon itu hanya bug jika menurut Anda pipenv harus menghormati pengaturan pyenv lokal secara umum. Yang saya maksud adalah, jika Anda menetapkan pyenv local 3.5.2 dan kemudian menjalankan pipenv install menurut saya ini berfungsi dengan benar. Namun, tanda —three dan —two helper mencari jalur secara terpisah untuk versi terbaru yang diinstal, tidak peduli versi mana yang telah Anda konfigurasikan dengan pyenv. Jadi pertanyaannya sebenarnya adalah apakah pipenv seharusnya menghormati pilihan pyenv Anda jika diterapkan. Ini terasa seperti kasus tepi terutama ketika Anda bisa bersikap eksplisit ketika Anda tidak menginginkan versi terbaru.

@techalchemy bahkan pipenv lock --clear tidak bekerja. Saya pikir itu benar-benar hanya pipenv yang mengabaikan konfigurasi pyenv saya tidak peduli apa. Apa jalur pencarian pipenv untuk Python dengan opsi --three di macOS?

@jeschkies Ini hanya melihat variabel $ PATH Anda untuk mencari.

@techemy aku robek. Agaknya seperti masalah lingkungan pengguna, di luar cakupan pipenv. Namun itu awalnya pemikiran kami saat menggunakan pew untuk manajemen virtualenv, yang menyebabkan lebih banyak masalah karena shell yang tidak dikonfigurasi dengan benar, jadi meskipun bukan masalah pipenv, kami mengubahnya untuk menghindari masalah.

@erinxocon hm, bagaimana Anda bisa memiliki versi Python yang berbeda tanpa pyenv? Haruskah saya menginstalnya dan memilikinya di $PATH ? Sepertinya itu tidak benar. Saya mengerti bahwa pipenv seharusnya tidak terlalu pintar tentang itu. Namun, beberapa dokumen mungkin akan membantu di sini.

@jeschkies python normal diletakkan di jalur, dan jika Anda menginstal 6 versi ya, semua berjalan di jalur Anda. Pyenv adalah fungsi pembantu tetapi jelas tidak diperlukan, dan pipenv tidak membaca file konfigurasi. Itu hanya melihat di jalur Anda untuk apa 'python' menunjuk kecuali Anda menentukan versi atau eksekusi tertentu. Pyenv shims agak berantakan yang menurut saya itulah mengapa kami tidak menggunakannya.

--three dan --two cari saja jalur untuk python3 atau python2 di jalur Anda. Saat ini python2 hanya diizinkan untuk diberi nama python dan python3 adalah python3 . Anda dapat memiliki semua versi python di jalur Anda, mereka hanya akan ditangani menggunakan sintaks yang lebih spesifik. python26 , python27 , python34

HM Oke. Jadi, apakah ada cara lain untuk mengelola versi Python yang bekerja lebih baik dengan pipenv?

@jeslek lebih bagus? Saya pribadi menggunakan pyenv dengan PIPENV_DEFAULT_PYTHON_VERSION SET TO 3.6.3 . Dengan pyenv terinstal (atau setup apa pun sebenarnya) Anda cukup mengirimkan —python=3.6.3 atau —python=2.7.14 . Itulah masalahnya dengan menebak (Ie dengan —three dan —two ) - itu tidak eksplisit. Jika Anda menginginkan versi tertentu, Anda perlu menentukannya

Saya mengalami masalah yang sama saat mencoba memasang Django==2.0b1 . Ini hanya menawarkan roda Python 3 (sama dengan dcoscli ).

Saya telah menginstal Pipenv secara global melalui Homebrew, dan saya menggunakan pyenv untuk mengelola versi Python saya. Saya juga menentukan python_full_version = "3.6.3" di Pipfile saya (bersama dengan opsi prarilis).

Gagal ketika saya menjalankan pipenv install melalui Pipenv global, tetapi jika saya menginstal Pipenv (melalui Pip) dalam versi Python 3, maka berhasil. Saya menduga ini berarti Pipenv tidak menggunakan versi yang ditentukan dalam Pipfile untuk melakukan pencarian versi dependensi? Saya mendapatkan kesalahan yang sama saat menggunakan pip install dengan Python 2.7.10.

Saya sudah mencoba menggunakan variabel lingkungan PIPENV_DEFAULT_PYTHON_VERSION , tetapi itu juga tidak berhasil.

Hai @jamieconnolly Saya pikir ini mungkin ada hubungannya dengan shims pyenv yang diberlakukan untuk membuat banyak lingkungan tersedia. Tidak bisa memastikan ini karena saya tidak menggunakan pyenv.

@jamieconnolly Saya menduga ini terkait dengan bug yang sama yang kami miliki titik kontaknya di berbagai tempat yang berkaitan dengan, seperti yang Anda sebutkan, tipu muslihat resolusi ketergantungan. Namun satu pertanyaan - apakah pipenv install berhasil menginstal versi yang ditentukan dalam kasus sebelumnya, tetapi gagal pada langkah resolusi dan menyarankan Anda untuk menggunakan --skip-lock ? Atau apakah itu gagal dipasang di tempat pertama?

@ Jamieconnolly , terima kasih atas petunjuknya. Saya akan mencoba menggunakan instalasi pipenv melalui pip dari konfigurasi pyenv lokal.

@ Techalchemy , saya harus lebih spesifik. Tampaknya pipenv tidak mengambil versi Python yang benar dari pyenv ketika menghasilkan Pipfile.lock. Seperti yang Anda katakan

Jadi pertanyaannya sebenarnya adalah apakah pipenv seharusnya menghormati pilihan pyenv Anda jika diterapkan.

Karena jawabannya belum tentu ya, saya bertanya-tanya bagaimana saya dapat mengelola versi Python yang berbeda sehingga pipenv mengambil yang benar saat menghasilkan file kunci.

Saya juga akan mencoba --python=3.6.3 .

@jeschkies yang saya maksud adalah tidak menghormati apa pun yang Anda tetapkan dengan pyenv shell atau pyenv local atau apa pun. Itu harus menghormati python yang ada di jalur Anda, dan berpotensi jika pyenv dikonfigurasi dengan benar itu akan menghormati apa pun yang diatur dengan pyenv global karena begitulah cara shim untuk python akan diselesaikan (jika Anda tidak menentukan versi )

Ok, tapi saya bertanya-tanya mengapa versi pyenv local Python tidak ditemukan saat file kunci dibuat. Bisa berupa konfigurasi pyenv atau masalah dengan pipenv. Saya tidak yakin itu konfigurasinya karena pipenv tidak memiliki masalah dalam menginstal paket yang benar dan versi Python di pipenv shell python --version juga benar. Jadi mengapa pipenv lock tidak menggunakan versi yang benar?

@jeschkies karena jika Anda tidak menentukan versi, pipenv run dan pipenv shell akan default ke sistem python (yang pyenv akan menyelesaikan melalui shims jika Anda menggunakan pyenv local untuk apa pun yang Anda setel ). Resolusi terjadi menggunakan resolver pip-tools dan tidak pernah memanggil python secara langsung, sehingga shims pyenv pada dasarnya dilewati untuk resolusi versi dan pipenv hanya melihat melalui PATH dan PYENV_ROOT semua ular sanca yang tersedia. Jadi itulah mengapa pyenv local tidak berdampak pada lockfile.

@ Techalchemy , ah, ok, saya rasa saya sudah memahami perbedaannya sekarang. Jadi pipenv install dan pipenv shell melakukan pemanggilan Python secara langsung dan itulah mengapa saya mengakhirinya dengan versi yang benar di sana?

@jeschkies itu sebagian besar benar, meskipun saya pikir pipenv shell akan bergantung pada apakah Anda menggunakan variabel lingkungan PIPENV_SHELL_FANCY / berada di windows

Saya melihat masalah yang sama dengan Django==2.0rc1 . Benar-benar tidak banyak yang bisa ditambahkan selain apa yang dikatakan @jamieconnolly , tetapi inilah beberapa data, jika Anda mau:

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

[paket-dev]

[paket]

"psycopg2" = "*"
django = "== 2.0rc1"

[pipenv]
allow_prereleases = true


➜ metada git: (master) ✗ pip3 dibekukan
certifi == 2017.11.5
chardet == 3.0.4
Django == 2.0rc1
serpihan8 == 3.5.0
idna == 2.6
mccabe == 0.6.1
bangku == 1.1.0
pycodestyle == 2.3.1
pyflakes == 1.6.0
pytz == 2017.3
permintaan == 2.18.4
urllib3 == 1.22
virtualenv == 15.1.0
virtualenv-clone == 0.2.6


When I try to lock, even with `--pre`, I get this:

➜ metada git: (master) ✗ kunci pipenv --pre
Mengunci dependensi [dev-packages]…
Mengunci dependensi [paket]…
KRITIS: pip.index : Tidak dapat menemukan versi yang memenuhi persyaratan django == 2.0rc1 (dari versi: 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.3, 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9, 1.5.10, 1.5.11, 1.5.12, 1.6, 1.6.1, 1.6.2, 1.6.3, 1.6.4, 1.6.5, 1.6.6, 1.6.7, 1.6.8, 1.6.9, 1.6.10, 1.6.11, 1.7, 1.7.1, 1.7.2, 1.7.3, 1.7.4, 1.7.5, 1.7.6, 1.7.7, 1.7.8, 1.7.9, 1.7.10, 1.7.11, 1.8a1, 1.8b1, 1.8b2, 1.8rc1, 1.8, 1.8.1, 1.8.2, 1.8.3, 1.8.4, 1.8.5, 1.8.6, 1.8.7, 1.8.8, 1.8.9, 1.8.10, 1.8.11, 1.8.12, 1.8.13, 1.8.14, 1.8.15, 1.8. 16, 1.8.17, 1.8.18, 1.9a1, 1.9b1, 1.9rc1, 1.9rc2, 1.9, 1.9.1, 1.9.2, 1.9.3, 1.9.4, 1.9.5, 1.9.6, 1.9. 7, 1.9.8, 1.9.9, 1.9.10, 1.9.11, 1.9.12, 1.9.13, 1.10a1, 1.10b1, 1.10rc1, 1.10, 1.10.1, 1 .10.2, 1.10.3, 1.10.4, 1.10.5, 1.10.6, 1.10.7, 1.10.8, 1.11a1, 1.11b1, 1.11rc1, 1.11, 1.11.1, 1.11.2, 1.11.3, 1.11.4, 1.11.5, 1.11.6, 1.11.7)
Peringatan: Dependensi Anda tidak dapat diselesaikan. Anda mungkin memiliki ketidakcocokan di sub-dependensi Anda.
Anda dapat menggunakan $ pipenv install --skip-lock untuk melewati mekanisme ini, lalu jalankan grafik $ pipenv untuk memeriksa situasinya.


So when I do that, and run the graph:

➜ metada git: (master) ✗ grafik pipenv
Django == 2.0rc1

  • pytz [wajib: Apa saja, terpasang: 2017.3]
    psycopg2 == 2.7.3.2

Just can't create a lock file if I specify the version like that.

If I drop the `==2.0rc1` in `Pipfile` and allow pre-relerases (which I already did), it'll go back to a 1.17 something like that in the lock file, which isn't what I want.

And here's a another output:

➜ metada git: (master) ✗ pipenv run pip freeze
Django == 2.0rc1
pytz == 2017.3
``

Maaf untuk mengirim spam ke semua orang, tetapi saya juga menemukan "solusi" masalah saya. Saya awalnya memasang piping melalui brew tetapi memutuskan untuk beralih ke instalasi melalui pip , atau lebih tepatnya pip3 melalui pip3 install --user pipenv .

Versi pipenv ini dapat mengunci Django==2.0rc1 dengan benar. Saya tidak yakin apakah # 965 benar-benar terkait dengan ini, tetapi saya juga melihat masalah itu saat Googlin 'jadi saya pikir saya akan menyebutkannya. Pada dasarnya, bagaimana seseorang memasang pipenv tampaknya membuat perbedaan, apakah ia mengambil roda python yang benar saat melakukan pemasangan / kunci.

Saya tampaknya telah mengatasi masalah serupa dengan menghapus instalasi homebrew pipenv dan menggunakan standar pip3 install pipenv . Saya pikir pesan kesalahan saya terkait dengan dependensi python 2 yang https://github.com/Homebrew/homebrew-core/blob/master/Formula/pipenv.rb butuhkan, saya berharap dengan asumsi pemasangan python2 asli daripada memanfaatkan python 3 jika tersedia. Akan mencoba mengirim pesan kesalahan ketika saya punya waktu untuk mereproduksi.

ini mungkin karena batasan setup.py, tidak ada yang bisa kami lakukan

misalnya instal pipenv dengan python3

Pipenv homebrew akan segera menggunakan python3 sebagai default untuk membantu menghindari hal-hal ini.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat