Pipenv: Невозможно построить блокировку, хотя зависимости найдены.

Пакет shakedown, вероятно, должен быть только Python 3. Однако я думаю, что pipenv должен создавать блокировку только для определенной версии Python, если файл Pipefile включает требуемую версию Python.

Вот подробный вывод блокировки

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

Это странно. Когда я устанавливаю dcsocli с помощью pipenv --three install dcoscli я вижу

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

followed by

                      ROUND 1

Текущие ограничения:
dcos-shakedown из git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown
dcoscli

Поиск лучших кандидатов:
найден кандидат -e git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown (ограничение было)
найден кандидат dcoscli == 0.4.14 (ограничение было)

Поиск вторичных зависимостей:
dcoscli == 0.4.14 требует 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
`` ''

почему он пытается установить 0.4.14 dcoscli? Особенно, когда pipenv --three run dcos --version выводит dcoscli.version=0.5.5 .

Это не. Это процесс блокировки. Он выполняет разрешение зависимостей на основе того, что он знает и что вы кэшировали. Попробуйте блокировку pipenv — clear

18 октября 2017 г. в 6:16 Карстен Ешкис [email protected] написал:

Это странно. Когда я устанавливаю dcsocli с помощью pipenv --three install dcoscli, я вижу

Установка dcoscli…
Сбор dcoscli
Использование кешированного dcoscli-0.5.5-py3-none-any.whl
с последующим

                      ROUND 1

Текущие ограничения:
dcos-shakedown из git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown
dcoscli

Поиск лучших кандидатов:
найден кандидат -e git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown (ограничение было)
найден кандидат dcoscli == 0.4.14 (ограничение было)

Поиск вторичных зависимостей:
dcoscli == 0.4.14 требует 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
почему он пытается установить 0.4.14 dcoscli? Особенно, когда pipenv --three run dcos --version выводит dcoscli.version = 0.5.5.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

Вам нужно будет предоставить вывод pipenv lock —verbose и pipenv —version.

18 октября 2017 г. в 6:16 Карстен Ешкис [email protected] написал:

Это странно. Когда я устанавливаю dcsocli с помощью pipenv --three install dcoscli, я вижу

Установка dcoscli…
Сбор dcoscli
Использование кешированного dcoscli-0.5.5-py3-none-any.whl
с последующим

                      ROUND 1

Текущие ограничения:
dcos-shakedown из git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown
dcoscli

Поиск лучших кандидатов:
найден кандидат -e git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown (ограничение было)
найден кандидат dcoscli == 0.4.14 (ограничение было)

Поиск вторичных зависимостей:
dcoscli == 0.4.14 требует 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
почему он пытается установить 0.4.14 dcoscli? Особенно, когда pipenv --three run dcos --version выводит dcoscli.version = 0.5.5.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

Очистка кеша блокировок не помогла. Вот полный вывод 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

К вашему сведению каждый раз, когда вы проходите - три вы говорите pipenv, чтобы он уничтожил ваш существующий virtualenv, не уверен, было ли это задумано, но просто FYI. Я рассмотрю это немного подробнее, но вкратце, поскольку у вас установлен pyenv, вам также следует установить переменную среды PYENV_ROOT для сообщения об ошибке.

@techalchemy , спасибо. Я не знал, что --three будет каждый раз создавать новый env. Я думал, что он просто скажет pipenv использовать только Python 3. Я установил PYENV_ROOT один раз, но затем pipenv создал virtuelenv с Python 3.6 вместо 3.5, как определено в моем локальном pyenv.

Я по-прежнему думаю, что проблема в том, что pipenv пытается создать закрытие для Python 2, и это не ограничивается Python 3.

Бросая мое наблюдение за поведением разрешения зависимостей:
Похоже, что для разрешения зависимостей здесь используется исполняемый файл Python 2 или pip2.
У меня такое чувство, что я видел похожие проблемы в последнее время, но у меня не было времени разобраться в них.

Догадываясь здесь о среде, я бы сказал, что pipenv был установлен глобально (что нормально), и что глобальный или корневой питон - это Python 2. @jeschkies Можете ли вы подтвердить, правильно ли? Обратите внимание, я не говорю о версии virtualenv для Python, созданной pipenv , я говорю о исполняемом файле python, используемом для запуска pipenv .
Я также заметил, что вы, похоже, используете pyenv , я не уверен, есть ли здесь какой-либо побочный эффект от исполняемого файла python, используемого самим pipenv ..

Я (пока) не эксперт в том, как pipenv определяет, какую версию python / pip использовать для себя, но если он просто слепо выбирает корневой питон среды, в которой он установлен для себя, тогда мы знаем почему мы получаем здесь результаты Python 2.

Спасибо за указатели @vphilippon. Я вынул свою старую версию pyenv и установил последнюю и Python 3.5.2. Затем я обновил pip до 9.0.1 за пределами virtualenv. Я также пропатчил shakedown, чтобы потребовать конкретную версию Python и использовал зависимости git. Видеть
• https://github.com/jeschkies/shakedown/blob/master/setup.py
• https://github.com/mesosphere/marathon/blob/karsten/use-pipenv/Pipfile

Интересно, как работает блокировка, поскольку, насколько я могу судить, в ней не упоминается хеш фиксации. Кроме того, блокировка указывает версию dcos cli как 0.4.14, но pipenv run dcos --version выводит 0.5.5.

В целом мне интересно, как pipenv обрабатывает разные версии Python и чего следует ожидать от pipenv в этом отношении.

Хм блокировка не работает для зависимостей:

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

Итак, в основном установка с pipenv install -e git+https://github.com/jeschkies/shakedown#egg=dcos-shakedown создающая Pipefile.lock, не совсем точна.

Ну, команда, которую вы запустили, просто повторно использовала файл блокировки, который у вас уже был, я считаю, что pipenv сначала нужно сообщить, какую версию python он должен использовать, если вам нужна версия, отличная от версии по умолчанию для вашего варианта использования.

Глядя на это, по умолчанию venv, похоже, использует Python 3.5.2 и оценивает маркеры как таковые. Это похоже на шаг вперед.

@jeschkies Я бы удалил Pipfile.lock и запустил pipenv lock --clear чтобы продолжить блокировку ферша. Если проблема с корневым питоном больше не является причиной, это должно сработать.

Я согласен с @vphilippon, но если у вас возникнут дополнительные проблемы, я бы спросил, можете ли вы предоставить свои Pipfile и Pipfile.lock чтобы мы могли помочь с процессом устранения неполадок в дальнейшем

Я начал все заново без Pipfile.lock а затем использовал файл блокировки для воссоздания env. Я попробую еще раз доложить.

Хорошо. Я воспроизвел проблему в чистой папке. Вы видите все команды вывода в этой сути .

Вот что я пытаюсь сделать и что получается:

1. Установите shakedown из git для Python 3.5 с помощью pipenv --three -e git+https://github.com/jeschkies/shakedown.git#egg=dcos-shakedown
2. dcos-cli, одна из зависимостей shakedown устанавливается с версией 0.5.5. Это как и ожидалось.
3. Удалите virtualenv с помощью pipenv --rm .
4. Создайте новый virtualenv с помощью pipenv --three install .
5. Установлен dcos-cli 0.4.14. Этого не ожидалось.

Верно, но мне все равно нужно, чтобы вы указали свои pipfile.lock чтобы помочь в устранении неполадок. Можете ли вы также предоставить вывод pipenv lock —verbose после того, как вы увидели неправильную информацию о версии

Вот результат pipenv lock --verbose и сгенерированный Pipfile.lock

Pipfile.lock включает

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

но pipenv run dcos --version дает dcoscli.version=0.5.5 .

Хорошо, этот подробный вывод является последовательным и соответствует содержимому Pipfile.lock .
Но заявленная установленная версия (от dcos --version ) не совпадает.

Я попробовал выполнить шаги и не смог воспроизвести. Я получил:

"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"
},

и от pipenv run dcos --version

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

как при первой установке, так и при повторной установке из Pipfile.lock .

@jeschkies В командах из pipenv lock --clear (обратите внимание на --clear ). Вы запустили его, как я предлагал раньше? Если нет, сделайте это, так как это все еще может быть проблемой с кешем зависимостей. (И нет ничего плохого в том, чтобы переделать его, чтобы быть уверенным на 100%.)

В противном случае, если мы на 100% уверены, что кеш зависимостей очищен, выведите вывод pipenv run pip freeze .

@vphilippon вы используете pyenv ? Я подозреваю, что проблема в этом. Я не могу заставить его заблокировать dcos-cli 0.5.5 следующим образом:

• 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 будет версия 0.4.14. Что мне здесь не хватает? Подбирает ли pipenv версию Python или неправильный пакет dcos-cli?

@jeschkies Нет, я не использую pyenv . Это было следующим, что я собирался проверить, после того как убедился, что это не проблема с кешем зависимостей. Я также хотел взглянуть на полный список установленных версий пакетов, поэтому я попросил вывести pipenv run pip freeze .

Нам понадобится кто-то, чтобы попытаться использовать pyenv и попытаться воспроизвести, хотя, если вся ваша среда python сейчас находится на Py 3+, это не должно быть проблемой, вызывающей вычисление зависимостей Py 2.

Я не верю, что pipenv соблюдает локальную настройку pyenv, что потенциально может вызвать у вас проблемы. Когда я попытался просто запустить pipenv install... моя система попыталась вернуться к Python 2.7.

Выполнение команды как pipenv --python=3.5.2 install -e git+https://github.com/jeschkies/shakedown.git#egg=dcos-shakedown сработало нормально (и это рекомендуемый способ указать версии python для pipenv вместо того, чтобы надеяться, что он подхватит локальный файл):

        "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"
        },

К вашему сведению, это проблема, связанная с тем, как pipenv разрешает пути pyenv python, поскольку он не знает о локальных настройках pyenv, он будет использовать свое собственное предположение, какой интерпретатор python использовать в virtualenv по сравнению с для разрешения зависимостей. Они окажутся разными, потому что одна будет решена прокладками pyenv, а другая - нет.

@techalchemy это ошибка в pipenv или pyenv или в обоих ???

Вот результат pipenv run pip freeze после того, как я запустил pipenv --python=3.5.2 install -e git+https://github.com/jeschkies/shakedown.git#egg=dcos-shakedown . Вот содержимое Pipfile.lock

       "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"
        },

Это так странно. Даже с pyenv global 3.5.2 не работает.

@jeschkies попробуйте pipenv lock —clear за @vphillipon выше, теперь, когда вы явно указали pipenv использовать 3.5.2, и посмотрите, получите ли вы правильное разрешение

@erinxocon - это ошибка, только если вы думаете, что pipenv должен уважать локальные настройки pyenv в целом. Я имею в виду, что если вы установите pyenv local 3.5.2 а затем запустите pipenv install я думаю, что это работает правильно. Однако флаги помощника —three и —two ищут путь отдельно для последней установленной версии, независимо от того, какую из них вы настроили с помощью pyenv. Итак, вопрос в том, должен ли pipenv вместо этого уважать ваш выбор pyenv, если они применимы. Это похоже на крайний случай, особенно когда вы можете просто сказать, что вам не нужна последняя версия.

@techalchemy даже pipenv lock --clear не работает. Я думаю, что на самом деле pipenv игнорирует мою конфигурацию pyenv, несмотря ни на что. Каков путь поиска pipenv для Python с опцией --three в macOS?

@jeschkies Он просто смотрит на вашу переменную $ PATH для поиска.

@techalchemy Я разорван. Похоже, что проблема с пользовательской средой выходит за рамки pipenv. Однако изначально мы так думали при использовании pew для управления virtualenv, что вызывало больше проблем из-за неправильной настройки оболочки, поэтому, хотя это и не проблема pipenv, мы изменили, чтобы избежать проблем.

@erinxocon хм, как бы у вас были разные версии Python без pyenv? Должен ли я просто установить их и разместить все на $PATH ? Это не кажется правильным. Я понимаю, что pipenv не должен слишком умничать. Однако здесь, вероятно, помогут некоторые документы.

@jeschkies нормальный питон помещается в путь, и если вы установите 6 версий, да, все пойдут по вашему пути. Pyenv - это вспомогательная функция, но она определенно не нужна, и pipenv не читает файлы конфигурации. Он просто смотрит на ваш путь, на что указывает «python», если вы не укажете версию или конкретный исполняемый файл. Прокладки Pyenv немного запутаны, поэтому я считаю, что мы их не используем.

--three и --two просто найдите путь для python3 или python2 на своем пути. На данный момент python2 может называться только python а python3 - это python3 . У вас могут быть все версии python на вашем пути, они просто будут рассмотрены с использованием более конкретного синтаксиса. python26 , python27 , python34

Хм, ладно. Так есть ли другой способ управлять версиями Python, которые лучше работают с pipenv?

@jeschkies лучше? Я лично использую pyenv с PIPENV_DEFAULT_PYTHON_VERSION SET TO 3.6.3 . С установленным pyenv (или любой другой установкой) вы можете просто передать —python=3.6.3 или —python=2.7.14 . Вот в чем дело с угадыванием (т.е. с —three и —two ) - это не явно. Если вам нужна конкретная версия, вам нужно будет указать ее

У меня такая же проблема при попытке установить Django==2.0b1 . Он предлагает только колесо Python 3 (то же, что и dcoscli ).

Я установил Pipenv глобально через Homebrew и использую pyenv для управления своими версиями Python. Я также указал python_full_version = "3.6.3" в моем файле Pipfile (вместе с опцией предварительного выпуска).

Он терпит неудачу, когда я запускаю pipenv install через глобальный Pipenv, но если я устанавливаю Pipenv (через Pip) в версии Python 3, тогда он преуспевает. Я предполагаю, что это означает, что Pipenv не использует версию, указанную в Pipfile, для поиска версии зависимости? Я получаю ту же ошибку при использовании pip install в Python 2.7.10.

Я пробовал использовать переменную окружения PIPENV_DEFAULT_PYTHON_VERSION , но это тоже не сработало.

Привет, @jamieconnolly, я думаю, это может иметь какое-то отношение к прокладкам, которые pyenv устанавливает, чтобы сделать доступными несколько сред. Не могу быть уверенным в этом, поскольку я не использую pyenv.

@jamieconnolly Я предполагаю, что это связано с той же ошибкой, для которой у нас есть точки соприкосновения в различных местах, связанных, как вы упомянули, с обманом разрешения зависимостей. Один вопрос: успешно ли pipenv install устанавливает указанную версию в первом случае, но не выполняет шаг разрешения и советует использовать --skip-lock ? Или вообще не получается установить?

@jamieconnolly , спасибо за подсказку. Я попробую использовать установку pipenv через pip локальной конфигурации pyenv.

@techalchemy , я должен быть более конкретным. Похоже, что pipenv не выбирает правильную версию Python из pyenv при создании Pipfile.lock. Как ты сказал

Итак, вопрос в том, должен ли pipenv вместо этого уважать ваш выбор pyenv, если они применимы.

Поскольку ответ не обязательно положительный, мне интересно, как я могу управлять другой версией Python, чтобы pipenv выбирал правильную версию при создании файла блокировки.

Я тоже попробую --python=3.6.3 .

@jeschkies то, что я имел в виду под этим, это то, что он не уважает то, что вы установили с помощью pyenv shell или pyenv local или чего-то еще. Он должен уважать питонов, которые находятся на вашем пути, и потенциально, если pyenv настроен правильно, он будет уважать все, что установлено с помощью pyenv global поскольку именно так будет разрешена прокладка для python (если вы не укажете версию )

Хорошо, но мне интересно, почему версия Python pyenv local не обнаруживается при создании файла блокировки. Это либо конфигурация pyenv, либо проблема с pipenv. Я не уверен, что это конфигурация, поскольку у pipenv нет проблем с установкой правильного пакета, и версия Python в pipenv shell python --version верна. Так почему же pipenv lock не выбирает правильную версию?

@jeschkies, потому что, если вы не укажете версию, pipenv run и pipenv shell умолчанию будут использовать системный python (который pyenv будет разрешать с помощью прокладок, если вы используете pyenv local для того, что вы установили ). Разрешение происходит с использованием резолвера pip-tools и никогда не вызывает python напрямую, поэтому прокладки pyenv по существу обходятся для разрешения версии, а pipenv просто просматривает ваши PATH и PYENV_ROOT для все доступные питоны. Вот почему pyenv local не влияют на файл блокировки.

@techalchemy , а, ладно, думаю, теперь я чувствую разницу. Итак, pipenv install и pipenv shell вызывают Python напрямую, и поэтому я заканчиваю там правильными версиями?

@jeschkies это в основном правильно, хотя я думаю, что pipenv shell будет зависеть от того, используете ли вы переменную среды PIPENV_SHELL_FANCY / в Windows

Я наблюдаю ту же проблему с Django==2.0rc1 . На самом деле нечего добавить, кроме того, что сказал

Pipfile
Имя = Pipfile
[[источник]]
url = " https://pypi.python.org/simple "
verify_ssl = true
name = "pypi"

[dev-пакеты]

[пакеты]

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

[pipenv]
allow_prereleases = true

➜ metada git: (мастер) ✗ pip3 freeze
certifi == 2017.11.5
chardet == 3.0.4
Django == 2.0rc1
flake8 == 3.5.0
idna == 2.6
mccabe == 0.6.1
pew == 1.1.0
pycodestyle == 2.3.1
pyflakes == 1.6.0
pytz == 2017.3
запросы == 2.18.4
urllib3 == 1.22
virtualenv == 15.1.0
виртуальный клон == 0.2.6

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

➜ metada git: (мастер) ✗ pipenv lock --pre
Блокировка зависимостей [dev-packages]…
Блокировка зависимостей [пакетов]…
КРИТИЧНО: pip.index : не удалось найти версию, удовлетворяющую требованию django == 2.0rc1 (из версий: 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)
Предупреждение: ваши зависимости не могут быть разрешены. Вероятно, у вас есть несоответствие в ваших зависимостях.
Вы можете использовать $ pipenv install --skip-lock, чтобы обойти этот механизм, а затем запустить $ pipenv graph, чтобы проверить ситуацию.

So when I do that, and run the graph:

➜ metada git: (мастер) ✗ график pipenv
Django == 2.0rc1

• pytz [требуется: любой, установлено: 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: (мастер) ✗ pipenv запустить pip freeze
Django == 2.0rc1
pytz == 2017.3
`` ''

Извините за спам, но я также нашел "обходной путь" моей проблемы. Изначально у меня был установлен трубопровод через brew но я решил переключиться на установку через pip , или, скорее, pip3 через pip3 install --user pipenv .

Эта версия pipenv смогла правильно заблокировать мои Django==2.0rc1 . Я не уверен, действительно ли # 965 связан с этим, но я также видел эту проблему во время работы в Google, поэтому подумал, что упомянул. По сути, то, как одна установка pipenv, кажется, имеет значение, выбирает ли он правильные колеса Python при выполнении установки / блокировки.

Кажется, я решил аналогичную проблему, удалив установку homebrew pipenv и используя стандартную pip3 install pipenv . Я думаю, что мои сообщения об ошибках относятся к зависимостям python 2, которые https://github.com/Homebrew/homebrew-core/blob/master/Formula/pipenv.rb требуют, я ожидаю в предположении собственной установки python2, а не использования преимущества из Python 3, если он доступен. Постараюсь отправить сообщение об ошибке, когда у меня будет время воспроизвести.

это вероятно из-за ограничений setup.py, мы ничего не можем с этим поделать

например, установите pipenv с python3

Homebrew pipenv скоро будет использовать python3 по умолчанию, чтобы избежать подобных вещей.