«upgrade» - это тривиальный псевдоним для «install --upgrade». Нужно подумать еще немного
про «апгрейд-все»; с одной стороны, я предполагаю, что это будет только обновлять пакеты
внутри sys.prefix? (т.е. если вы находитесь внутри virtualenv, он не будет пытаться
обновить глобальные пакеты). Это было бы поводом переехать
UninstallPathSet.can_uninstall () в функцию с более общим названием (или
метод InstallRequirement), поэтому он предоставляет общий вопрос: "Могу ли я прикоснуться к этому?"
решения.

Original Comment By: Carl Meyer

Для протокола, я думаю, что это хорошая идея, учитывая возможность
удалите перед обновлением. Хотя я бы предпочел вариант --all для
upgrade вместо собственной команды upgrade-all .

Что касается can_uninstall (), я согласен ... это, вероятно, удобно, если
в любом случае глобально.

Original Comment By: Jannis Leidel

Я не совсем возражаю против обновления в качестве псевдонима для install --upgrade. Но
это кажется немного тривиальным.

upgrade-all требует, чтобы вы выяснили, что является «обновляемым». Наверное, один
пререквезит состоит в том, что он живет в/lib/pythonX.Y/site-packages
(просто под sys.prefix недостаточно).

Если мы разрешим что-то вроде «zip import» (чтобы принести пакет из родительского
среды в среду virtualenv), то, вероятно, пакеты в этом
родительскую среду не следует обновлять, но не на 100% ясно, что именно
пользователь будет ожидать.

Я попытался удалить редактируемый пакет с помощью "pip uninstall", и он довольно
Разумно предлагалось удалить ссылку .egg и обновить easy-install.pth. Но это
не мог разумно обновить пакет, поэтому can_uninstall несколько
отличается от can_upgrade.

Original Comment By: Ian Bicking

Да, вы правы, что can_uninstall и can_upgrade разные.

Я бы подумал, что если бы у нас был "импорт пипсов", мы все равно не хотели бы обновлять
импортированные глобальные пакеты; но (наряду с редактируемыми) это может стоить "не
обновление этого "предупреждения до консоли.

Original Comment By: Carl Meyer

+1 за эту ошибку

Original Comment By: smyrman

Проблема № 167 отмечена как дубликат этой проблемы.

Original Comment By: Carl Meyer

1

(echo pip; pip freeze | awk 'BEGIN{FS="=="}{print $1}') | xargs sudo pip

установить -U

Это должно обновить все установленные пакеты (включая сам pip). Если
вы запускаете его в virtualenv, вам, вероятно, не нужно использовать sudo.

Конечно, это имеет высокий риск отказа - если обновить один из пакетов
терпит неудачу весь процесс завершится неудачно (это похоже на port upgrade outdated в
MacPorts).

Original Comment By: Tomasz Elendt

+1 за улучшение - все

Почему на данный момент все средства управления модулями Python отстойны? Почему нет
один обеспечивает простое обновление + обновление - команда all?

Original Comment By: Anonymous

Я бы не возражал против реализации, но сначала несколько вопросов.

По общему мнению, новая команда "upgrade", поддерживающая '--all'
возможность добавить в пункт?

Запуск обновления pip должен влиять только на среду, в которой он работает. Если
запустить из виртуального окружения, тогда будут обновлены только пакеты, локальные для этого env;
то же самое для non-virtualenv

Original Comment By: Kelsey Hightower

Келси: из того, что я прочитал вышеупомянутое обсуждение, я не вижу никаких реальных
противодействие этому. Я считаю, что это прекрасное дополнение. Основной крайний случай
редактируемые установки VCS - как предложил Ян, я думаю, что команда "обновить"
не следует их трогать. Определение того, что означает «обновление» в контексте всех
редактируемые возможности (включая установленные локальные репозитории редактируемые, которые не имеют
origin) было бы почти невозможно, я думаю, и даже если бы
определение можно было бы составить, это только увеличило бы содержание
бремя и без того хрупких бэкендов VCS. Но для нередактируемых - выбирайте
Это!

Original Comment By: Carl Meyer

Карл: Круто, я начну и дополню этот тикет результатами.

Original Comment By: Kelsey Hightower

Во время работы над командой обновления возникли следующие вопросы:

• Какие методы следует использовать для поддержки обновления пакетов, чтобы указать, какие пакеты следует
  Обновить? Должны ли мы поддерживать файл требований?
• Как pip upgrade обрабатывать пакеты, которые еще не установлены?
  Стоит ли устанавливать недостающие пакеты?

Варианты использования обновления pip и способы их решения:

# pip upgrade some_installed_package

Try and locate a package that satisfies the requirement. If the

требование не выполнено обновление до запрошенной версии. Это включает в себя
переход на более старую версию.

# pip upgrade --all

Locate all installed packages (non-editables) and update them to a new

версия, если есть.

# pip upgrade some_other_package

Warning: some_other_package not installed, use pip install

some_other_package.

Моя цель - сделать команду обновления очень простой. Вы можете обновить
определенные нередактируемые пакеты для новой или более старой версии; или вы можете обновить
все нередактируемые пакеты до более новой версии.

Мысли?

Original Comment By: Kelsey Hightower

Я думаю, что "pip upgrade" должен быть точным псевдонимом для "pip install --upgrade" как
теперь он работает. Это означает, что да, он устанавливает запрошенные пакеты, если они
не установлены, и да, он принимает файлы требований с -r. Его должен
быть выполнимым практически без нового кода.

Upgrade - всем потребуется код для поиска списка текущих
установленные обновляемые пакеты; тогда он должен просто передать этот список для установки
--upgrade, как указано выше.

Original Comment By: Carl Meyer

Карл, спасибо за ответ. Я в значительной степени пошел по твоему пути
описано. Позже сегодня я смогу опубликовать несколько примеров прогонов.

Original Comment By: Kelsey Hightower

Большая часть кода готова, осталось немного доработать, прежде чем я отправлю код
для рассмотрения.

СДЕЛАТЬ:

• Тесты
• Файл требований к фильтрам; добавить нередактируемые в список пакетов
  Обновить.

Запуск pip с помощью команды обновления

# pip upgrade --all

All packages up-to-date


# pip upgrade --all -v

Packages installed at latest version:

  pip: 0.8.2 (latest)

  distribute: 0.6.14 (latest)

  Python: 2.7.1 (latest)

  wsgiref: 0.1.2 (latest)

All packages up-to-date


# pip upgrade PyYAML

Package updates available:

  PyYAML: N/A (installed) 3.09 (latest)

Downloading/unpacking PyYAML

  Downloading PyYAML-3.09.tar.gz (238Kb): 238Kb downloaded

....

Successfully installed PyYAML

Cleaning up...


# pip upgrade --all -v

Packages installed at latest version:

  pip: 0.8.2 (latest)

  distribute: 0.6.14 (latest)

  PyYAML: 3.09 (latest)

  Python: 2.7.1 (latest)

  wsgiref: 0.1.2 (latest)

All packages up-to-date


# pip upgrade PyYAML==3.08

Downloading/unpacking PyYAML==3.08

....

Successfully installed PyYAML

Cleaning up...


# pip upgrade --all -v

Packages installed at latest version:

  pip: 0.8.2 (latest)

  distribute: 0.6.14 (latest)

  Python: 2.7.1 (latest)

  wsgiref: 0.1.2 (latest)

Package updates available:

  PyYAML: 3.08 (installed) 3.09 (latest)

Downloading/unpacking PyYAML

...

Successfully installed PyYAML

Cleaning up...

  Removing temporary dir /root/upgrade_env/build...

Original Comment By: Kelsey Hightower

Последний набор вопросов (надеюсь):

• Должен ли pip upgrade проанализировать файл требований и отфильтровать
  редактируемые? А как насчет требований к URL?

Для каждого нередактируемого элемента в файле требований я хотел бы проверить
индексы для более поздней версии. Для этого мне нужно собрать
информация о пакете из каждой строки в файле требований.

Любые советы приветствуются (в настоящее время смотрите pip.req.parse_requirements )

• Следует ли pip upgrade искать в индексах более позднюю версию для установки?
  (Это то, чем я сейчас занимаюсь). Если нет, то как команда обновления должна определять
  если есть апгрейд?

Прямо сейчас я добавляю пакеты в список обновлений только в следующих случаях:

• Пакет не установлен
• Доступно обновление (более поздняя версия из индексов), и нет явного
  версия была запрошена
• Запрошенная версия отличается от установленной (Версия отсутствует
  совпадение).
• Я откладываю файл требований команде установки, пока не отфильтрую
  из нередактируемых требований.

Original Comment By: Kelsey Hightower

Карл после перечитывания твоего поста кажется, что я делаю больше, чем
обязательный. Я выложу свою ветку, чтобы вы могли посмотреть. Я мог пойти
за борт, проверив PyPi для более поздней версии.

Original Comment By: Kelsey Hightower

Карл после перечитывания твоего поста кажется, что я делаю больше, чем
обязательный. Я выложу свою ветку, чтобы вы могли посмотреть. Я мог пойти
за борт, проверив PyPi для более поздней версии.

Original Comment By: Kelsey Hightower

Да, похоже, вы делаете больше, чем должно быть. Установка пипа
--upgrade выполняет все, что вы уже обсуждаете (проверяет наличие более новых
версии и т. д.); все "обновление пункта" должно быть похоже на двухстрочный переход
все до pip install --upgrade.

Единственный реальный код, который должен быть написан здесь, - это код для "upgrade --all", чтобы получить
полный список установленных обновляемых пакетов в среде.

Original Comment By: Carl Meyer

Да, я знал это. Что ж, я многому научился. Хотя для этого и не требуется
задача, мне нравится возможность показать, что установлено и доступно во время
процесс обновления (см. тестовый запуск выше).

Я перефактор и уберу вещи. Текущие изменения в моей вилке на
ветка команды обновления.

https://bitbucket.org/khightower/pip/changeset/2bdc202b446c

Original Comment By: Kelsey Hightower

Я удалил команду обновления в соответствии с предложениями Карла (я зашел слишком далеко
на первом месте). Не уверен, что мне нравятся результаты, но зеркальная установка выполняется- обновить функциональность.

Кажется, что pip пытается загрузить и переустановить пакет, даже если
пакет уже установлен и обновлен. Еще хуже с апгрейдом--all , pip переустанавливает все, включая сам pip. Это как пип
апгрейд должен работать? Если так, то я почти закончил :)

Запуск команды обновления pip

# pip upgrade Mako


Downloading/unpacking Mako

  Running setup.py egg_info for package Mako


    warning: no files found matching '*.jpg' under directory 'doc'

    warning: no files found matching '*.sty' under directory 'doc'

    warning: no files found matching 'autohandler' under directory 'doc'

    warning: no files found matching '*.xml' under directory 'examples'

    warning: no files found matching '*.mako' under directory 'examples'

    warning: no files found matching '*.dat' under directory 'test'

    warning: no files found matching 'ez_setup.py'

Downloading/unpacking MarkupSafe>=0.9.2 (from Mako)

  Running setup.py egg_info for package MarkupSafe


Installing collected packages: Mako, MarkupSafe

  Found existing installation: Mako 0.3.6

    Uninstalling Mako:

      Successfully uninstalled Mako

  Running setup.py install for Mako

    changing mode of build/scripts-2.7/mako-render from 644 to 755


    warning: no files found matching '*.jpg' under directory 'doc'

    warning: no files found matching '*.sty' under directory 'doc'

    warning: no files found matching 'autohandler' under directory 'doc'

    warning: no files found matching '*.xml' under directory 'examples'

    warning: no files found matching '*.mako' under directory 'examples'

    warning: no files found matching '*.dat' under directory 'test'

    warning: no files found matching 'ez_setup.py'

    changing mode of /root/upgrade_env/bin/mako-render to 755

  Found existing installation: MarkupSafe 0.11

    Uninstalling MarkupSafe:

      Successfully uninstalled MarkupSafe

  Running setup.py install for MarkupSafe


    building 'markupsafe._speedups' extension

    gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall

-Wstrict-prototypes -fPIC -I / opt / OpenPython-2.7.1 / include / python2.7 -c
markupsafe / _speedups.c -o build / temp.linux-x86_64-2.7 / markupsafe / _speedups.o

    gcc -pthread -shared

сборка / temp.linux-x86_64-2.7 / markupsafe / _speedups.o -o
сборка / lib.linux-x86_64-2.7 / markupsafe / _speedups.so

Successfully installed Mako MarkupSafe

Cleaning up...

Original Comment By: Kelsey Hightower

Келси - Да, есть ошибки с install --upgrade; в частности вы
определили № 13 , что он повторно загружает и переустанавливает даже пакеты, которые
уже обновлены. Решение не в том, чтобы делать что-то другое
с новой командой обновления она исправляет ошибку в install --upgrade.

С upgrade --all мне кажется разумным, что pip обновится сам
тоже, если доступно обновление. (Лично я никогда не буду использовать апгрейд
- все, поэтому я не знаю, какого поведения люди, которые будут его использовать, хотели бы от него
здесь). Очевидно, опять же, было бы лучше, если бы № 13 был исправлен.

Original Comment By: Carl Meyer

Спасибо, Карл, я завершу это и начну смотреть на №13.

Original Comment By: Kelsey Hightower

Если у кого-то есть время, пожалуйста, просмотрите мою ветку команды обновления. А пока
Я буду работать над юнит-тестами, которые стараются не дублировать существующие для
установить команду.

https://bitbucket.org/khightower/pip/src/fa7b2a6d2bf1/pip/commands/upgrade.py

Original Comment By: Kelsey Hightower

@vababiy : я пробовал вашу команду обновления, но она работает некорректно ... Итак, я сделал собственную:

https://github.com/pypa/pip/pull/313
https://github.com/jedie/pip/commit/7a31d70dabe0e809184fe1b5280c5a7ccf420dd5

@jedie, я думаю, вы хотели направить свой комментарий на @khightower. @vbabiy перенесла сюда свой комментарий, но не написала команду обновления.

+1

@kelseyhightower Есть прогресс?

+1

+1!

+1

+1

Пожалуйста, прекратите комментировать проблему, поставив только «+1». Мы знаем, что эта функция востребована, но спам в нашем почтовом ящике не помогает.

Вместо этого я был бы рад увидеть комментарий «патч готов!» ;)

+1

Любые обновления? Есть ли планы добавить это, ему уже 3 года ..

@pradyun См. https://github.com/pypa/pip/issues/59#issuecomment -9418336

+1

Я думал, это уже слили. Я могу стряхнуть пыль со своих навыков питона и попробовать еще раз.

Будет ли эта функция включена в 1.5? Не могу найти ссылки на него в документации 1.5 ...

+1

Каков статус этой проблемы?

Заблокирован # 988

Если это действительно важно для вас, есть обходные пути для обновления всех пакетов; Я собрал сценарий, чтобы сделать это параллельно (https://github.com/ariccio/update-pip-packages), и есть много других реализаций в других местах в Интернете.

Этот вопрос состоит из двух частей. upgrade-all может быть заблокирован gh-988, но я не вижу, как блокируется upgrade . pip upgrade может быть простым псевдонимом для pip install -U --no-deps . Это решит одну из основных проблем использования install_requires в файлах setup.py. Разве это не может быть сделано когда-нибудь в ближайшее время?

pip upgrade может быть простым псевдонимом для pip install -U --no-deps

из описания:

pip upgrade будет похоже на pip install --upgrade но по умолчанию будет нерекурсивным (и предложит вариант --recursive ). Это текущее рекурсивное поведение по умолчанию многих огорчило (# 304). Что касается того, как сейчас делать нерекурсивные обновления, см. Здесь

это не pip install -U --no-deps

«Нерекурсивный» в этом контексте не означает просто –no-deps . При нерекурсивном обновлении зависимости обновляются, но только если это необходимо для выполнения родительских требований.

@qwcode спасибо за разъяснения. Тогда меня это не волнует. Почему вы назвали это «нерекурсивным», оно все еще рекурсивно, но только немного умнее / отличается?

Из обсуждения в gh-571 у меня сложилось впечатление, что желаемое значение по умолчанию - действительно нерекурсивное. Это, безусловно, имело бы смысл и избавило бы от необходимости всегда писать код вроде https://github.com/scipy/scipy/commit/8e7ee0c4b3c16.

в # 571 «нерекурсивный» - это не --no-deps это «умнее / другое» рекурсивное, как вы говорите.
обратите внимание на тест test_upgrade_with_needed_recursive_upgrades() из этого PR.

не зацикливаясь на терминах, есть 3 вещи:

1. «более разумное / другое обновление», то есть такое, которое происходит в пакете ОС, которое также может подразумевать обновление зависимостей (но только если они действительно _ нуждаются_ в обновлении).
2. что теперь делает pip, то есть обновляет все зависимости, независимо от необходимости или разрешения конфликтов.
3. --no-deps

несколько возможных способов отличить №1 от №2

1. "нерекурсивный" vs "рекурсивный"
2. "нормальный" vs "рекурсивный"
3. "только если необходимо рекурсивно" vs "делать это независимо от рекурсии"

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

Думаю, мне нравится эта фраза «рекурсивная только в случае необходимости». возможно, мне стоит использовать это здесь, в документации:

Мне тоже это нравится. Если бы вы описали все три варианта вместе как

a. non-recursive
b. only if needed recursive
c. recursive (or "do it regardless recursive")

это было бы ясно.

Затем вы хотите выбрать хорошие значения по умолчанию. И для upgrade и для install -U может иметь смысл либо (a), либо (b). Я сильно предпочитаю (а), но (б) тоже имеет смысл, учитывая то, что делает упаковка ОС.

(c) по умолчанию не имеет смысла, поэтому пересмотрите свое решение не менять install -U .

Чтобы прояснить, почему я решительно предпочитаю (а): ничего не подозревающий пользователь, желающий (б) и получающий (а), должен будет прочитать сообщение "non-recursive upgrade can't satisfy all dependencies, please use only-if-needed recursive" , что не так уж и важно. Если по умолчанию будет (b), этот ничего не подозревающий пользователь может в конечном итоге получить обновление или даже прервать установку пакета, к которому он действительно не хотел прикасаться. Чтобы оправиться от этого, могут потребоваться часы или даже дни.

(c) не имеет смысла по умолчанию, поэтому пересмотрите свое решение не изменять install -U

Причина, по которой оставить install -U покое, - это просто из соображений совместимости, а затем для того, чтобы в конечном итоге отказаться от него.

Если по умолчанию будет (b), ничего не подозревающий пользователь может в конечном итоге выполнить обновление.
или даже неработающая установка пакета, которого он действительно не хотел трогать

если пользователь хочет, чтобы необходимые обновления зависимостей оставались невыполненными, он должен специально запросить это, используя --no-deps . Я не думаю, что это когда-либо могло быть по умолчанию. такое поведение нанесет больше вреда, чем вы рассматриваете (что является исключением). Снова и снова пользователи останутся без необходимых обновлений зависимостей.

Устарение install -U звучит хорошо.

Я согласен (б) встречается чаще, чем (а). Даже если бы это было в 100 раз чаще, что, я думаю, не так, больший ущерб не соответствует действительности. Чтение четкого сообщения об ошибке перед началом установки намного лучше, чем, например, ошибка компиляции на полпути, что imho (a) по-прежнему является лучшим вариантом по умолчанию.

Полагаться на --no-deps может быть нормально для очень опытных пользователей, но новые пользователи узнают об этом только после того, как что-то пойдет не так.

В любом случае, похоже, я не смогу вас убедить. Затем вернемся к руководству

try:
   import dependency
except ImportError:
    install_requires.append('dependency')
else:
    if dependency.version < 'x.y.z':
        raise ValueError('Please upgrade dependency to x.y.z')

Это.

@qwcode спасибо за подробное объяснение. Я надеюсь, что в ближайшем будущем это будет продвигаться вперед - только в случае необходимости рекурсивный метод будет огромным улучшением по сравнению с текущим поведением.

Снова потратив на этой неделе много часов на обсуждение вопросов, почему мы не используем install_requires , я добавляю: +1: для отхода от текущего поведения.

Есть ли обновления по этой проблеме?

У нас 2015 год, и мне все еще нужно скопировать из pip freeze --local | grep -v '^\-e' | cut -d = -f 1 | xargs -n1 pip install -U stackoverflow

Да, по сути, весь прогресс связан с этим вопросом.

GitHub неплохо справляется с перекрестными ссылками. Все они кликабельны! (Я уверен, ты это знаешь?)

Да, конечно, но я не понимаю, почему эта "простая" функция имеет такую ​​задержку.

Что является причиной этого?

Am 16.04.2015 um 05:28 schrieb Alexander Riccio [email protected] :

Да, по сути, весь прогресс связан с этим вопросом.

GitHub неплохо справляется с перекрестными ссылками. Все они кликабельны! (Я уверен, ты это знаешь?)

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Что касается pip upgrade-all , похоже, что консенсус состоит в том, чтобы дождаться работы, связанной с # 988, прежде чем выпускать какие-либо блестящие новые команды, которые все еще в конечном итоге ошибочны и могут быть опасны для рабочей среды. Простая версия upgrade-all , которая неправильно выполняет требования, может легко сломать существующие пакеты.

+1

Чем ты занимаешься 4 года?

+1

+1

+1

@muhasturk В настоящее время жду ... https://github.com/pypa/pip/issues/59#issuecomment -93646462

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 ... извините за спам, но запускать pip freeze --local | grep -v '^\-e' | cut -d = -f 1 | xargs -n1 pip install -U больно!

+1

Если кто-то заинтересован в работе над этим, я думаю, что приведенные выше комментарии несколько сбивают с толку - AFAICT фактический статус таков, что pip upgrade-all в настоящее время заблокирован необходимостью правильной системы разрешения зависимостей, но pip upgrade может быть реализовано в любое время. Если кто-то захочет поработать над этой частью, это будет очень круто :-).

(См. Также ветку, начинающуюся здесь, и ответ @dstufft здесь, и комментарий здесь, согласный с приведенной выше оценкой.)

вот еще одно обсуждение из списка pypa-dev год назад (который согласен с тем, что pip upgrade FOO можно сделать сейчас) https://groups.google.com/forum/#!searchin/pypa -dev / pip $ 20 обновление / pypa-dev / vVLmo1PevTg / oBkHCPBLb9YJ

Спасибо @qwcode! Я также только что увидел новое описание на https://pip.pypa.io/en/latest/user_guide/#only -if-required-recursive-upgrade, это полезно.

+1

Если я не ошибаюсь:

Если xxx не установлен:

• pip upgrade xxx будет эквивалентно pip install xxx
• pip upgrade xxx --recursive будет эквивалентом pip install xxx --upgrade

Если установлен xxx:

• pip upgrade xxx --recursive прежнему будет эквивалентом pip install xxx --upgrade (по замыслу)
• но в настоящее время нет эквивалента для pip upgrade xxx , это может быть pip install xxx --upgrade-only-if-needed/--upgrade-lazy

Непонятно, какова добавленная стоимость новой команды по сравнению с добавлением новой опции в pip install ?

Непонятно, какова добавленная стоимость новой команды по сравнению с добавлением новой опции в pip install ?

Поведение по умолчанию pip install -U неприемлемо для многих проектов. См. Мой комментарий выше (https://github.com/pypa/pip/issues/59#issuecomment-52434862). А вот более подробное объяснение: http://article.gmane.org/gmane.comp.python.distutils.devel/24218

Если это неприемлемо, то я предполагаю, что вы планируете изменить использование pip install --upgrade на pip upgrade?
Почему вы не могли вместо этого изменить текущее использование pip install --upgrade на pip install --upgrade-only-required?
Что дает новая команда, чего не может дать новая опция?

Это все мощеные коровьи тропы. Его беспокоит не личное использование

Верно. Люди не читают документы. Действительно, мы исправим все документы по установке, которые сможем найти, но как только пользователь увидит -U или --upgrade , он воспользуется этим. Вероятность того, что люди будут использовать --no-deps или --only-as-needed или что-то еще до того, как их серьезно укусит, очень мала.

Почему вы не могли вместо этого изменить текущее использование pip install --upgrade на pip install --upgrade-only-required?

И для ясности: мы избегаем pip install --upgrade сейчас _и_ из-за этого не используем install_requires . Вот как это плохо.

Я думаю, здесь есть небольшое недоразумение - IIUC @xavfernandez соглашается с добавлением функции нерекурсивного обновления, их вопрос заключается в том, почему пользовательский интерфейс для этой функции должен быть новой командой верхнего уровня, а не новой опцией для pip install .

@xavfernandez : Обратите внимание, что в настоящее время в # 3194 обсуждается вопрос о том, какой пользовательский интерфейс будет наиболее понятным для этой функции.

(И pip install -U будет объявлено устаревшим, а затем удалено, так что это отвечает на вопрос о том, как пользователи узнают, что его не использовать :-).)

Я думаю тут небольшое недоразумение

Я почти уверен, что это не так. И да, мы обсуждаем только UI. Но это важно.

Да, обсуждают только UI, и я согласен, что это важно. Но я предвижу, что после выхода обновления pip не будет причин продолжать использовать pip install ...
И пользовательский интерфейс для установки любого пакета станет "pip upgrade foo"

не будет причин продолжать использовать pip install

в чем проблема, почему? Проблема (по крайней мере, для @qwcode в комментариях выше) с изменением pip install --upgrade на правильное поведение нарушает обратную совместимость. Итак, pip upgrade - это способ избежать этого перерыва _и_ получить правильное значение по умолчанию.

@rgommers : если честно, мы _will_ получим некоторое ненулевое количество запутанных вопросов о том, почему вы сказали мне запустить pip upgrade foo когда у меня даже не установлен foo , это не так не работает (спорите взад и вперед, пока они на самом деле не попробуют запустить команду вместо того, чтобы предполагать, что она не сработает, и делать вид, что они ее выполнили)

На # 3194 я сделал комментарий, что, возможно, правильный путь вперед - просто удалить --upgrade из pip install , сделать так, чтобы pip install всегда выполнял обновление явно названных элементов и по умолчанию к стратегии минимального обновления для зависимостей с флагом --recursive чтобы получить текущее поведение при обновлении.

Я думаю, я согласен с тем, что с # 3194 UX по умолчанию станет pip upgrade foo вместо pip install [-U] foo . Единственная проблема, с которой я сталкиваюсь, это то, что я думаю, что наличие двух команд немного сбивает с толку, и, учитывая, что я думаю, что pip upgrade будет "правильным" для людей, я думаю, что это неприятно иметь очевидное имя быть неправильным именем.

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

Что ж, я не буду спорить, что обратная совместимость здесь важна. Я всегда был за изменение поведения pip install --upgrade . Он самый чистый, а стоимость кажется небольшой. Но мне показалось, что @qwcode наложил на него вето, поэтому pip upgrade был следующим лучшим решением (и уже одобрено разработчиками pip год назад).

Если мы теперь хотим вернуться к изменению значений по умолчанию / поведения для pip install , отлично.

@dstufft, который для меня имеет смысл - головная боль не может быть такой уж плохой :)

Поскольку мы согласны отказаться от --upgrade, мы могли бы сохранить это и добавить два параметра для установки pip: --upgrade-only-required и --upgrade-eager, причем второй является псевдонимом для устаревшего --upgrade

@xavfernandez Я думаю, что неприятное занятие . Если я не разбираюсь в довольно тонких проблемах, я не уверен, что действительно знаю, хочу ли я --upgrade-only-needed и --upgrade-eager .

@xavfernandez, значит, вы предлагаете, чтобы в финальной ситуации команда была бы pip install --upgrade-only-needed ? Выглядит некрасиво.

Было бы гораздо лучше иметь что-то, что соответствует эквиваленту закрепления семантической версии, доступному, например, в npm , hex или Cargo . Это, безусловно, потребует корректировки в контексте Python, поскольку (а) версии PEP 440 не соответствуют и не могут точно соответствовать семантическому управлению версиями и (б) сообщество Python в целом не обязательно придерживается семантического управления версиями в своих выпусках даже внутри PEP 440.

Тем не менее, что-то в этом роде было бы очень полезно, как и идея закрепления указанной версии.

Учитывая ограничения, в краткосрочной перспективе один жизнеспособный вариант может делать что-то аналогичное командам homebrew upgrade и upgrade --all , где последняя просто выполняет обновление всего (возможно, с предупреждением в первый раз). ).

Однако в долгосрочной перспективе было бы чрезвычайно полезно создать общие соглашения о том, что означают версии в сообществе разработчиков Python, и создание поддержки pip вокруг этого могло бы стать большой частью этого.

Очевидный путь миграции:

версия пункта X:

• добавить параметры pip install --eager , pip install --no-eager , где --eager означает, что для требований без ограничения версии мы пытаемся установить последнюю версию, даже если уже установлена ​​какая-то версия, и --no-eager означает, что мы довольны, если установлена ​​какая-либо версия
• также добавьте опцию pip install --eager-recursive с текущей семантикой -U
• --no-eager остается значением по умолчанию
• если ни один из этих параметров не указан, и pip install передано требование без прикрепленного номера версии, и это требование уже выполнено, вывести предупреждение о том, что мы не обновляли ваш пакет, но в будущем мы будем, поэтому вы должны использовать --no-eager если хотите сохранить текущее поведение
• добавить предупреждение об устаревании для pip install -U направляющих людей в pip install --eager-recursive

версия пункта Y:

• измените значение по умолчанию для pip install на --eager

версия пункта Z:

• удалить pip install -U

Я сделал разные версии Y и Z, потому что мне не терпится получить --eager так что, возможно, мы могли бы внести это изменение в более агрессивный график, сохраняя при этом pip install -U на некоторое время, так как много документации уже упоминается к нему, и это не причинит никакого вреда. Но очевидно, что Y = Z - это вариант :-)

@chriskrycho : Звучит

Абсолютно; Моя точка зрения (которую, как я теперь понимаю, я совершенно не смог выразить!) заключалась в том, чтобы просто отметить, что любое решение, принятое здесь, не должно противоречить принятию такого рода курса в будущем.

Каков обычный путь прекращения поддержки для pip? На основе времени / версии? Через какое время до удаления что-то должно быть устаревшим?

Кстати, я думаю, что «нетерпеливый» - это слово, которое пользователи не поймут. рекурсивный / только по мере необходимости рекурсивный / всегда рекурсивный намного понятнее.

Обычно мы проводим цикл прекращения поддержки двух версий.

Я предполагаю основные версии? Минорные версии действительно быстрые (7.0 -> 7.1 был один месяц). Обычно между основными версиями проходит полгода, поэтому 1 год предупреждений об устаревании?

Ага, извини. Основные версии. Если мы что-то осуждаем в 8.x, это будет желтое предупреждение для остальной части 8.x, красное предупреждение для всех 9.x и удаленное в 10.x.

Спасибо.

Копирование комментария @dstufft «сек из https://github.com/pypa/pip/pull/3194#issuecomment -152357835 здесь, потому что это лучшее резюме ситуации:

Думаю, дело в том, что я полностью считаю, что нам нужно исправить поведение "по умолчанию", нам просто нужно выбрать конкретную реализацию его исправления:

1. Оставьте UX be pip install --upgrade и измените значение по умолчанию.
2. Переместите UX в pip upgrade с «правильным» значением по умолчанию и добавьте флаг --recursive.
3. Переместите UX в pip install, удалите --upgrade и добавьте флаг --recursive.

Мой 2с:

(1) имеет хороший UX, можно сделать сейчас
(2) немного худший UX (есть и install и upgrade ), можно сделать сейчас
(3) второй лучший UX, изменение pip install можно сделать сейчас, удаление --upgrade будет выполнено только в 10.0 (устарело в 8.0 и 9.0).

Я не понимаю, почему проблема обратной совместимости (которая в любом случае должна быть незначительной) для (1) будет хуже, чем для (3). Итак, (1) кажется лучшим. Если вас действительно беспокоит совместимость ч / б, выберите (2).

В любом случае, пора закончить ночь.

Я думаю, что разница между (3) и (1) сводится к тому, думаем ли мы, что установка или обновление является наиболее распространенной операцией, которую хотят люди, - в таком случае лучше всего использовать короткую команду, как в (3). В любом случае это не имеет большого значения.

Кстати, я думаю, что «нетерпеливый» - это слово, которое пользователи не поймут. рекурсивный / только по мере необходимости рекурсивный / всегда рекурсивный намного понятнее.

Я совершенно не привязан к написанию «нетерпеливое», но слово «рекурсивный» просто не имеет смысла в качестве основного слова для включения и выключения обновлений. Я предполагаю, что мы могли бы использовать --upgrade-non-recursive (по умолчанию в будущем), --upgrade-recursive , --upgrade-none или около того, но это все еще выводит на первый план запутанное рекурсивное поведение (я бы понятия не имел, что --upgrade-non-recursive означало, что если я еще не был знаком со странным рекурсивным поведением устаревшей опции -U), а --upgrade-none вводит в заблуждение, как будто это гарантирует, что никакие пакеты не будут обновлены, даже если это необходимо для сохранения себя последовательность.

Если мы пойдем по этому пути, то мне наплевать на период написания, поскольку вариант, который хочет большинство людей, будет просто значением по умолчанию, а варианты рекурсивного обновления и без обновления будут особенными, редко используемыми вещами, которые большинство пользователей мог игнорировать.

--upgrade-non-recursive (по умолчанию в будущем) ...

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

Я думаю, что разница между (3) и (1) сводится к тому, думаем ли мы, что установка или обновление является наиболее распространенной операцией, которую хотят люди.

Я ожидал «установить». По крайней мере, я знаю, что обновляю только те пакеты, которые интенсивно использую специально, но каждый раз, когда я вижу что-то интересное / полезное, это просто pip install pkgname .

(не то чтобы я типичный пользователь, поэтому мои ожидания могут быть неверными)

Думаю, я был бы за:

• Нет нового pip upgrade которое было бы псевдонимом для pip install
• pip install (без опции --upgrade* ) поведение не меняется
• pip install --some_name будет пытаться обновить только пакеты, указанные в командной строке, а не их зависимости
• pip install --some_other_name чтобы сохранить старое поведение --upgrade доступным

И тут есть два варианта:

• нам не нужен / не нужен путь устаревания, тогда --some_name может быть --upgrade а --some_other_name может быть любым, что кажется лучшим
• нам нужен путь устаревания, тогда --upgrade в pip8 выдаст предупреждение о том, что он устарел, и мы должны использовать --some_other_name чтобы сохранить старое поведение или, скорее, переключиться на более безопасный --some_name только при необходимости обновлять указанные пакеты и их зависимости.

Во втором случае --some_name не может быть --upgrade . Итак, нам нужно найти два новых имени опций для --some_name и --some_other_name

Мне кажется, что очевидное «лучшее» решение - оставить pip install в качестве команды и изменить поведение --upgrade чтобы не обновлять зависимости. Единственная реальная проблема - обратная совместимость, но были ли у нас какие-либо пользователи, утверждающие, что они полагаются на текущее поведение?

Лично я склоняюсь к точке зрения «дерзай и черт возьми с обратной совместимостью». Я мог бы возразить, что текущее поведение на самом деле является ошибкой, и это изменение будет исправлением. Но я действительно думаю, что в какой-то момент нам нужно иметь возможность сказать, что мы достигли хорошей точки, и мы собираемся принять гораздо более строгий взгляд на обратную совместимость. Я не думаю, что мы еще на этом этапе, но нам, возможно, придется дать сообществу знать, что, по нашему мнению, еще нужно сделать, чтобы добраться до этого момента.

По-прежнему (ИМО) существует необходимость в какой-то команде pip install --upgrade :all: для обновления всех установленных пакетов. Но это новая функция, поэтому здесь она не актуальна.

Текущее поведение _is_ полезно, особенно для таких проектов, как Pyramid, которые не являются единым проектом, а фактически представляют собой набор проектов. Было бы полезно иметь возможность сделать что-то вроде pip install --upgrade-recursive Pyramid , чтобы обновить Pyramid и все его зависимости до последней версии. Удаление рекурсивной вещи вместе означает, что мне нужно либо вручную отслеживать все зависимости и делать pip install --upgrade Pyramid dep1 dep2 dep3 dep4 (со всем деревом зависимостей), либо мне нужно сделать гипотетический pip install --upgrade :all: и, возможно, обновить больше вещи, которые я действительно хочу обновить. В # 3194 по крайней мере один пользователь упомянул, что он хотел бы, чтобы текущее поведение было доступно через флаг, потому что это полезно в некоторых случаях.

Есть ли какая-либо причина (кроме обратной совместимости) не делать так, чтобы pip install неявно выполнял «минимальное» обновление? Я пытаюсь выяснить, в какой ситуации я бы на самом деле хотел, чтобы он только устанавливался, а не выполнял обновление (IOW, тот, где последняя версия в порядке, если она еще не установлена, но не, если она у меня есть установлен), и у меня возникла проблема с тем, что я хотел бы иметь текущее поведение.

Мне нравится идея команды _new_ pip upgrade [--recursive] как в # 3194 (и не рекомендуется install --upgrade )

У меня есть опасения по поводу любого выбора, который нарушает совместимость, имеет сложную устаревшую версию или обременяет и без того сложную pip install дополнительными изменениями или сложностью. Кроме того, меня лично привлекает команда «обновить», которая по умолчанию просто выполняет обновления, аналогично тому, как работают инструменты дистрибутива. "установить" устанавливает и "обновляет" обновления ...

Я склоняюсь к точке зрения "дерзай и черт возьми, с обратной совместимостью"

Я не :) по крайней мере для такой базовой логики.

сделайте так, чтобы pip install неявно выполнял "минимальное" обновление

для меня, учитывая, что это кажется неудачным, не так ли? примите во внимание количество возможных поломок автоматизированной сборки. кроме того, люди в определенный момент замыкаются в концептуальной модели того, что такое pip install ... и это вынуждает перезагрузить новую ментальную модель. людям это не нравится.

@qwcode Не знаю, не думаю, что все будет в порядке. Основная проблема с pip upgrade заключается в том, что либо вы убираете способ, которым люди говорят: «Дайте мне последнюю версию, независимо от того, установлена ​​она или нет», либо у вас есть две команды, которые делают почти одно и то же ( pip install и pip upgrade ). В краткосрочной перспективе может произойти некоторая поломка, но меня немного беспокоит реальная ментальная модель pip upgrade потому что я вижу, что люди просто широко меняют свои инструкции по установке с pip install foo на pip upgrade foo (но почему я обновляю то, чего еще не установил ?!).

Я думаю, что все будет в порядке.

широко распространены замены их инструкций по установке pip install foo на pip upgrade foo

Роджер, поэтому я думаю, что upgrade нужно просто обновить. что касается "какашки" --fill-in-missing , я не зацикливаюсь на этом, так что не думайте, что я должен это иметь, но см. ниже.

"дайте мне последнюю версию, независимо от того, установлена ​​она или нет"

• если у меня нет FOO , то я pip install FOO и получаю последнюю версию.
• если у меня FOO , то pip upgrade FOO и я получаю последнюю версию.

Думаю, речь идет о 2 случаях:

1. Я не знаю , есть ли у меня FOO , и я хочу, чтобы команда _one_ получила последнюю FOO , есть она у меня или нет.
2. Я хочу, чтобы команда _one_ получила последние из FOO и BAR . У меня установлено FOO , но не BAR .

Обязаны ли мы пользователям _one_ команда за это? Я бы предпочел простоту и ясность команд, чем давать людям ярлыки. Но если пользователи потребуют этого, тогда на --fill-in-missing придет что-то вроде

Кроме того, меня лично привлекает команда «обновить», которая по умолчанию просто выполняет обновления, аналогично тому, как работают инструменты дистрибутива. "установить" устанавливает и "обновляет" обновления ...

Уточнение: я только что проверил, как работают три популярных инструмента дистрибутива, и AFAICT (частично это основано на страницах руководства b / c, я не использую все это сам):

• apt:
  
  
  
  • apt install <pkg> выполняет «апсталляцию» - либо обновляет, либо устанавливает, в зависимости от того, установлен он уже или нет.
  
  
  • apt upgrade обновляет все установленные пакеты
  
  
  • apt upgrade <pkg> не существует, единственный способ обновить один пакет - apt install <pkg> (который также принимает различные типы спецификаторов версии)
  
  
• ням:
  
  
  
  • yum install <pkg> выполняет «апсталяцию»
  
  
  • yum upgrade обновляет все установленные пакеты
  
  
  • yum upgrade <pkg> обновляет указанный список пакетов. Я не знаю, что произойдет, если они еще не установлены.
  
  
• домашнее пиво:
  
  
  
  • brew install <pkg> выполняет «апсталяцию»
  
  
  • brew upgrade обновляет все пакеты
  
  
  • brew upgrade <pkg> обновляет указанный список пакетов. Я не знаю, что произойдет, если они еще не установлены.
  
  

Таким образом, использование установки для обновлений - это на самом деле то, что делают инструменты дистрибутива :-). Это не значит, что мы тоже должны это делать; просто точка данных.

Я не знаю, есть ли у меня FOO, и я хочу, чтобы одна команда получила последнюю версию FOO, независимо от того, есть она у меня или нет.

Я думаю, что наиболее убедительный пример использования этого метода находится в документации. Пример: документы django, которые я связал в другом потоке, которые инструктируют людей запускать pip install -U <some package> . Вы не хотите говорить людям: «Запустите pip install <pkg> за исключением случаев, когда он у вас уже установлен, запустите pip upgrade <pkg> », потому что это слишком запутанно для новичков, но если install не делает ' Если вы просто скажете людям запустить pip install <pkg> это также создаст путаницу, когда люди начнут работать с вашим учебником с установленной старой версией, а затем не поймут, почему что-то не работает, и обвинят вас в этом. Так что вам определенно понадобится одна команда «upstall», и она должна быть простой и очевидной для включения в документацию.

Продолжение поведения Homebrew для сравнения: brew upgrade не работает, если вы пытаетесь установить неустановленный пакет:

$ brew upgrade git
Error: No such file or directory - /usr/local/Cellar/git

Также меняется текущее поведение brew upgrade (см. Обсуждение здесь ); в будущем выпуске он переключится на требование --all для обновления всех установленных пакетов.

Уточнение

Я знал, что кто-нибудь это заметит. :)
Я почти ответил сам себе. Я был сосредоточен на обновлениях.

ням апгрейд[...] Я не знаю, что произойдет, если они еще не установлены.

это ничего не делает

ням установитьвыполняет «апсталляцию»

true, но по умолчанию запрашивается подтверждение, чего нет у пипса.

документы django, которые я связал в другом потоке

Чтобы было ясно, это не были настоящие документы Django. в документах Django написано pip install Django (https://docs.djangoproject.com/en/1.8/topics/install/)

На самом деле, я думаю, учитывая то, как сейчас работает -U , заставлять людей привыкать использовать install -U .

в вашем связанном примере это было для redis которое, я думаю, не имеет никаких зависимостей, так что в этом случае это нормально.

создаст путаницу, когда люди начнут работать с вашим учебником
со старой версией [...] Так что вам определенно понадобится одна команда "upstall"

IDK, для меня не так очевидно, что учебные пособия должны подсказывать людям, что нужно выполнить установку в целом. Если кто-то делает учебник для FOO, и у него уже установлен FOO, то, возможно, им не следует слепо «устанавливать» ... может быть, обновление повредит существующее окружение.

Я думаю, что учебные пособия должны побуждать людей «установить» (отличный термин!), Потому что значительное количество из них написано самими проектами, и когда люди идут смотреть учебные пособия, они редко сначала смотрят, какую существующую версию FOO они установили, скорее они смотрят все, что есть в последней документации.

Я также согласен с тем, что способ -U настоящее время работает, это плохая привычка заставлять людей использовать его без разбора, но ключевым моментом, на мой взгляд, является предлагаемое поведение, которое я не считаю плохой привычкой , но это хорошее дело. Если вам нужно убедиться, что установлена ​​определенная версия, вы уже должны использовать == и мы можем добавить флаг, который превратит стандартную «установку» обратно в обычную «установку» для людей, которым необходимо убедиться, что установленная в настоящее время версия ИЛИ установлена ​​последняя версия (хотя я все еще не могу придумать сценарий, в котором это действительно то, что кому-то нужно).

Я думаю, что в руководствах людям следует «установить»

опять же, что это за среда, в которой они находятся, где, очевидно, можно обновить? Если это среда Python для дистрибутива, то, конечно же, нет. Если это какая-то другая среда, созданная для приложения, то установка обновления может быть опасной. если это среда, которую они только что создали для учебника, то им не нужно обновляться.

Ключевым моментом здесь является то, что PyPI не является «курируемым» репозиторием, в отличие от репозиториев дистрибутива. вы можете быть уверены в том, что "upstall" безопасен из репозитория дистрибутива по умолчанию ... вы не знаете этого с PyPI. Каждое обновление - это своего рода авантюра. "install" как таковое является консервативным.

имейте в виду, что если заставить pip install действовать как "апстаил" без исправления # 988, это все сломает.

подумайте, где установлены A и B , а для A требуется B<2 . Теперь я запускаю новый pip install B , который обновляет B до версии v3 или чего-то еще (из-за того, что не учтены установленные ограничения), и теперь моя среда остановлена.

для людей, которым необходимо убедиться, что установлена ​​текущая установленная версия ИЛИ последняя версия (хотя я все еще не могу придумать сценарий, в котором это действительно то, что кто-то хочет).

Придумывать такие сценарии - нетрудно. Пример (к сожалению, не придуманный): в настоящее время statsmodels нарушается последним pandas (0.17.0). Я пользуюсь и тем, и другим. У меня установлено несколько версий Python и валяются venvs. Итак, я знаю, что для любого Python / venv я бы хотел установить pandas только если его еще нет. Если это так, у меня, вероятно, также будет statsmodels и тогда "upstall" сломает его.

@rgommers Хм, значит, вы абсолютно уверены, что у вас нигде нет панды 0.17.0 в виртуальной среде? Я предполагаю, что это может произойти, хотя я думаю, что, вероятно, произнесу это, выполнив pip install pandas!=0.17.0 или pip install pandas<0.17 но я думаю, что не совсем необоснованно полагаться на то, что вы уже установили.

Хм, так вы абсолютно уверены, что у вас нигде нет панды 0.17.0 в виртуальной среде?

Я не это сказал. У меня есть venv с пандами 0.17.0, только один, в котором у меня нет статистических моделей. pip install pandas<0.17 выполнит эту работу, но мне не пришло в голову использовать это (в основном потому, что мне это не нужно, текущая команда install работает для этой цели).

В любом случае, я не особо предпочитаю или против апсталляций. Я просто хотел указать на реалистичный сценарий, когда вы сказали, что не можете его придумать.

+1

Это обсуждение, кажется, застопорилось, так и не пришло к выводу. Любой вариант в таблице - серьезное улучшение текущего статуса. Похоже, все соответствующие плюсы и минусы были учтены; есть только разница во мнениях об относительной важности обратной совместимости по сравнению с оптимальным API. Может быть, разработчики пипса могут попытаться окончательно принять решение?

@rgommers они наверное решение сделали? https://pip.pypa.io/en/stable/user_guide/#only -if-required-recursive-upgrade

@rgommers они наверное решение сделали? https://pip.pypa.io/en/stable/user_guide/#only -if-required-recursive-upgrade

@ Liso77, спасибо, но нет - это действительно обсуждение этой темы, которое требует завершения. Документация, на которую вы ссылались, просто указывает сюда.

@rgommers из ссылки, которую я разместил выше, я прочитал, что разработчики собираются сделать команду обновления. И не планируйте добавлять опцию «только при необходимости» в команду установки, потому что они не создали термин для этой опции и используют только описание в кавычках. Итак, из вашего (или dstuff) комментария от 30 октября - это: _2. Переместите UX на обновление pip с "правильным" значением по умолчанию ..._ (кстати, я предпочитаю это)
Я уверен, что вы больше думали об этой теме и видите более тонкие вещи, чем я. Так что напишите, пожалуйста, что (если вы думаете, что что-то) еще открыто. Если вы имели в виду, что было бы хорошо, если бы разработчики прямо написали здесь свое решение и в конечном итоге закрыли эту проблему - я согласен.

Кстати. ситуация могла бы быть намного менее проблемной, если бы у нас было что-то вроде

pip freeze > checkpoint.txt
pip checkout checkpoint.txt

что могло гарантировать возврат установки к любой «контрольной точке». (pip install -r в данный момент не подходит) Я думал добавить это предложение в новый выпуск, но уверен, что мне нужно изучить и проанализировать больше, чтобы внести действительно полезное предложение. Я вижу много предостережений, но мне очень нравится иметь возможность

pip checkout git+https://github.com/somebody_trusted/pip_distro4ubuntu<strong i="12">@bleeding_egde_branch</strong>
#or
pip checkout git+https://github.com/somebody_trusted/pip_distro4ubuntu<strong i="13">@stable</strong>

Я имею в виду, что это может решить (с помощью something_trusted (или сообщества с большим количеством модульных тестов)) что-то вроде проблемы pandas и statsmodels, которую вы описали выше.

(полезно также посмотреть в этой теме: https://pypi.python.org/pypi/peep)

@ Liso77 все просто: обсуждение этого вопроса не закончено. Ожидается PR с реализованной командой upgrade (gh-3194), но разработчики pip (по крайней мере, qwcode и @dstufft , и, вероятно, также @xavfernandez и @pfmoore) должны решить, хотят ли они этого , или вместо этого они хотят изменить поведение pip install . Пока этого не произойдет, ничего не изменится.

+1

Итак, похоже, что введение новой команды обновления было согласовано, и последние неурегулированные дебаты заключаются в том, должна ли быть команда "upstall", и если да, то какая основная команда (установка или обновление) должна получить ее как переключатель или по умолчанию .

Добавляя мое личное мнение:

Я думаю, что наличие отказоустойчивой единственной команды для установки «того стоит», _ если только_ только в тех случаях, когда вы хотите программно проверить, что среда обновлена ​​по любой причине. Почему «программно»? Потому что он не интерактивный, т.е. нет пользователя, который бы реагировал на ошибку, предупреждение или другое сообщение, указывающее ему на команду «брат» или «сестра», потому что пакет уже существует или не существует.
При желании можно добавить подсказку, спрашивающую пользователя, хочет ли он обновить или установить, вместо того, чтобы просто жаловаться.

Тем не менее, эта команда «upstall» не должна использоваться по умолчанию для любой из команд (установка / обновление) и, следовательно, требует вызова опции. Это добавляет ясности семантически четко определенным глаголам «установить» и «обновить», и, на мой взгляд, все менеджеры пакетов, которые обновляют по умолчанию на одном из них, делают это неправильно. Запрос на действие (как, кажется, делает yum ) в порядке.

Остается upgrade --install (короче, чем --install-missing ) и install --upgrade . Семантически, «обновить до последней версии [и установить, если не существует]» и «установить последнюю версию [или обновить до последней версии, если она уже существует]». Здесь нет большой разницы, имо. install --upgrade - это уже существующая версия, которая будет узнаваема, но обратно несовместима.
Вот еще одна комбинация: новая команда с именем install-upgrade (или upstall ?), В которой ни при установке, ни при обновлении не предоставляется возможность «сделать и другое», но новая команда представлена ​​с четкая семантика в важной позиции: само имя команды. Это было бы моим предпочтением.

TL; DR : ввести upgrade и upgrade-install , исключить install --upgrade . Весь функционал с понятной семантикой.
Добавьте сообщения или, при необходимости, запросы на установку и обновление команд, если их операции завершаются неудачно из-за того, что пакет уже существует или не существует.

Сделал это снова вручную сегодня утром. Есть ли какие-нибудь новости по этому запросу функции?

+1

+1

+1

Всем, пожалуйста, используйте реакцию "большой палец вверх" на OP и прекратите спамить всем входящим почтовым ящикам.

поскольку pip имеет другую модель контроля качества, чем дистрибутивы linux, я вполне уверен, что случайная команда upgrade all - это просто сбой в процессе создания

pypi не имеет базы данных версий пакетов и совместимости, которая фактически проверена и протестирована,
поэтому в отличие от дистрибутива с QA pypi практически не имеет собственного QA и полностью полагается на загруженные в него проекты (которые различаются по качеству)

с текущими наборами ограничений я убежден, что это больше проклятие, чем благословение
и если кому-то интересно, почему дистрибутивы так устарели, QA требует времени и усилий ^^

Всем, пожалуйста, используйте реакцию "большой палец вверх" на OP и прекратите спамить всем входящим почтовым ящикам.

Обратите внимание, что на самом деле нам не нужны какие-либо ответы типа «Я бы хотел это» от людей. Мы знаем, что люди хотят этого, чего не хватает, так это того, чтобы кто-нибудь хотел разработать исправление, которое учитывает все различные проблемы и проблемы, которые уже были подняты, и которые неизбежно возникнут во время проверки связи с общественностью.

Так что лично я был бы признателен, если бы люди воздерживались от проверки этой проблемы, если у них нет рабочего кода, который хотя бы предлагает отправную точку для реализации - и они готовы довести ее до реализации.

В противном случае мы доберемся до этого, когда сможем. Я лично регулярно сталкиваюсь с этой проблемой, и я являюсь основным разработчиком pip, поэтому я могу гарантировать, что, если у меня когда-нибудь будет достаточно времени, чтобы поработать над этим, я буду. А пока "прогресс есть?" комментарии, как правило, просто демотивируют меня, потому что они в основном просто ощущаются людьми, требующими права диктовать мне, как я провожу свое хобби ...

отправная точка для реализации

Я думал, что это цель https://github.com/pypa/pip/pull/3194? С этого момента обсуждение перешло к нескольким альтернативам именования и поведения команд без согласия основных разработчиков. Поможет ли реализовать несколько из этих альтернатив? Или https://github.com/pypa/pip/pull/3194 просто нужно обновить?

@sfriesel Вы пропустили "и готовы

Более 50% работы над подобным предложением - это «управление» (документирование предложений, управление обсуждениями, достижение консенсуса). Это не обязательно то, что люди любят делать, но с такой широко используемой кодовой базой, как pip, это важная часть. (И да, это проблема - гораздо приятнее сказать «Я пишу код для хобби», чем «Я занимаюсь управлением проектами в качестве хобби» :-))

@pfmoore Полностью согласен.

Количество предложений и количество обсуждений, разбросанных по разным местам, связанные с этим вопросом на протяжении многих лет, чрезвычайно затрудняют подход к этому вопросу и получение четкой картины за короткое время .

@RonnyPfannschmidt

pypi не имеет базы данных версий пакетов

Это так. Это информация, предоставляемая пакетами во время выполнения (файла setup.py), и она немного усложняет процесс разрешения зависимостей. Более того, из-за того, как ведет себя текущая логика, некоторые пакеты (даже известные, такие как scipy) не перечисляют зависимости (например, numpy), если они установлены, чтобы избежать ненужной повторной компиляции.

Среди прочего, это будет решено с помощью PEP 426 , но я не знаю, каков статус этого PEP.

@pfmoore

Обратите внимание, что на самом деле нам не нужны какие-либо ответы "Я бы хотел это" от людей.

Просто заманчиво сказать +1 или показать большой палец вверх, что вы хотели бы, чтобы это произошло. Это позволяет человеку почувствовать, что он что-то добавил к этой проблеме, внес свой вклад в ее решение. Я не говорю, что разработчиков pip нужно мотивировать или убеждать, просто все хотят это сказать. И...

Я был бы признателен, если бы люди воздерживались от проверки этой проблемы, если у них нет рабочего кода.

Поднятие большого пальца не приведет к появлению (раздражающих) уведомлений / электронных писем, и мы все равно увидим количество людей, проявивших интерес. Я не думаю, что кто-то должен возражать против этого, но я могу ошибаться.

Поднятие большого пальца не приведет к появлению (раздражающих) уведомлений / электронных писем, и мы все равно увидим количество людей, проявивших интерес. Я не думаю, что кто-то должен возражать против этого, но я могу ошибаться.

Ах, я не понимал, что это позволяет избежать уведомлений. Да, что это хорошая идея.

Следующим шагом в этом направлении, вероятно, будет либо OP, либо кто-то другой, кто желает взять на себя ответственность за PR, чтобы написать краткое изложение текущей позиции в стиле PEP, каковы различные нерешенные проблемы, что он предлагает в качестве решение этих различных проблем и призыв к комментариям для возобновления обсуждения.

Как бы то ни было, я ранее писал об этом и разрешении зависимостей в стиле PEP. Я собираюсь разделить его и обновить сейчас, добавив все, что было предложено за последние несколько месяцев. Я отправлю один для команды обновления как Gist, как только он будет готов (~ 2 дня?), И ссылку на него отсюда.

Я пока не хочу брать на себя ответственность за PR. Я намерен помочь оживить дискуссии и прийти к окончательному проекту, который можно реализовать. Если некоторые вещи вокруг меня идет к плану, я должен быть в состоянии следовать этому пути реализации , но я не хочу , чтобы совершить его после этого через только пока.

/ cc @qwcode @dstufft @pfmoore @xavfernandez

Вот ссылка на мою запись: https://gist.github.com/pradyunsg/a5abeac4af90fbdc54bb266c32c0d2d8

Сначала я просто ссылался на разные места (~ 30 ссылок), на которые читатель мог сослаться, и пытался скопировать, а затем отредактировать, чтобы подогнать под все цепочки комментариев. Документ был довольно длинным, и мое мнение проскользнуло. В итоге я начал с нуля. Но теперь он короче и не самоуверен. Я все еще отмечал это как WIP.

Если есть какие-то проблемы, прокомментируйте Gist. Я внесу исправления, как только смогу.

ВНИМАНИЕ: _SLIGHTLY_ ДАЛЬНЕЙШИЙ КОММЕНТАРИЙ ВПЕРЕДИ

Мне нравится идея исправить существующее поведение --upgrade . Есть ли какие-либо опасения по этому поводу, кроме обратной совместимости? Добавление команды upgrade не кажется хорошей идеей из-за большого совпадения между установкой и обновлением.

FWIW, git сделал что-то похожее на то, что мы обсуждаем по поводу --upgrade , изменив поведение по умолчанию git push в 2014 году. Link

Если есть интерес к изменению поведения pip install --upgrade , вот предложение по раздаче (обозначьте его как P1) для этого обсуждения:

• Начиная со следующей основной версии (9.0), pip install --upgrade выводит предупреждение:

`` ''
PipDeprecationWarning: pip перестанет обновлять зависимости до последних версий
версия безоговорочно по умолчанию стартовая версия 11.0.

Чтобы сохранить текущее поведение после изменения поведения по умолчанию, чтобы
команда установки передает --upgrade-strategy eager .

Чтобы немедленно начать использовать новое поведение, команде установки
передать --upgrade-strategy non-eager .

Чтобы подавить это сообщение,.

Подробнее читайте.
`` ''

Ссылка на страницу документации предоставит краткий обзор изменения и его последствий. Затем он отвечал на самый распространенный вопрос: «Что мне делать?» и "Какую стратегию обновления мне следует использовать?" самым прямым разумным способом.

• Сообщение может использовать очистку.
• Вариантом может быть даже 2 флага, --upgrade-eager и --upgrade-non-eager или что-то в этом роде. Это байкешдинг, то есть последний шаг.
  
  
  
  • Если не произойдет чего-то серьезного, в версии 11.0 pip install --upgrade переключает поведение на отсутствие желания при обновлении зависимостей.
  
  

Изменить: я поставил 3 цикла основных версий для изменения, просто чтобы дать людям больше времени на переключение. Возможно, в этом нет необходимости. Может быть, достаточно одной основной версии, выводящей предупреждения, и следующего внесения изменений?

@dstufft придумал похожую (такую ​​же?) идею.

Если команда обновления - это путь вперед, вот предложение по раздаче для возобновления этого обсуждения (назовите его P2, если хотите):

1. pip upgrade копирует большинство параметров и поведения из pip install .
2. Флаг --dry-run будет добавлен к командам install и upgrade которые печатают, какой пункт будет пытаться выполнить, если он действительно будет запущен.
3. pip install <out_of_date_pkg> не меняет поведения.
4. pip upgrade <not_installed_pkg> не удастся.
5. pip upgrade <up_to_date_pkg> ничего не сделает, скажет, почему ничего не сделал, и выйдет с нулевым кодом выхода.
6. pip upgrade <out_of_date_pkg> выполнит неактивное рекурсивное обновление.
   
   
   
   • : white_check_mark: По умолчанию - рекурсивное обновление без желания
   
   
7. pip upgrade --eager package будет вести себя как сегодняшняя pip install --upgrade .
   
   
   
   • : white_check_mark: Разрешить согласие на текущее поведение
   
   
8. pip install --upgrade напечатает RemovedInPip10Warning .
   Потому что его уберут.

Кроме того, что вы думаете о:

1. Делаем команду обновления интерактивной? (что-то вроде того, что делает apt-get)
   
   
   
   • заставить pip install <pkg> вести себя как установка ieupstall диспетчера пакетов ОС?
   
   
2. Имея --only-binary по умолчанию в новой команде обновления?
   
   
   
   • Если все в порядке, как насчет добавления --only-source и --no-source в команду обновления?
   
   
3. Добавляете возможность «удерживать» обновление пакета? ИМО, это требование для upgrade-all .
4. Имеет ли смысл различать эти случаи, т.е. требовать разные интерфейсы командной строки?
   
   
   
   • установить: не установлено -> актуально
   
   
   • обновление: устаревшее -> актуальное
   
   
   • upstall: {not-installed, out-of-date} -> up-to-date
   
   

Я ничего не предлагал по поводу «установить как апсталь», потому что в любом случае я не уверен в этом. Это согласуется с менеджерами пакетов на уровне ОС, но будет серьезным изменением. Я не уверен, насколько это было бы полезно и на что было бы похоже точное поведение и интерфейс ...

Может, это поможет поспать.

Лично я не вижу особой ценности в том, чтобы придерживаться поведения, которое мало кому нравится. Интересно, было бы лучше или хуже иметь один для Python 2 (охватывающий стабильность) и другой для Python 3 (охватывающий изменения).

@ekevoo

Интересно, было бы лучше или хуже иметь один для Python 2 (охватывающий стабильность) и другой для Python 3 (охватывающий изменения).

Во-первых, это не по теме. Во-вторых, если вы это сделаете, в конечном итоге возникнет расхождение. Это оттолкнет людей, которые в настоящее время используют Python 2, потому что (надеюсь) однажды он достигнет EOL, и им придется перейти на Python 3, чтобы адаптироваться к другому инструменту. Таким образом, pip не должно вызывать расхождения (и не будет, ИМО). Тогда можно было бы объединить все это в одном инструменте.

OTOH, я понимаю, что вы думаете о приемлемости обратной совместимости ...

Предупреждение в пункте 9, а также дополнительные параметры для настройки поведения pip install --upgrade , --eager/non-eager (или другого имени) кажутся мне нормальными.

Удар. Еще одно уведомление для всех.

@pfmoore @dstufft @qwcode Я не хочу быть любопытным, но не могли бы вы выделить для этого немного времени, на выходных или на следующей неделе?

Итак, мои комментарии:

Что касается двух направлений вперед, у меня нет мнения. Выберите тот, который, по вашему мнению, лучше, реализуйте его, и мы посмотрим, что из этого выйдет.

Повторите ваши дополнительные вопросы:

1. Я -1 за то, чтобы сделать команду интерактивной. Если нет конкретной проблемы, по которой пользователь должен принять решение, например, «это последствие того, о чем вы просили, - это то, о чем вы явно не подозревали, и может быть проблемой - вы хотите продолжить», тогда это просто бесполезный шум. Я против подсказок типа "вы уверены" вообще. Если у вас есть конкретное предложение для подсказки, которую, по вашему мнению, стоит добавить, не стесняйтесь спросить еще раз, указав детали.
2. Мы не должны делать обновления, отличные от установок, поэтому по умолчанию не использовать --only-binary . Для личного использования я, вероятно, всегда буду хотеть в первую очередь pip upgrade --only-binary , но я _ хочу_, чтобы это было явно.
3. Я не совсем понимаю, что вы имеете в виду, говоря о "удержании" обновлений. Просьба уточнить. Но в качестве общего ответа я бы посоветовал не беспокоиться в первую очередь, давайте избавим первоначальный PR от «необязательных дополнений» - они могут быть добавлены позже.
4. Разве это не основная тема обсуждения различных обсуждений этой функции? Для начала, разве это не влияет на основной вопрос install --upgrade vs upgrade ? Я не припомню, чтобы этот вопрос был разрешен, поэтому я немного удивлен, что вы ожидаете "простого" ответа на этот вопрос? У меня, конечно, нет хорошего ответа.

(Между прочим, у меня нет легкого доступа к сути, поэтому, если там есть какой-либо контент, которого нет в вашем резюме, я пропустил его, извините).

Я знаю, что писать PR - тяжелая работа, и демотивировать его, чтобы он, казалось, увяз в дебатах и ​​вопросах, но в конечном итоге я думаю, что кому-то придется написать его и изложить как «это решение. Предлагаю - какие-нибудь комментарии? "

Мы не должны делать обновления, отличные от установок [snip] Я, вероятно, всегда буду хотеть pip upgrade --only-binary в первую очередь, но я хочу, чтобы это было явным.

Если вы, вероятно, всегда чего-то хотите, по умолчанию должно быть ¹ . Но я думаю, что поддержание согласованности между install и возможной командой upgrade - хорошая идея.

Я не совсем понимаю, что вы имеете в виду, говоря о "удержании" обновлений.

Я оставлю это в покое, пока мы не перейдем к разговору о добавлении функциональности для всех обновлений.

Примечание для себя: apt-mark концепции для пункта

Я -1 за то, чтобы сделать команду интерактивной. Если нет конкретной проблемы, по которой пользователю нужно принять решение

То же.

Разве это не основная тема обсуждения различных обсуждений этой функции?

Именно поэтому я хотел знать, что вы думаете, ребята.

Я не припомню, чтобы этот вопрос был разрешен, поэтому я немного удивлен, что вы ожидаете "простого" ответа на этот вопрос?

Я пока не жду "простого" ответа. Я надеюсь, что в ходе обсуждения мы придем к одному, желательно простому ответу.

Кстати, у меня нет легкого доступа к сути, поэтому, если там есть какой-либо контент, которого нет в вашем резюме, я его пропустил, извините

Это больше, чем резюме, это продолжение рецензии. Пожалуйста, прочтите его, как только сможете.

Выберите тот, который, по вашему мнению, лучше, реализуйте его, и мы посмотрим, что из этого выйдет.
[отрывок]
Я думаю, что кому-то придется написать один [PR] и изложить его как «это решение, которое я предлагаю - какие-либо комментарии?»

Я думал примерно так: «Давайте сначала определим, что именно мы хотим», а затем приступим к реализации этого.

¹ если он не сломает чужой мир

Мы не должны делать обновления отличными от установок [snip] Я, вероятно, всегда буду хотеть обновить pip --only-binary в первую очередь, но я хочу, чтобы это было явным.
Если вы, вероятно, всегда чего-то хотите, это должно быть по умолчанию. Но я думаю, что поддержание согласованности между установкой и возможной командой обновления - хорошая идея.

Если _everyone_, вероятно, всегда чего-то хочет, это (возможно) должно быть по умолчанию. Но я просто комментировал свои предпочтения. Честно говоря, я понятия не имею, хочет ли большинство людей --only-binary (вероятно, это зависит от того, говорим мы о долгосрочной или краткосрочной перспективе).

Существует сильная разница между двоичными файлами (колесами), источниками, которые можно собирать где угодно (обычно на чистом Python), и источниками, которым требуется компилятор или другие внешние предпосылки. К сожалению, pip не может различить последние два, и это делает --only-binary менее полезным (особенно по умолчанию).

И я ценю согласованность между командами, а не значения по умолчанию «делай то, что я имею в виду», что, опять же, может быть только моим личным предпочтением.

Это больше, чем резюме, это продолжение рецензии. Пожалуйста, прочтите его, как только сможете.

Я читал это, он не добавил многого, о чем я не знал (поскольку я следил за различными обсуждениями по этому поводу), поэтому мои комментарии остаются в силе. Но это хорошее резюме состояния игры, так что спасибо за то, что написали его.

Мы не должны делать обновления отличными от установок [snip] Я, вероятно, всегда буду хотеть обновить pip --only-binary в первую очередь, но я хочу, чтобы это было явным.

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

Если _everyone_, вероятно, всегда чего-то хочет, это (возможно) должно быть по умолчанию. Но я просто комментировал свои предпочтения.

Уточнение: «Вы» в моем комментарии относились к конечным пользователям (во множественном числе), причем

Некоторые мысли о стратегиях обновления. Личное мнение, все это, конечно :-)

Предположим, я делаю pip upgrade foo

1. Если в настоящее время у меня не установлен foo , я ожидаю ошибки. Для меня «установка» и «обновление» - это два отдельных действия, которые я не хочу объединять.
2. Если нет доступной версии, более новой, чем та, которая установлена ​​в настоящее время (см. Ниже --only-binary ), я ожидаю уведомления о том, что делать нечего.
3. В противном случае я ожидаю, что foo будет обновлен до последней версии. Это то, о чем я просил, так что это должно произойти.
   
   
   
   • Я не уверен, что добавление ограничений имеет смысл. Что будет означать pip upgrade foo>1.0 если у меня установлена ​​версия 1.1, но доступна версия 1.2? Это не обновление, если там остается 1.1, но если он обновляется до 1.2, это то же самое, что и pip upgrade foo . Возможно, вы могли бы приписать смысл чему-то вроде pip upgrade foo<2.0 но ИМО, это было бы очень необычным случаем и не стоило бы сложности. Итак, предположим, что pip upgrade просто принимает список имен пакетов (в отличие от требований).
   
   
   • Точно так же я не знаю, как интерпретировать pip upgrade <path_to_archive/wheel> . Предположим, что это не разрешено в первую очередь.
   
   
4. Я могу или не могу позволить pip пытаться построить из исходного кода (это должно быть решение пользователя, так как pip не может сказать, будет ли сборка из исходного кода работать, и не имеет возможности повторить попытку с другой версией, если исходная сборка не выполняется). Таким образом, --only-binary должен быть пользовательским параметром, и если он указан, это означает, что pip должен игнорировать распространение исходного кода при определении того, «что доступно». (Конечно, мы могли бы использовать по умолчанию только двоичные файлы и иметь опцию --allow-source , но в любом случае upgrade должно соответствовать install в этом отношении).

Хорошо, так что обработаны явно указанные пакеты. Я сомневаюсь, что в этом есть что-то спорное (кроме, может быть, тех частей, которые, как я говорю, мы должны опустить на потом). Теперь о зависимостях.

• На мой взгляд, основное правило состоит в том, что мы никогда не должны ничего делать с зависимостями, если только мы не _актуально_ обновляем указанный пользователем пакет. Итак, это отправная точка. Если цель не обновляется, даже не смотрите на зависимости. Всегда.
• Я считаю, что _все_ зависимости должны обрабатываться одинаково - неважно, являются ли они прямыми или косвенными зависимостями указанного пользователем пакета. Не думаю, что это спорно.
• Основное предположение здесь должно заключаться в том, что пользователь не знает, каков список зависимостей. В конце концов, смысл наличия неявных зависимостей в том, что пользователю _не_ нужно ими управлять. Таким образом, любое решение, которое требует, чтобы пользователь явно знал о зависимости, на мой взгляд, является ошибочным (если только команда не завершится с сообщением о конкретной зависимости, и в этом случае пользователь может повторно запустить эту зависимость, указанную в параметре, но мы должны стараться работать с первого раза в максимально возможном количестве случаев, поэтому это не следует рассматривать как норму).
• Я бы сказал, что по умолчанию подход должен заключаться в обновлении только тех зависимостей, которые _должны_ быть обновлены для удовлетворения новых ограничений. Здесь кроется неприятная проблема, поскольку ограничения могут меняться в зависимости от того, что обновляется. Но не так уж важно, делаем ли мы полное решение этой проблемы или просто пробуем какое-то решение «наилучшего усилия» (я сомневаюсь, что сложные графы зависимостей с конфликтующими ограничениями - обычное дело в реальной жизни). Важным моментом является принцип, согласно которому мы не обновляем ничего, о чем пользователь не просил обновить, за исключением случаев, когда это необходимо.
• Наличие флага «обновить все до последней версии» может быть полезно (по крайней мере, для обратной совместимости). Еще лучше было бы иметь инструменты (возможно, внешние по отношению к pip), которые анализируют и сообщают о вариантах обновления. Тогда пользователи могли решать сами. Но я не знаю, увижу ли я когда-либо необходимость в каком-либо из этих вариантов.
• Вместо варианта «нетерпеливого обновления» мне гораздо больше нужна команда upgrade-all (или upgrade --all если мы хотим придерживаться одной команды). Это должно быть семантически идентично upgrade с каждым установленным пакетом, указанным в командной строке. Когда я выполняю слепое обновление пакетов (обычно я могу не знать или не задокументировать дерево зависимостей своих пакетов), я, вероятно, просто хочу «все». Тем более, если я использую виртуальные среды для изоляции вещей.
• Здесь снова появляется вопрос --only-binary . Конечно, если пользователь указывает --only-binary для основного обновления, предполагается, что зависимости подразумевают --only-binary . Но даже если пользователь разрешает установку исходного кода при обновлении основного пакета, введение риска сбоя, связанного с выполнением обновления исходного кода зависимости, кажется неразумным. Поэтому я бы посоветовал нам всегда рассматривать только двоичные файлы для обновления зависимостей, если пользователь явно не разрешает источник. Это означало бы, что потребуется опция --allow-source dep1,dep2,... . Я ожидаю, что это предложение будет спорным, но рассмотрим чистый пакет Python foo который распространяется только в исходной форме, которая зависит от numpy. У нас есть foo 1.0 в зависимости от numpy> = 1.10 и foo 2.0 в зависимости от numpy> = 1.11. У пользователя foo 1.0, и он хочет выполнить обновление. У них нет средств для создания тупого. Они должны разрешить обновление исходного кода для foo, но они не хотят тратить время на сборку numpy 1.11 (или, что еще хуже, сборка может работать, но дает неоптимизированную сборку, которая ломает их систему). Конечно, они могут указать --only-binary numpy но они могут даже не знать, что foo зависит от numpy.

Вот и все. Для меня требования довольно ясны (и, честно говоря, я не думаю, что они особенно спорны, если мы проигнорируем проблемы реализации). Однако реализация здесь является убийцей (в основном вышесказанное в значительной степени требует подхода полного SAT-решателя, как обсуждалось ранее). На какие компромиссы мы готовы пойти из-за того, что реализация SAT-решателя слишком сложна, скорее всего, именно по этому поводу будут споры.

Насколько мне известно, проблемы реализации будут следующими:

1. Полноценный решатель SAT - это сложно. Я не знаю достаточно, чтобы понять, какие альтернативы проще и чем они отличаются от решателя SAT. (Что ж, активное обновление, я считаю, достаточно просто - вот почему мы этим занимаемся сейчас). В частности, когда мы получим ситуацию, когда мы обновим что-то, что, как гласит простой принцип «не обновляйте то, что вам не нужно», не должно было обновляться.
2. Я замалчивал все, кроме самых основных ограничений зависимостей. Как только мы начинаем устанавливать верхние пределы версий или списки разрешенных версий, все становится неприятно. Но на самом деле такие случаи, скорее всего, будут довольно редкими (я бы хотел, чтобы кто-нибудь провел исследование фактической информации о зависимостях из PyPI - я могу попробовать это сделать, но я сомневаюсь, что у меня будет время).
3. Когда у нас есть несколько целей - pip upgrade a b c - рассматриваем ли мы это как 3 отдельных действия: «обновить a», затем «обновить b», затем «обновить c», или мы объединяем 3 в одно «объединенное» действие каким-то образом (обратите внимание, что, поскольку я предлагаю обрабатывать зависимости, отличные от целей, это _не_ то же самое, что и pip upgrade dummy где фиктивный элемент зависит от a, b и c, и мы предполагаем, что фиктивный элемент был обновлен).

Если кто-то хочет оспорить любой из вышеперечисленных комментариев или утверждений, это прекрасно. По большей части это всего лишь мое мнение, и я, честно говоря, не работаю со сложными средами - мое использование, вероятно, будет в основном связано с поддержанием системной установки и нескольких виртуальных сред в Windows (следовательно, дебаты о двоичной и исходной установке важны для меня, но сложных графиков зависимостей не так много). Чем больше вариантов использования мы сможем проверить, тем лучше.

Итак, в настоящее время у нас есть две операции: pip install и pip install --upgrade , однако я думаю, что обе эти вещи делают то, чего на самом деле никто не хочет делать в реальной жизни.

Для pip install мы получаем такое странное поведение, когда вы можете получить последнюю версию (а можете и не получить!) В зависимости от того, что уже установлено в вашей системе. Я думаю, что из-за такого рода странностей использовать pip сложнее, и я не думаю, что это действительно имеет большой смысл (в какой ситуации вы бы не заботились об обновлении, но вы все равно хотите установить последнюю версию, если у вас еще нет Это?). Я думаю, что тот факт, что эта команда имеет такое странное поведение «может быть, последнее, может, нет», является причиной того, что мы видим, что многие люди используют pip install ---upgrade качестве своей основной команды, а не pip install .

Тем не менее, pip install --upgrade не намного лучше, хотя он дает вам последовательное поведение, он чрезмерно нетерпелив, он расширяется до полного обновления _everything_, о котором пользователь может даже не знать, будет задействован в их pip install --upgrade команда. Я действительно вижу некоторую пользу в таком поведении, но не считаю его хорошим значением по умолчанию для команды верхнего уровня.

Что, я думаю, нам следует здесь сделать, так это выяснить, как сделать `pip install ... more consistent. In that I mean pip install всегда должен иметь последнюю приемлемую версию (с учетом спецификаторов и флагов модификаторов, таких как - only-binary '') независимо от того, что было установлено ранее.

Я думаю, что дать этой команде какое-то поведение --eager или --recursive или --upgrade-all-the-things было бы нормально.

Я не думаю, что нам следует делать команду pip upgrade которая принимает список пакетов. Я думаю, что если мы добавим такую ​​команду, то с ее помощью нужно просто обновить все установленное до последних версий (с учетом информации о цепочке зависимостей, а также модификаторов типа --only-binary ).

Хм? Итак, pip install foo не всегда дает сбой, если установлен foo? Мне это кажется неправильным, я бы ожидал, что он просто скажет «уже установлено».

Мне не нравится идея о том, что pip install означает «установить или обновить». Лучше быть откровенным и все такое.

Прямо сейчас pip install foo никогда не «дает сбой» в зависимости от того, установлено что-то или нет, он просто ничего не сделает и скажет, что X уже установлен. Я утверждаю, что поведение не очень полезно. «Утверждать, что какая-то версия, любая версия, какая бы она ни была установлена», мне не кажется полезным поведением. Он также не соответствует другим менеджерам пакетов, которые я привык любить apt-get или около того.

Хорошо, я вижу, что такое поведение бесполезно (хотя лично я нахожу молчаливое принятие "уже установлено" как довольно безобидное). Но я бы предпочел, чтобы установка уже установленного пакета завершилась ошибкой, а не обновлялась.

Что бы вы ожидали от pip install foo-1.0-none-any.whl , если бы foo 2.0 уже был установлен? Перейти на более раннюю версию? Тихо ничего не делать? Я бы предпочел увидеть красивую простую ошибку «уже установлена», чем сложный набор правил, которые, я сомневаюсь, люди запомнят на практике.

У меня нет большого опыта работы с менеджерами пакетов Linux, поэтому я не могу комментировать сходство (или иное) с pip. Но я не думаю, что я ожидал бы обновления apt-get install foo , поэтому, если вы скажете, что да, я могу только ответить, что мне это тоже покажется странным.

«Утверждать, что какая-то версия, любая версия, какая бы она ни была установлена», мне не кажется полезным поведением.

Небольшой побочный вопрос по этому поводу: как насчет «Утвердить, что эта конкретная версия установлена»?

Неважно, у нас такое поведение сегодня.

@pfmoore :

Что вы ожидаете от pip install foo-1.0-none-any.whl, если бы foo 2.0 уже был установлен? Перейти на более раннюю версию? Тихо ничего не делать? Я бы предпочел увидеть красивую простую ошибку «уже установлена», чем сложный набор правил, которые, я сомневаюсь, люди запомнят на практике.

Ха, ожидания - вещь удивительная. Я бы сказал, что _ очевидно_ в этом случае pip должен понизить рейтинг. Пользователь полностью ясно сказал, что он хочет, чтобы pip установил именно это колесо, поэтому pip должен установить именно это колесо. В этом нет ничего сложного. Но случай «путь распространения / файл явно указан» - это №536 - вероятно, нам следует сосредоточить это обсуждение на том, что произойдет, если пользователь скажет «pip install foo», который перейдет к индексу пакета и найдет foo 2.0, когда foo 1.0 уже установлен.

Я полностью согласен с позицией Дональда здесь. Если мы начнем с вопроса «что должен делать pip install ?», То я могу понять, как можно утверждать, что, ну, в названии написано «установить», поэтому нужно только устанавливать вещи, а не обновлять их ( ну, кроме случаев, когда есть какие-то ограничения). Но если мы начнем с вопроса «какие операции хотят пользователи?», То команда, которая может установить последнюю версию или оставить вам старую версию, будет действительно странной и нелогичной. Я утверждаю, что в 99% случаев, когда пользователи вводят pip install x , это происходит потому, что они (а) либо не уверены, установлен ли он, либо знают, что это не так, И (б) хотят убедиться, что они они установили его, потому что они собираются начать использовать его впервые. (Если бы это было не в первый раз, они бы знали, что он был установлен, поэтому они бы не запускали pip install .) В этой ситуации предоставление им последней версии является правильным решением.

@nchammas :

А как насчет «Подтвердить, что эта конкретная версия установлена»? Мне кажется полезным наличие идемпотентной команды установки.

Для «конкретной версии» есть pip install x==<version> .

Я также могу представить, что для некоторых видов сценариев / программного использования может быть полезно иметь команду pip require x которая имеет ту же семантику, что и установка пакета с Dist-Requires: x , т.е. она гарантирует, что некоторые версия установлена, но без каких-либо гарантий. Но это будет команда нижнего уровня, не предназначенная для конечных пользователей.

Один из способов подумать о разнице между ними: если x не установлен, тогда для pip require x будет нормально установить какую-то случайную старую версию. (И, черт возьми, может быть, и следует, чтобы заставить людей быть стойкими против этого .) Но никто никогда не согласится с pip install x устанавливающим какую-то случайную старую версию.

(Это мысленный эксперимент, я на самом деле не сторонник того, чтобы простые Dist-Requires: x или pip require x в среде без x выбирали случайную старую версию x для установки.)

Что ж, я предполагаю, что есть еще один случай, когда пользователи вводят pip install x , когда они уже знают, что он установлен, но они привыкли к системам с поведением в стиле Debian, где install всегда обновляется . Очевидно, эти пользователи тоже хотят его обновить :-).

Я бы предпочел не добавлять команду pip upgrade .

Пользователи pip уже имеют определенные ожидания от поведения pip.
Основная проблема связана с поведением по умолчанию pip instal --upgrade поэтому давайте сосредоточимся на этом.

Предупреждение в пункте 9, а также дополнительные параметры для настройки поведения pip install --upgrade , (--eager / non-eager), за которым следует в пункте 10 изменение его поведения по умолчанию, кажется достаточно простым, должно устранить основную боль origin и не нарушает ментальную модель pip пользователей.

Да, я определенно пытаюсь подойти к этому с точки зрения «какие операции хочет выполнять пользователь», а не «какие операции должна выполнять команда X». Затем я беру эту высокоуровневую операцию, которую, как мне кажется, хотят делать пользователи, и пытаюсь сопоставить ее с одной именованной командой (как бы явно это ни было, pip install-the-latest-version `` не очень удобен для пользователя) .

Очевидно, все это очень расплывчато, но я могу сказать, что в 99% случаев я делаю pip install -U <whatever> потому что это лучше всего соответствует тому, что я ожидаю от установщика, учитывая то, что в настоящее время доступно. Я также вижу в различных сценариях автоматизации людей, использующих pip install -U . Это также то, что по умолчанию делают другие популярные менеджеры пакетов для языков, например npm. В тех случаях, когда я вижу, что люди не используют -U , это связано с его рекурсивным характером, а не потому, что они не хотят устанавливать последнюю версию чего-либо.

Пользователи pip уже имеют определенные ожидания от поведения pip.

TBH, однако, основное ожидание, которое я ожидаю от pip как пользователя, состоит в том, что примерно в 50% вызовов он будет делать что-то неожиданное и явно неправильное. И я не единственный - см., Например, выступление @glyph на pycon на прошлой неделе, где он заметил, что pip великолепен, за исключением того, что все значения по умолчанию нарушены и требуют флажков unbreak-me. Это не критика разработчиков pip, я понимаю, что вы / мы все работаем со сложным набором ограничений, и это не аргумент в пользу того, что мы должны волей-неволей ломать что-то ради того, чтобы сломать его - pip имеет много частей, и многие из них хороши! Но, учитывая общее состояние параметров pop по умолчанию, меня действительно_ не убеждают аргументы вида «pip всегда делал X, поэтому pip всегда должен делать X». Если вы хотите, чтобы pip install отказывался от обновления, это круто, но я бы предпочел, чтобы этот аргумент был сделан по существу, а не только по инерции.

Да, я, конечно, согласен с @njsmith и @glyph здесь. У нас есть ряд плохих поведений по умолчанию, и часть продвижения вперед, я думаю, должна заключаться в том, чтобы выяснить, как мы можем избавиться от них и справиться с этими критическими изменениями, чтобы перейти к лучшим настройкам по умолчанию.

Это конкретное изменение может не быть одним из тех, но я думаю, что это так.

Да, я определенно пытаюсь подойти к этому с точки зрения «какие операции хочет выполнять пользователь», а не «какие операции должна выполнять команда X». Затем я беру эту высокоуровневую операцию, которую, как мне кажется, хотят сделать пользователи, и пытаюсь сопоставить ее с одной именованной командой (как бы явно она ни была, pip install-the-latest-version `` не очень удобна для пользователя) .

В ПОРЯДКЕ. Предположим, я готов считать себя убежденным (в некоторой степени) в этом. Однако, если мы предположим, что это правильно, как насчет зависимостей? Я на 100% убежден, что «попытаться установить numpy из исходного кода» почти всегда не то, что нужно. Таким образом, мы устанавливаем только numpy с колес, если пользователь явно не упоминает numpy. Примите это пока как данность, а затем предположим, что у нас есть ситуация, которую я описал ранее.

• У пользователя установлены foo 1.0 и numpy 1.10, foo 1.0 зависит от numpy> = 1.10
• PyPI имеет доступный foo 2.0, зависит от numpy> = 1.11. Колеса 1.11 numpy отсутствуют.

Что делает pip install foo ? Предположительно оставить пользователю 1.0, так как это рабочая установка? Но должен ли он завершиться успешно (поскольку foo установлен) или потерпеть неудачу (поскольку не удалось установить последнюю версию)? Если первое, как пользователь узнает, что его система устарела? В последнем случае, как пользователь говорит: «Я просто хочу убедиться, что там есть foo»? Хорошо, пользователь может сделать pip list --outdated , увидеть, что foo 2.0 существует, и сделать pip install foo (Кстати, это все еще кажется мне очень странным, у меня есть foo, но я знаю, что есть новая версия, так что Я делаю pip install ??? Nevermind ...) И получается успех, но 1.0 остается установленной?

Одна из причин, по которой я предпочитаю две команды, заключается в том, что намерения пользователя полностью ясны, поэтому такие крайние случаи, как этот, можно обрабатывать правильно, потому что мы знаем ожидания пользователя.

Может быть, это все очевидно, если вы привыкли к apt-get. Но я могу определенно сказать, что кому-то вроде меня непонятно, кто не такой.

Если вы хотите, чтобы pip install отказывался от обновления, это круто, но я бы предпочел, чтобы этот аргумент был сделан по существу, а не только по инерции.

Мой аргумент основан на явном, а не на неявном. Определенно _не_ на "мы всегда так поступали". У меня нет проблем с мыслью, что, возможно, подходящие пользователи привыкли «устанавливать», что означает «возможно обновить». Я действительно не уверен, что другие пользователи будут.

Одна мысль - есть ли у apt "пакет уже существует - обновление?" быстрый? Я мог бы представить, что установка как обновление была бы менее удивительной для меня, если бы это было «установи-или-спроси-если-мне-нужно-обновить» ... Конечно, pip в настоящий момент не ведет себя так интерактивно, хотя очевидно, что сделать это - вариант.

Это интересный вопрос. Другие менеджеры пакетов в основном обходят этот вопрос, либо не имея на самом деле двоичных пакетов, так что он _ всегда_ по источнику, или в значительной степени имея дело только с двоичными пакетами, поэтому он _ всегда_ двоичный. Мы находимся в какой-то странной ситуации, что усложняет задачу.

Учитывая это, я думаю, что по умолчанию на данный момент мы должны загрузить исходный пакет numpy 1.11 и попытаться установить его, но если они указали --only-binary , то наш гипотетический преобразователь (который нам отчаянно нужен, SAT или обратное отслеживание или что-то еще) увидит, что foo-2.0 не является разрешаемой установкой, и затем вернется к установке foo-1.0 . Это не лучший вариант по умолчанию, особенно для пользователей Windows, где компиляция _ намного_ сложнее, но я думаю, что это отражает реальность сегодняшнего дня.

При этом одна вещь, которую я действительно хочу сделать, - это начать пытаться подтолкнуть вещи к миру, в котором мы можем снова изменить поведение pip, чтобы по умолчанию мы могли быть только двоичными и требовать согласия для исходных выпусков, но я не думаю, что мы еще на месте, где можем это сделать.

@pfmoore : Я думаю, что вопрос установки двоичного кода или исходного кода несколько ортогонален? Мне кажется, что те же самые вопросы возникают и для специальной команды pip upgrade , поэтому, хотя это реальные проблемы, которые нам нужно решить, разделение обновления и установки просто устраняет проблемы, а не упрощает их? Кроме того, в частном случае numpy мы теперь поставляем колеса практически для всех платформ, которые мы заботимся о поддержке :-).

Но вот как я бы посоветовал решить эти проблемы для pip install foo (конкретно этой команды - я не говорю о pip install foo==whatever или pip install ./foo-*.whl или pip install bar где bar имеет Requires-Dist: foo ):

1) Запросите индекс, чтобы найти последнюю версию кандидата foo ; назовите это $LATEST . Если версий-кандидатов не существует, выполняется ошибка.

2) Если $LATEST уже установлено, завершите успешно.

3) Проверьте, есть ли дистрибутив $LATEST который можно установить в текущей среде. (Примеры причин, почему их может не быть: есть только колеса, но нет sdist, и колеса не соответствуют текущей среде. Нет подходящего колеса, и есть sdist, но пользователь передал --binary-only :all: . Нет соответствующего колеса, и есть sdist, но у sdist есть какой-то флаг, говорящий «Я работаю только на python 3», и пользователь запускает python 2 - люди ipython / jupyter, вероятно, будут предложить это как новую функцию в ближайшее время, b / c они хотят отказаться от поддержки python 2 для новых выпусков в январе, при этом все еще предоставляя LTS с поддержкой python-2.)

4) Если $LATEST _не_ имеет жизнеспособный дистрибутив: выдайте предупреждение, чтобы сообщить пользователю, что доступна более новая версия, но не для его среды, в идеале с подсказкой о том, что им нужно делать, если они действительно это делают. хотите новую версию (например, «ipython 6.0.1 доступен, но требует python> = 3.4, и у вас есть python 2.7 - рассмотрите возможность обновления python», или «numpy 1.12 доступен, но нет двоичного кода для ppc64, и у вас есть отключил сборку из источника - рассмотрите --allow-source numpy ). Затем удалите $LATEST из списка версий-кандидатов и перейдите к шагу 1.

5) Если у $LATEST _does_ есть жизнеспособный дистрибутив, попробуйте установить этот дистрибутив.

6) Если установка не удалась (например, b / c это sdist и компилятора нет), то ошибка выйдет. В противном случае завершите успешно.

@njsmith binary-only несколько ортогонален, согласен, но ИМО, если мы пытаемся разработать команды, которые «делают то, что ожидает пользователь», тогда очень важно сделать это правильно в то же время.

@dstufft проблема с "установить numpy, если пользователь не говорит, что --binary-only была объяснена в примере в моем предыдущем эпическом посте - (1) говорят, что foo доступен только в исходной форме, и (2) пользователь не может (и действительно не должно) знать, что foo зависит от numpy. Тогда пользователь не может сказать --only-binary :all: и понятия не имеет, что им нужен --only-binary numpy пока _after_ a (long) не удалось скомпилировать. Или (возможно, еще хуже) успешная компиляция, которая оставляет пользователю неоптимизированный numpy (в наши дни numpy компилируется из коробки в Windows, но дает неоптимизированную сборку).

Я полностью согласен с тем, что в долгосрочной перспективе мы должны по умолчанию использовать только двоичный код, но мы еще далеки от этого (как минимум, это должно означать, что почти каждый пакет чистого Python доступен в виде колеса).

@pradyunsg Как видите, здесь еще много нерешенных проблем. Вы все еще заинтересованы в этом? Я не хочу начинать еще одну долгую дискуссию, если она снова затянется ...

@pradyunsg Как видите, здесь еще много нерешенных проблем. Вы все еще заинтересованы в этом? Я не хочу начинать еще одну долгую дискуссию, если она снова затянется ...

Я ожидал, что там будет. Я заинтересован в том, чтобы продвигать это вперед. Давай сделаем это! :улыбка:

Я предлагаю собрать список всего того, что _user_ хочет, чтобы pip делал, а затем предлагать решения для каждого из них, пока все (или достаточное количество) из них не будут решены командой pip (с параметрами / значениями по умолчанию) или не будут обработаны с помощью "бездействие".

Для начала вот, скорее всего, неполный список:

1. Пользователь хочет установить еще не установленный пакет.
2. Пользователь пытается установить уже установленный пакет.
3. Пользователь хочет обновить установленный пакет.
4. Пользователь пытается обновить пакет, который не установлен.
5. Пользователь хочет убедиться, что у него установлена ​​последняя версия пакета, независимо от того, была она уже установлена ​​или нет.
6. Пользователь обычно не хочет, чтобы все зависимости обновлялись, а вместо этого только удовлетворяет их.
7. Пользователь хочет обновить / установить пакет, но не хочет выполнять сборку из исходного кода (ни из пакета, ни из его зависимостей). Вероятно, более вероятно, чем:
8. Пользователь желает обновить / установить из исходников.

Мои личные предложения по этому поводу, как пользователю:

1) & 7) pip install foo должен попытаться разрешиться до последней доступной версии (с учетом зависимостей) и установить ее. Алгоритм будет @njsmith .
2) pip install foo → показать предупреждение о том, что foo уже установлен, и предложить использовать pip upgrade foo
3) & 7) pip upgrade foo пытается установить последнюю доступную версию foo, снова следуя алгоритму @njsmith . Если более новая версия не может быть установлена, потому что она недоступна для платформы, и нет sdist или пользователь не хочет строить из исходного кода, покажите это. Успешно в любом случае и неуспешно только в том случае, если сама установка не удалась.
4) pip upgrade foo не работает, если пакет не установлен.
5) pip install-uprade foo или pip install foo --ensure-latest или pip install foo --upgrade (в основном то же самое, что и в настоящее время, за исключением отсутствия желания).
7) Все операции не должны быть активными, и будет доступен флаг --eager , чтобы получить старую функциональность install --upgrade . Если зависимость еще не установлена, установите последнюю версию. Если он уже удовлетворен, ничего не делайте. Если это не устраивает, установите последнюю версию, которая все еще удовлетворяет требованиям (для требований с ограничением сверху).
8) pip upgrade foo --allow-source или pip upgrade foo --allow-source numpy , если foo зависит от небинарных выпусков numpy. Изменить: я не знаю, применимо ли это, см. Комментарий ниже.

Не стесняйтесь расширять список и размещать собственные предложения.

@pfmoore Я не уверен, что есть альтернатива? Состояние мира сегодня таково, что колеса набирают популярность, но они далеко не повсеместны, поэтому я не уверен, что действительно вижу хороший вариант, который не разрешает выпуск исходных текстов по умолчанию прямо сейчас.

@dstufft мое предложение состояло в том, чтобы разрешить источник для явно названных пакетов, но по умолчанию использовать только двоичные файлы для зависимостей. Таким образом, пользователь не получит «неожиданных» шагов сборки. Конечно, это компромисс, но он отражает то, что я (должен) делать вручную в данный момент.

@FichteFoll Прежде всего, мой основной вариант использования - это возможность «обновить все». Найдите все, что установлено на данный момент, и, если доступны более новые версии, обновите их.

Пакеты, которые я установил, обычно не имеют ничего, кроме зависимостей "> =" (а у большинства их даже нет), поэтому здесь нет ничего сложного. Просто скачайте последнюю версию. Мое самое большое ограничение заключается в том, что есть некоторые пакеты, которые я не могу создать (numpy, scipy, lxml, pyyaml, matplotlib, pyqt), поэтому мне нужны только двоичные файлы для них. Я, вероятно, могу просто положить --only-binary <these> в свой pip.ini (или, по крайней мере, я надеюсь, что смогу ...)

Вторичный: установите пакет XXX (последняя версия), а также любые его зависимости, которых у меня еще нет. Не обновляйте зависимости, которые у меня уже есть, если они удовлетворяют ограничениям нового пакета. Я всегда знаю, что у меня сейчас нет XXX.

Третичный: обновите один пакет XXX, который я (знаю, что я) установил. Не изменяйте никакие другие пакеты, если это не требуется для поддержания ограничений зависимостей (и даже это теоретически - я никогда не сталкивался с такой ситуацией в реальной жизни, поэтому не знаю, какое решение будет для меня лучшим). Мое намерение всегда - «обновить до последней версии». Я никогда не сталкивался с ситуацией, когда это нарушало бы зависимости уже установленных пакетов. Если бы это было так, я _think_, я бы хотел получить предупреждение о том, что у меня нет последней версии (и почему), плюс обновление до последней приемлемой версии. На мой взгляд, эта ситуация в настоящее время переводится в pip install -U хотя поведение зависимостей не то, что я хочу. Основная причина, по которой я сделал это, заключается в том, что в настоящее время нет подходящей команды «обновить все» (или иметь дело со случаями, когда новая команда «обновить все» не работает так, как я хотел).

По моему опыту, все обсуждения зависимостей и ограничений почти полностью теоретические. В настоящее время в моей системе Python установлено 160 пакетов (сочетание научных модулей, модулей анализа данных, веб-модулей и общих программных модулей). 100 из них не имеют требований. В остальном нет ничего сложнее списка пакетов - никаких ограничений версии или чего-либо более сложного, чем Requires: six, dask, pillow, networkx . Самый длинный список зависимостей состоял из 9 пунктов.

@pfmoore Разве это не сломает много вещей? Краткий список вещей, которые я могу придумать и которые, как я знаю, являются очень популярными пакетами, зависит от всего:

• SQLAlchemy (необязательно требуется компилятор, в противном случае будет использоваться чистый Python).
• PyYAML (необязательно требуется компилятор, в противном случае будет использоваться чистый Python).
• Markupsafe (необязательно требуется компилятор, в противном случае будет использоваться чистый Python).
• PyCrypto (всегда требуется компилятор)
• pycparser (не требует компилятора)
• httplib2 (компилятор не требуется)
• anyjson (компилятор не требуется)
• zope.interface (необязательно требуется компилятор, в противном случае будет использоваться Pure Python).
• docopt (компилятор не требуется)
• Мако (компилятор не требуется)
• это опасно (не требует компилятора)
• amqp (не требует компилятора)
• orderdict (не требует компилятора)

и так далее, вы можете увидеть длинный список самых популярных пакетов с указанием того, есть ли у них колеса, на http://pythonwheels.com/.

@pfmoore

Найдите все, что установлено на данный момент, и, если доступны более новые версии, обновите их.

Некоторое время назад я получил эту команду из какого-то вопроса SO, который я сейчас использую для этого. Это неоптимально, но работает с большинством моих пакетов, кроме одного. (Он использует py запуска

pip list -o | cut -d " " -f 1 | xargs -n1 py -m pip install -U

Единственная проблема, с которой я столкнулся, - это пакет flake8, который имеет следующие требования:

Requires-Dist: pyflakes (>=0.8.1,<1.1)
Requires-Dist: pep8 (>=1.5.7,!=1.6.0,!=1.6.1,!=1.6.2)
Requires-Dist: mccabe (>=0.2.1,<0.5)

В частности, проблема представляет собой pyflakes, поскольку для него доступна более новая версия и обновляется с помощью указанной выше команды, в результате чего flake8 ничего не делает (поскольку он проверяет версию).
Так что это действительно то, что нужно учитывать, и я также хотел бы иметь надлежащую функциональность для всех обновлений (без нарушения требований!).

@dstufft почему? Если foo зависит от pyyaml, и я прошу обновить foo, pyyaml ​​не обновляется (нет новых двоичных файлов), но foo все еще можно обновить, так как все еще присутствует исходный pyyaml.

Для новых зависимостей (или при установке, где зависимость не всегда присутствует) вам необходимо установить, поэтому, если нет двоичного файла, вы берете исходный код. Я бы лично подумал о том, чтобы «выбрать старую версию с двоичным кодом вместо новой с исходным кодом», но это становится опасно близким к значению по умолчанию --binary-only которому, я согласен, мы не готовы.

Хм, возможно, проблема у меня на самом деле связана с опцией --only-binary , которая слишком грубая. Если бы у нас была опция --prefer-binary , которая гласила: «Используйте только двоичные файлы, если это не означает, что нет кандидатов, и в этом случае повторите попытку разрешения источника», я подозреваю, что многие из моих опасений, что чрезмерное обновление приведет к поломке может быть облегчено. Что, как предположил @njsmith , означает, что различия между двоичным кодом и исходным кодом, на которых я сосредотачиваюсь, вполне могут быть ортогональны этому билету (хотя это просто изменило бы мою позицию на «нет удовлетворительного решения для моих требований без чего-то лучше, чем --only-binary доступен "...).

В частности, проблема в pyflakes

Хорошо, так что у меня нет такой ситуации (как я уже сказал, у меня нет ничего с установленными зависимостями). У меня нет проблем с уточнением «обновить все», чтобы обновить вещи до «последней версии, которая не приводит к поломкам», но AIUI, которому нужен подход «SAT-решатель» для выработки правильного решения. Однако это проблема реализации - дизайн действительно всегда должен давать правильные результаты.

@pfmoore Я думаю, что флаг --prefer-binary может быть хорошим вариантом, независимо от результата этого тикета. Скорее всего, в комплекте с предупреждением, когда в конечном итоге не устанавливается последняя версия, которая в противном случае была бы установлена.

@FicheFoll : Я не думаю, что попытка переделать весь пользовательский интерфейс из первых принципов будет очень продуктивной. Есть относительно четко определенная часть проблемы, которая относится к этой конкретной проблеме, и если мы попытаемся расширить область действия на все сразу, то она снова просто увянет.

По этой теме, похоже, главное, чем мы отличаемся, заключается в следующем: предположим, что у пользователя есть ментальная модель, согласно которой pip install foo предназначена только для перехода от неустановленных к установленным, и что они понимают, что foo уже установлен. Я утверждаю, что пользователь с этой ментальной моделью _ никогда не наберет pip install foo _. Следовательно, когда какой-то пользователь _does_ набирает pip install foo когда foo уже установлен, мы можем сделать вывод, что его ментальная модель не похожа на вашу (2). _Либо_ первая часть неверна: они знают, что foo установлен, и ожидают, что pip обновится, как некоторые другие популярные менеджеры пакетов, _или_ вторая часть неверна: они не знают, что foo установлен , и в этом случае они ожидают, что install оставит им самую новую версию (потому что это то, что делает установка, когда пакеты не установлены, и они думают, что этот пакет не установлен).

Для записи, одна из причин, по которой мне не нравится, что pip install ... только когда-либо переходит от неустановленного к установленному, а pip upgrade ... только когда-либо переходит от установленного к более новому установленному, заключается в том, что я нахожу пользователя опыт довольно убогий. Программное обеспечение, которое знает, что вы хотите, но вместо того, чтобы делать это, оно предлагает вам вызвать другую команду, невероятно расстраивает.

$ pip install foobar
I'm sorry, but foobar is already installed, you want to run ``pip upgrade foobar``
$ pip upgrade foobar
...

Ничего не сделало бы для меня, кроме как раздражало бы меня, хотя это технически «правильно».

С другой стороны, если вы скажете: «Хорошо, если в pip install foobar уже установлено foobar , то мы будем действовать так, как будто он не установлен, и если вы сделаете pip upgrade foobar тогда мы буду действовать так, как будто он уже установлен, в итоге мы получим две команды, которые делают в основном одно и то же, за исключением _maybe_ некоторых незначительных различий в том, как именно обрабатываются вещи, которые говорят мне, что они принадлежат как единственная команда с некоторыми --options чтобы иметь дело с крайними случаями. Я думаю, что это лучше, потому что это означает, что пользователям не нужно пытаться выбирать между тем, что они хотят заранее, есть одна команда для установки вещей, и для большинства пользователей она обычно поступают правильно.Если какой-либо пользователь в конкретном сценарии требует от себя выбора, то он должен оплатить стоимость выбора того, какой --flags использовать.

В ПОРЯДКЕ. Считайте меня убежденным. Я провел небольшое исследование, и даже установщики Windows, с которыми я (предположительно :-)) знаком, выполняют установку как обновление (если вы устанавливаете что-то вроде VirtualBox, он говорит: «У вас уже установлена ​​предыдущая версия, не так ли? хотите обновить? ") Powershell имеет установочный пакет, в котором ничего конкретного не говорится, но нет пакета обновления. И т.д. Так что я полагаю, что наличие одной единственной команды «установить» является нормой.

Что, конечно, означает, что, если кто-то еще не хочет спорить, технически этот PR может быть просто закрыт как «не будет реализован». Но я думаю, это все еще хорошее место для обсуждения того, как мы хотим переделать команду установки.

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

Вопрос. Кто-нибудь думает, что мы уже достигли точки, когда кто-то мог бы составить полное предлагаемое поведение из всех предложений здесь и в других местах? Обсуждение того, как обрабатываются зависимости, что происходит с ограничениями (и когда они конфликтуют), двоичный код или исходный код, как мы поддерживаем сценарий «обновить все» и т. Д.? Лично я считаю, что нам нужен кто-то, чтобы принять это решение, дать дискуссии точку отсчета, или мы могли бы просто вечно обсуждать детали. Я, вероятно, мог бы это сделать, но вряд ли смогу реализовать то, что предлагаю (например, я бы предложил подход «оптимального разрешения зависимостей», который подразумевает AIUI решателя SAT). Так что было бы лучше, если бы кто-то, кто был готов реализовать свое предложение, активизировался (и имел дело с неизбежными дебатами и байкшедингом :-)).

Меня по-прежнему беспокоят некоторые последствия сделанных здесь пунктов, но я не уверен, что у меня хватит сил обсуждать их, пока не появится реальная возможность реализации.

Я полностью согласен с @dstufft «s последнее https://github.com/pypa/pip/issues/59#issuecomment -224341218
Вот почему (еще раз) я бы выступил за простое решение с вариантами --eager / --non-eager .

Я также согласен с комментарием @dstufft , как уже отмечалось (мы используем одну команду install а не команду update ).

Однако я не уверен, что влечет за собой --eager / --non-eager . Я предполагаю, что --non-eager означает, что не обновляйте ничего, что не нужно обновлять (либо потому, что пользователь указал это явно, либо потому, что он слишком старый, чтобы удовлетворить новый набор зависимостей). Означает ли тогда --eager обновление всех зависимостей до последней возможной версии, независимо от того, необходимо это или нет? Что будет по умолчанию? (Я бы поспорил за --non-eager )

И вопрос - побудит ли это научные пакеты правильно объявлять свои зависимости? Это должно быть важным соображением.

Велосипедная точка. Названия параметров --eager и --non-eager довольно неинтуитивны. Я думаю, нам нужны более выгодные условия. Может быть, что-нибудь явное, например --upgrade-dependencies .

Этот PR также предлагает команду upgrade-all , которая для меня является ключевым вариантом использования. Вы говорите, что мы отвергаем эту команду, или просто у вас нет на нее мнения?

Мое понимание того, что означает --eager и -non-eager совпадает с тем, что только что сказал @pfmoore (независимо от того, используются ли зависимости только при необходимости или всегда установлены), и я согласен с тем, что --non-eager должно быть по умолчанию. Я также согласен с тем, что название довольно неприятное, хотя у меня нет лучшего решения, кроме как наесться. Может, --[no-]recursive или что-то в этом роде, я не знаю.

Я думаю, что что-то вроде команды upgrade-all могло бы быть хорошим дополнением (при условии, что оно не нарушает спецификаторы версии чего-либо). Я бы, вероятно, просто назвал это upgrade и просто позволил бы ему не принимать аргументов для ограничения того, над чем он работает.

tl; dr
Обсуждение upgrade-all-packages - остается здесь.
Обсуждение Prefer-binary - Переход к # 3785
Обсуждение install-as-upgrade - Переход к # 3786

Если бы у нас была опция --prefer-binary, в которой говорилось: «Используйте только двоичные файлы, если это не означает, что нет кандидатов, и в этом случае повторите попытку, разрешив источник»

Это хорошая идея. Хотя это связано с этой проблемой, я думаю, что она заслуживает отдельного рассмотрения. ( Комментарий @dstufft заставляет меня думать, что есть интерес к этому). Я взял на себя смелость открыть # 3785 для дальнейшего обсуждения этого.

Мое понимание того, что означает --eager и -non-eager, соответствует тому, что только что сказал @pfmoore (независимо от того, нужны ли зависимости только при необходимости или всегда установлены)

При нетерпеливом обновлении будут установлены последние разрешенные версии всех (под) зависимостей.

Названия параметров --eager и --non-eager довольно неинтуитивны.

Я согласен. Мне нравится идея поместить поведение за одним флагом.
--upgrade-strategy=eager/non-eager

Это тоже непросто, но более четко передает намерение. Это слишком многословно? Может быть.

Я думаю, что избавление от мотоциклов лучше всего проводить после завершения семантики.

Кто-нибудь думает, что мы уже достигли точки, когда кто-то мог бы составить полное предлагаемое поведение из всех предложений здесь и в других местах?

Я так думаю. Нам нужно, по крайней мере, установить некоторые основные факты, с которыми мы согласны. Я на этом.

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

Я думаю, что мы должны пока оставить этот вопрос открытым, потому что он предлагает upgrade-all . Вы уже отметили, что обновления не происходит. Я открыл # 3786 для дальнейшего обсуждения команды install-as-upgrade.

Меня по-прежнему беспокоят некоторые последствия сделанных здесь пунктов, но я не уверен, что у меня хватит сил обсуждать их, пока не появится реальная возможность реализации.

Я готов продвигаться вперед на всем пути к реализации. Я определенно не хочу тратить впустую усилия всех остальных, чтобы прийти к консенсусу по этому поводу.

Я думаю, все согласны с тем, что было бы неплохо иметь команду «обновить мир», но IIUC она заблокирована, пока мы ждем, пока не завершится работа преобразователя. Тем временем я опубликовал более конкретное предложение по обновлению одного пакета в новом специальном выпуске @pradyunsg для этого обсуждения.

Я думаю, все согласны с тем, что было бы неплохо иметь команду «обновить мир», но IIUC она заблокирована, пока мы ждем, пока не завершится работа преобразователя.

На самом деле эта проблема теперь правильно заблокирована # 988. Упоминание номера проблемы для перекрестного связывания двух проблем.

Я почти забыл...

Я не совсем понимаю, что вы имеете в виду, говоря о "удержании" обновлений. Просьба уточнить.

Теперь, когда эта проблема предназначена исключительно для обновления всего, я должен уточнить.

В некоторых ситуациях может оказаться полезным предотвратить обновление определенного пакета при выполнении функции upgrade-all. В частности, я имею в виду ... Если pkg установлен, и я не хочу беспокоиться о повторной настройке потенциальной более новой версии, поэтому я хочу, чтобы pip не обновлял этот конкретный пакет при запуске 'обновить Мир'. По сути сдерживаю апгрейд pkg.

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

Добавить это, как только появится решатель SAT, должно быть легко. Это всего лишь несколько дополнительных пунктов IIUC. (Да, я тоже освежаюсь в решателях SAT)

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

Ах я вижу. Это имеет смысл и кажется разумным желанием.

Быстрый запрос: не мог бы кто-нибудь добавить к описанию крошечную заметку о том, что команда обновления не выполняется? Возможно, если хотите, напишите краткое изложение того, почему это так.

_{_ложится спать_}

Две приятные функции, которые есть в apt (и я думаю, что другие зрелые системные менеджеры пакетов, такие как dnf, имеют аналогичные функции):

• Пометка пакета как «удерживаемого» - это постоянный флаг, прикрепленный к пакету и заставляющий его пропускать с помощью команд upgrade-the-world. Часто устанавливается для пакетов, которые нужно было откатить до более ранней версии или исправить локально.
• Отслеживание того, какие пакеты были явно запрошены пользователем, а какие были установлены только неявно для выполнения ограничений зависимости. Последние могут быть удалены с помощью обновления мира, если от них перестают зависеть.

И то, и другое можно рассматривать как частные случаи того, что делают более поздние менеджеры пакетов среды проекта, такие как npm и cargo, когда они различают своего рода ориентированный на человека файл «требований» и полностью определенный файл «блокировки». Явно удерживаемый пакет похож на пакет, который имеет ограничение версии, заданное человеком, а явно установленный пакет - это тот, который указан в файле, доступном для редактирования человеком.

То же. Если мы добавляем «обновить мир», нам нужно добавить возможность отмечать пакеты (как held / user-installed и, возможно, больше), чтобы добавить информацию, чтобы лучше определить курс действий для обновления. Я считаю это требованием, а не желанием иметь.

Мне действительно нравится техника, используемая Cargo, и ей нравится. Использование файлов, а не какой-либо формы команды meta-data-hidden-behind-a-cli-command значительно упрощает понимание и управление, а также позволяет создать воспроизводимую среду.

Я был бы счастлив, если бы увидел какую-нибудь форму pyproject.lock ...

200-й комментарий. Ух ты. : смайлик:

Добавление ссылки на № 654 для «маркировки» пакетов, о которых мы говорили.

Вы можете объяснить, что делает груз? Где бы вы увидели, что файл pyproject.lock хранится на машине пользователя?

Файл блокировки Rust Cargo сохраняется в корне проекта для записи текущей установленной версии зависимостей. Фиксация этого файла в git позволяет вам делиться согласованным набором версий зависимостей с другими разработчиками и CI. В PHP Composer есть похожий файл блокировки Composer.lock.

Я всегда предполагал, что pip 'pip freeze' и 'pip install -r' предназначены для аналогичных действий, и было просто жаль, что формат файла блокировки был легко читаем / записан людьми, и люди предпочитают редактировать его напрямую. Был ли файл requirements.txt изначально задуман как файл блокировки?

@triplepoint Спасибо за объяснение. Это действительно больше похоже на файл требований. Но файлы требований не являются обязательными, зависят от версии и для каждого проекта. Маркировка (как я понимаю) должна быть для среды (virtualenv или установка системы) и должна просто сказать «не обновлять пакет X автоматически» (но разрешать обновление вручную, если пользователь явно запрашивает обновление этого пакета по имени).

Чтобы помочь распутать дискуссии о upgrade-all и «поведении при обновлении», вот комментарии от @rbtcollins и @ncoghlan в обсуждении последнего списка о том, что решатель SAT не требуется для первой реализации upgrade-all :

Роберт:

Я понимаю, что консенсус по поводу билета состоит в том, что он заблокирован, но я не
на самом деле согласен.

Да, вы не можете этого сделать _ правильно_ без полного преобразователя, но вы можете
приближение, которое было бы намного лучше, чем ничего (просто узкое
спецификаторы, указанные во всех требованиях). Это на самом деле
разумно, когда вы имеете дело с предположительно хорошим набором версий
(с которой установка не работает).

Ник:

«yum upgrade» годами работал достаточно хорошо без надлежащего решателя SAT, а пакет, установленный при типичной установке Linux, намного больше, чем в типичной виртуальной среде (хотя распространение действительно снижает вероятность возникновения противоречивых требований при первом запуске). место).

Тем не менее, повторный запуск pip-compile, а затем выполнение pip-sync уже является функциональным эквивалентом операции upgrade-all (как и уничтожение и воссоздание venv), поэтому я согласен, что нет необходимости объединять вопрос поддержки массовых обновлений в базовый пакет с изменением поведения при обновлении именованных компонентов.

ИМО, pip upgrade-all - безусловно, самое важное предложение из всех обсуждений "функциональности обновления". «Обновить все» даст очевидный способ поддерживать вашу систему в актуальном состоянии, делая вопросы о нежелательных обновлениях, оставляя вещи на более старых уровнях гораздо менее актуальными, а также заполняя пробел, который существует в настоящее время.

Хотя полный решатель был бы хорош, я не вижу причин, по которым отправной точкой для pip upgrade-all не должно быть то, что он делает то, что делает pip install -U <list every package that's installed here> . Это то, чего я ожидал как пользователь, и в большинстве случаев он делает именно то, что нужно. Сложные угловые случаи, связанные с противоречивыми требованиями, могут быть рассмотрены в первую очередь с помощью ссылки на вышеизложенное. Если этого недостаточно, то мы можем рассмотреть либо изменение поведения install -U для его решения, либо особый регистр команды update-all , либо даже реализацию полного решателя на этом этапе.

Собираетесь ли вы реализовать это в ближайшие 10 лет?

FWIW, я еще раз приеду в эти выходные.

@magicgoose сказал:
Собираетесь ли вы реализовать это в ближайшие 10 лет?

@pfmoore сказал это лучше, чем я:

Мы знаем, что люди хотят этого, чего не хватает, так это того, чтобы кто-нибудь хотел разработать исправление, которое учитывает все различные проблемы и проблемы, которые уже были подняты, и которые неизбежно возникнут во время проверки связи с общественностью.

Так что лично я был бы признателен, если бы люди воздерживались от проверки этой проблемы, если у них нет рабочего кода, который хотя бы предлагает отправную точку для реализации - и они готовы довести ее до реализации.

полностью личное мнение

я думаю по самой природе pip (который устанавливает пакеты из репо, у которого нет глобального QA, например, debian, redhat или ubuntu)
я считаю необходимым и / или приемлемым полностью отказаться от реализации и обновления всех функций,

так как мы когда-либо гарантируем известное состояние установленного набора пакетов python

@RonnyPfannschmidt IMO вполне разумно для пользователей pip явно запретить использование команды update-all, если это соответствует их требованиям / рабочему процессу. Но не все пользователи pip предъявляют такие же строгие требования, как эти люди. Для пользователей с более расслабленными потребностями полезна команда update-all, и ее отсутствие значительно усложняет поддержание их систем в «актуальном состоянии». Поэтому я думаю, что для pip разумно предоставить такую ​​команду. Наша работа - предоставлять инструменты, которые нужны людям, а не навязывать определенные политики в отношении того, как пользователи решают использовать эти инструменты.

@pfmoore мой личный опыт простого обновления всех пакетов в среде заключается в том, что это очень

пользователи, которым требуется расслабленное обновление, все звучат так, как будто вы имеете в виду обычных конечных пользователей (которые должны просто использовать обычный дистрибутив Linux, например)

Будет ли обновление проблематичным или нет, во многом зависит от того, сколько у вас зависимостей и насколько дисциплинированно они относятся к обслуживанию своего API. Его также можно использовать в сочетании с тщательно подобранным частным репозиторием, чтобы контролировать, какие обновления действительно происходят, вместо того, чтобы тщательно настраивать, какие команды обновления вы запускаете в каждой виртуальной среде.

@RonnyPfannschmidt Число пользователей Windows по-прежнему превышает число пользователей Linux ~ 18 к 1, и на данный момент у них нет ничего сопоставимого с сообществом управления пакетами дистрибутива (хотя основная технология присутствует в последних версиях, сообщества по упаковке и курированию нет). Это означает, что они гораздо больше полагаются на инструменты пользовательского уровня, такие как pip и conda, чтобы компенсировать слабину.

Мы знаем, что люди хотят этого, чего не хватает, так это того, чтобы кто-нибудь хотел разработать исправление, которое учитывает все различные проблемы и проблемы, которые уже были подняты, и которые неизбежно возникнут во время проверки связи с общественностью.

@pfmoore, знаете ли вы, что такие комментарии могут

Грубое изложение лишь его части (PR gh-3194):

1. Существует задокументированное решение о том, что команда upgrade приветствуется (в списке рассылки pip, а также в документации и на GitHub).
2. Затем известный разработчик (в данном случае @njsmith) сообщает, что реализация этой функции была бы очень ценной.
3. Появляется новый участник, все внедряет, быстро реагирует на все отзывы отзывов. PR готов к слиянию.
4. Основной участник меняет свое мнение о желании upgrade .
5. Далее следуют очень долгие дискуссии, но без заключения.
6. Автор сдается и исчезает (большинство людей расстраивают такие вещи).

И это было еще до того, как появился @pradyunsg , проявляющий удивительную настойчивость.

В хорошо работающем проекте основные разработчики, которым действительно небезразлична проблема, организуют быструю тусовку и примут какое-то решение. Или поручите одному или двум людям поработать достаточно, чтобы прийти к такому выводу. Или, по крайней мере, извинитесь и скажите спасибо тому, кто отправил PR, вместо того, чтобы обвинять его в «невыполнении».

Я знаю, что у вас самые лучшие намерения, но, пожалуйста, будьте осторожнее с такими комментариями.

Я думаю, что вполне разумно, чтобы требования и мнения менялись в ходе обсуждения, особенно в таких сложных вопросах, как этот, на которые нет правильного ответа. Часть получения патча в любой базе кода - это отслеживание изменений, которые хешируются в рамках обзора и обсуждения любых изменений. Некоторые изменения довольно минимальны и их меньше, у некоторых их больше. Нет ничего плохого в том, что человек решает, что не хочет иметь с этим дело, и уходит (каждая полоса добавления изменения вызовет некоторое снижение, включая тесты, документацию и т. Д.).

Это конкретное изменение особенно неприятно, потому что оно меняет поведение по умолчанию для основного использования pip. Это сложно и страшно, и для наших пользователей было бы медвежьей услугой, если бы мы поторопились и не продумали все до того, как перейти к тому или иному направлению. Эта команда используется от 10 до 100 миллионов раз в месяц. Это непростое и легкое изменение, и не те люди, которые занимаются этим вопросом, должны иметь дело с гневной реакцией, вызванной внесением каких-либо изменений.

Человек, который реализовал PR раньше, ценит свое время, но факт в том, что они не довели дело до конца. Поскольку основные разработчики здесь _ наше_ время ограничено, мы либо волонтеры, либо участвуем во многих проектах, и мы постоянно участвуем и прекращаем участие. Есть масса различных вопросов, требующих внимания, и это лишь одна из них. Пол просто заявил, что проверка этой проблемы бесполезна (а это не так) и что если кто-то этого хочет, ему нужно будет либо дождаться, пока кто-нибудь (включая одного из основных разработчиков) решит приложить значительные усилия для изменить поведение миллионов по умолчанию или сделать это сами.

Мы знаем, что люди хотят этого, чего не хватает, так это того, чтобы кто-нибудь хотел разработать исправление, которое учитывает все различные проблемы и проблемы, которые уже были подняты, и которые неизбежно возникнут во время проверки связи с общественностью.

@pfmoore, знаете ли вы, что такие комментарии могут

@rgommers Серьезно? Этот комментарий был сделан несколько месяцев назад и был здесь процитирован вне контекста (но, честно говоря, у меня нет проблем с тем, что

Если бы я был таким «вне базы», ​​то вы могли бы сказать это в мае в то время, когда я это сказал, а не зацикливаться на этом сейчас, вне контекста.

Если я кого-то обидел, прошу прощения, это не было моим намерением. Честно говоря, я так же разочарован, как и все остальные, из-за того, что эта проблема оказалась настолько трудной для достижения дизайна, который был бы приемлем для всех. В своих комментариях я пытаюсь найти баланс - с одной стороны, я искренне ценю вклад, который делают люди, но, с другой стороны, я считаю важным дать людям понять, что в подобной проблеме кодирование, откровенно говоря, требует меньше всего работы. Очень часто участники не понимают этого факта, и именно здесь мы получаем неполные PR, когда люди разочаровываются в работе, необходимой для того, чтобы убедить людей, что их дизайн в порядке, и / или переработать изменение, возможно, так, как они этого не делают. Очень нравится, чтобы учитывать чужие (часто противоречивые и противоречивые!) мнения. Я бы предпочел, чтобы они вошли в процесс с пониманием того, что вовлечено, чем приходили с нереалистичными ожиданиями и в результате имели плохой опыт.

Все участники дискуссии по этому вопросу потратили много времени на обсуждение плюсов и минусов различных подходов. Я не думаю, что есть кто-то, кто доволен тем, сколько времени это занимает. Лично меня регулярно поражает отсутствие команды upgrade-all (только одной части изменения, которая вряд ли будет реализована первой). Мы иногда (честно говоря, это намного больше, чем просто «иногда») заставляем людей (обычно людей, которые на самом деле не участвовали в обсуждении или коде) комментировать «это важно, почему вы еще не реализовали это?» Откровенно говоря, трудно сохранять спокойствие и _не_ огрызаться на таких людей.

В хорошо работающем проекте основные разработчики, которые действительно заботятся о проблеме

Вы понимаете, что этот комментарий можно интерпретировать как говорящий о том, что разработчики pip не заботятся об исправлении этого (и, косвенно, о pip)? Мы все рискуем сформулировать вещи так, чтобы обидеть людей. Я уверен, что вы не имели в виду критику разработчиков pip, пожалуйста, примите во внимание, что я точно так же не пытаюсь никого обидеть.

организует быструю тусовку и примет какое-то решение.

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

Или поручите одному или двум людям поработать достаточно, чтобы прийти к такому выводу.

То есть вы говорите, что такое важное решение должно приниматься в одностороннем порядке двумя людьми? Может быть, это единственный способ получить решение, но на самом деле решения в pip принимаются не так (в отличие от Python, у нас нет BDFL с полномочиями по принятию исполнительных решений). Вы можете утверждать, что это не делает нас «хорошо функционирующим проектом», если хотите, это не моя точка зрения, но мы можем не согласиться с этим, если хотите.

Или, по крайней мере, извиниться и поблагодарить автора PR,

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

Конечно же, он получил мою благодарность. Довольно легко сказать «это само собой разумеющееся», но это не должно быть так - проекты с открытым исходным кодом недостаточно благодарны участникам, и это проблема. Раз уж я затронул эту тему, я хотел бы поблагодарить всех, кто внес свой вклад в эту дискуссию - и я здесь совершенно серьезно, - поскольку я знаю по опыту, насколько это может быть истощающим. Но особенно @pradyunsg за то, что он стал жертвой всех бесконечных дискуссий и смены направления. Спасибо, что не сдались! (Пока что!!)

вместо того, чтобы обвинять его в «невыполнении».

Что ж, я не думаю, что в этом есть какая-то вина (хотя трудно сказать, чувствовал ли он себя виноватым, поскольку его больше нет рядом). Но это правда, что его первоначальный пиар не был доведен до конца. Но это просто факт. Я надеюсь, что никто не предполагает, что участники имеют право на то, чтобы их PR были приняты _ просто потому, что они их отправили_. Не все PR приемлемы при первой отправке, их нужно пересматривать и обновлять, а иногда даже после всей работы они все еще остаются неприемлемыми. Извини, но это жизнь.

[Если я показался мне резким в приведенном выше заявлении, приношу свои извинения (еще раз!). Но большую часть свободного времени я провожу за чтением и рассмотрением жалоб, которые я (или проекты, в которых я участвую) почему-то сделал недостаточно. И это порочный круг - я теряю мотивацию работать над открытым исходным кодом в свободное время из-за нытья, что, конечно же, означает, что делается еще меньше. Хотя я стараюсь оставаться вежливым, иногда это непросто]

Я не планирую больше ничего говорить в этой мета-дискуссии о том, как осуществляется управление PR. В этот вечер я потратил час, работая над этим ответом, чтобы не сказать ничего, что могло бы кого-то обидеть (и держу пари, что я потерпел неудачу :-(). И я мог бы гораздо лучше провести это время - с семьей, отдыхая, или заниматься чем-то более продуктивным.

Итак, могу ли я предложить нам вернуться к попыткам помочь @pradyunsg придумать пиар, которым мы все можем быть довольны, и прекратить бесплодные мета-дискуссии?

Итак, могу ли я предложить нам вернуться к попыткам помочь @pradyunsg придумать пиар, которым мы все можем быть довольны, и прекратить бесплодные мета-дискуссии?

Да, пожалуйста. :невиновный:

Ой, я забыл.

@rgommers сказал:
И это было еще до того, как появился @pradyunsg , проявляющий удивительную настойчивость.

Приму это как дополнение ... Спасибо.

@pfmoore сказал:
особенно @pradyunsg за то, что он в настоящее время является жертвой всех бесконечных дискуссий и смены направления. Спасибо, что не сдались!

Пожалуйста.

(Пока что!!)

Я очень надеюсь, что до этого состояния не дойдет. ИМО, это будет действительно плохое положение дел, если это произойдет. (Я такой высокомерный)

Я написал следующее, пока просматривал историю, и решил, что с таким же успехом могу разместить это здесь, для использования в будущем и позволяя другим поправлять меня на всякий случай.

• Решил поработать над этим после осознания того, каким должно быть большое соотношение нетехническое: техническое (оно намного больше, чем я _в действительности_ консервативно думал), и осознав, что уже была предпринята неудачная попытка сделать это.
• Сделал обзор положения дел, потому что мне было скучно, и мне все равно нужно было знать, что произошло.
  
  
  
  • Наверное, потратил на это больше времени (и места здесь?), Чем нужно, но, по крайней мере, я получил хорошее представление о проблеме для себя (и всех остальных?).
  
  
• После того, как написал это, был очень взволнован. : smiley: Я показал это миру!
• Инициировал (долгое !!!) обсуждение реализации команды обновления.
  
  
  
  • В ходе обсуждений возникло несколько полезных побочных идей. Для того же были созданы новые выпуски.
  
  
• Обсуждение приводит к идее изменить поведение установки на upstall, при котором по умолчанию будут выполняться неактивные обновления, а также удалена часть функций, предоставляемых параметром --target - 3 вещи.
  
  
  
  • Здесь мы допустили ошибку, объединив 3 (достаточно) независимых изменения, которые будут реализованы как одно, потому что никто не реализовал эту часть.
  
  
• Я реализовал то же самое. Поскольку 3 изменения были объединены в пакет, все они застряли, когда не было консенсуса по поводу изменения поведения установки на upstall, что является потенциально спорным изменением.
• Отсутствие консенсуса инициировало долгую дискуссию, которая дошла до того, что люди отказались от обсуждения и, я думаю, чуть не довели до выгорания.
  
  
  
  • Некоторые из предыдущих предположений были опровергнуты, и было решено, что сначала мы внесем минимальные нарушения.
  
  
• У меня закончилось свободное время, чтобы поработать над этим, поэтому я создал несколько новых задач, чтобы кто-то другой мог работать над ними независимо и, в идеале, не совершать ту же ошибку, что и мы.
• Заглох.
• Я вернулся! Я постараюсь переключиться на неактивные обновления по умолчанию до 25 сентября.

Да, давайте просто сосредоточимся на исправлении pip install --upgrade и пока оставим все остальное. В любом случае это требование для любой другой работы.

@pfmoore @dstufft спасибо за вдумчивые ответы. Я не хотел никого обидеть, поэтому извиняюсь, если это натолкнулось на это.

Я не буду на все отвечать, потому что здесь никто не ищет долгого обсуждения.

Вы могли бы сказать это в мае, когда я сказал это,

Тогда я отсутствовал на Github на 2 месяца, но меня это очень обеспокоило, когда я впервые увидел этот комментарий.

То есть вы говорите, что такое важное решение должно приниматься в одностороннем порядке двумя людьми?

Все варианты на столе намного лучше, чем статус-кво. И после 5,5 лет и многих сотен комментариев, разбросанных по множеству вопросов / PR здесь и в списке рассылки, я не уверен, что еще больше комментариев решат эту проблему. Я надеюсь, что он разрешится, но если это снова заглохнет, тогда определенно да - назначьте одного или нескольких человек и просто сделайте выбор.

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

Я имел в виду последнее. Иногда я меняю свое решение по поводу одного из моих проектов, и такое случается. Тогда я чувствую ответственность за то, чтобы четко обозначить новое направление. И извиняюсь, если у меня нет времени разбираться с последствиями этого изменения (занимает всего 30 секунд ....).

Но это правда, что его первоначальный пиар не был доведен до конца. Но это просто факт.

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

После вашего ответа я понял, что ожидания разработчиков pip от участников и разработчиков ядра сильно отличаются от почти любого другого проекта, с которым я знаком. Я ожидаю, что основные разработчики будут направлять новых участников, поощрять их, давать им обратную связь там, где это необходимо, и помогать им решать спорные вопросы (которые у большинства участников нет ни навыков, ни интереса, а те, которые часто в конечном итоге становятся основными разработчиками), если нужный. Вы говорите новым участникам: _ "вы должны управлять нами. Мы можем изменить свое мнение, не соглашаться друг с другом или потерять интерес - это ваша работа - управлять этим" _. Может быть, такова природа этого проекта, и так должно быть, я не знаю.

Раз уж я говорю об этом, я хотел бы поблагодарить всех, кто участвовал в этой дискуссии.

Согласованный. Спасибо всем, кто внес свой вклад.

• и я здесь совершенно серьезно - как я знаю по опыту, насколько это может быть истощающим.

Это истощает. Лично я остаюсь здесь и на distutils-sig, потому что это важно для экосистемы Python и пользователей моих пакетов, но оба места не дают мне положительной энергии.

На всякий случай проскользнул под радар - # 3972: smile:

Вы говорите новым участникам: «Вы должны управлять нами. Мы можем передумать, не соглашаться друг с другом или потерять интерес - это ваша работа». Может быть, такова природа этого проекта, и так должно быть, я не знаю.

Я сказал, что не буду продолжать, но это меня поразило. Я не так отношусь к нашему подходу, но теперь, когда вы так выразились, я вижу, что это может показаться иным. Честно говоря, «мы можем изменить свое мнение, не соглашаться друг с другом или потерять интерес» - это правда - в конце концов, мы все тоже люди с другими обязательствами - но я не считаю это чем-то, что должен делать новый участник. "управлять". Скорее, это просто реальность общения с людьми, но если слишком много внимания уделяется тому, чтобы перекладывать проблему на новых участников, это неправильно.

Спасибо, что указали на это - я постараюсь иметь это в виду и не создавать такого впечатления в будущем.

Я думаю, что большая часть проблемы на самом деле сводится к тому факту, что мы сильно недоукомплектованы персоналом, что в конечном итоге затрудняет отслеживание и отслеживание всего. Потенциальных участников больше, чем нас, поэтому легко почувствовать себя ошеломленным, когда несколько человек пытаются внести изменения одновременно. Более серьезные изменения или изменения, в отношении которых нет четкого консенсуса, как правило, являются самыми трудными для решения, поэтому именно они, как правило, страдают больше всего :(

Печальное положение дел состоит в том, что, хотя я думаю, что все мы хотели бы быть здесь, чтобы помогать каждому участнику в процессе, у нас просто нет человеческих сил. Это также имеет тенденцию иметь немного вязкий цикл, потому что у нас нет человеческих сил для этого, мы с трудом находим новых людей, которые, кажется, действительно начали ломать голову над тем, как работает пипс, и которые научились достаточно (потому что мы не там, чтобы их учить), чтобы дать им права на коммит для pip. Это означает, что мы постоянно недоукомплектованы персоналом и изо всех сил пытаемся удержать голову над водой (по крайней мере, я так чувствую. Постоянные 70-90 часовые недели очень тяжело для человека: /).

@pradyunsg Reviewing # 3972 находится в моем списке TODO, просто еще не попал в него.

@pradyunsg Reviewing # 3972 находится в моем списке TODO, просто еще не попал в него.

Спасибо!

Это означает, что мы постоянно недоукомплектованы персоналом и изо всех сил пытаемся удержать голову над водой (по крайней мере, я так чувствую. Постоянные 70-90 часовые недели очень тяжело для человека: /).

Это сложно. Нумпи и Сципи были в такой ситуации, когда я начал над ними работать. Не смешно. Я ценю все, что ты делаешь.

Эта проблема сейчас очень длинная и очень старая, много чего обсуждалось, слишком много вещей произошло, и эта проблема почти достигла низкого уровня сигнал / шум. Трудно понять, что все произошло.

FWIW, причина того, что upgrade была на картах, заключалась в том, что install --upgrade имеет неверное значение по умолчанию. Поскольку мы сейчас на один шаг ближе к решению этой проблемы, я думаю, что лучше у нас есть для этого новая проблема.

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

• Измените стратегию обновления по умолчанию на only-if-needed .
• Добавьте функцию «обновить мир», зависящую от # 988.

15.09.16 Ник Коглан на [email protected] написал:

@RonnyPfannschmidt Число пользователей Windows по-прежнему превышает число пользователей Linux ~ 18: 1, и
у них нет ничего похожего на сообщество управления пакетами дистрибутива
вернуться к этому моменту (в то время как основная технология присутствует в недавнем
версий, сообщества упаковки и курирования - нет). Это означает, что они
гораздо больше полагаться на инструменты уровня пользователя, такие как pip и conda, чтобы подобрать
слабина.

Не тогда
conda update - все
достаточно хорошо?

@ Liso77
Ну, нет. Это не так.

Conda и pip - инструменты с разными целями. Это отличное чтение по этой теме. Третий пункт наиболее актуален.

Если обсуждение обновления всех всплывет снова (надеюсь, в новом выпуске), я голосую за то, чтобы написать его следующим образом:

pip install --upgrade :all:

pip install --upgrade :all: очень странно. Давайте придерживаться семантики POSIX, которой в настоящее время пользуются практически все: pip install --upgrade --all

А как насчет всего pip install --upgrade без имен пакетов или спецификаторов? Чтобы просто случайно запустить?

pip-tools делает это для pip-compile -P .

Может быть, нам стоит навес для велосипедов, когда у нас будет какая-то работа
выполнение... :)

Вс, 12 февраля 2017 г., 20:55 FichteFoll [email protected] написал:

Как насчет просто pip install --upgrade без имен пакетов или
спецификаторы? Чтобы просто случайно запустить?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/pypa/pip/issues/59#issuecomment-279225595 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ADH7SfnSBflH8rK3nFLw1hvYBaovjbcGks5rbyRUgaJpZM4AJ4Py
.

Как насчет версии pip list --outdated которая создает свой список в формате, который может быть напрямую (т. Е. Без sed , cut и т. Д.), Загружен pip install --upgrade (например, pip list --outdated --format install | xargs pip install --upgrade или что-то подобное с обратными кавычками)?

какой бы синтаксис не использовался, самое главное - представить эту команду. Невероятно, что она все еще отсутствует.

А пока я предлагаю вам попробовать
https://github.com/jgonggrijp/pip-review
с pip-review --local --interactive спрашивать пакет за пакетом, если вы хотите обновить, не очень хорошо, но лучше, чем ничего

@ SMH17 Вполне

Так что если вы хотели бы видеть ситуацию улучшить, вполне вероятно , что самая полезную вещь , которую вы лично можете сделать это либо поощрять ваш поставщик поддержки Python инвестировать время разработчика в улучшении инструментов вы используете, или если вы не имеете поддерживайте поставщика, поощряйте своего работодателя заплатить его.

В качестве дополнительного контекста относительно отсутствия срочности решения этой проблемы стоит помнить, что общие рекомендации заключаются в следующем:

• держите определения рабочей среды под контролем источника, чтобы улучшить воспроизводимость в других системах (используя что-то вроде https://github.com/jazzband/pip-tools или https://github.com/kennethreitz/pipenv, чтобы поддерживать эти определения в актуальном состоянии )
• стремиться к регулярному обновлению до новых выпусков зависимостей, чтобы минимизировать окна подверженности неизвестным или нераскрытым уязвимостям безопасности

Это не означает, что предложенные здесь команды бесполезны, они просто заметно менее ценны, если текущая рабочая среда уже поддерживается через pip-compile + pip-sync или pipenv lock + pipenv install .

Было бы полезно обновить исходное описание, поскольку я предполагаю, что с момента обновления, сделанного @qwcode, в pip install были внесены некоторые изменения.

Всем привет.

Я нарушил некоторые зависимости пакета python из-за следующей команды:

pip install --upgrade packageName рекурсивно обновил пакеты.

Почему бы не изменить поведение параметра --upgrade по умолчанию, то есть удалить и переустановить ТОЛЬКО данный пакет из командной строки?

Как насчет этого ?

@sebma Я считаю, что поведение по умолчанию менять нельзя. Может быть, вы могли бы попробовать использовать флаг -no-dependencies в следующий раз. Должно сработать: +1:

@sebma , @aaossa , я --upgrade-strategy ) добавлена ​​в https://github.com/pypa/pip/pull/3972.

Как упоминал ранее @pradyunsg , эта проблема

Я выпустил красивое интерактивное средство обновления для файла требований: https://github.com/simion/pip-upgrader

Измените стратегию обновления по умолчанию на «Только при необходимости».

4500 сделали это.

Добавьте функцию «обновить мир», зависящую от # 988.

4551 за обсуждение этого вопроса.

Обращение к пунктам, высказанным в текущем топ-посте:

Обновление pip будет похоже на pip install --upgrade, за исключением того, что по умолчанию оно будет нерекурсивным (и предлагать параметр --recursive). Это текущее рекурсивное поведение по умолчанию многих огорчило (# 304). О том, как сейчас делать нерекурсивные обновления, смотрите здесь.

Было решено не добавлять команду обновления или делать pip install обновлением уже установленных пакетов. pip теперь имеет нерекурсивные обновления по умолчанию, с рекурсивным поведением, доступным за --upgrade-strategy eager .

pip upgrade-all обновит все установленные пакеты.

4551 существует, и было бы неплохо провести новое обсуждение по этому поводу; когда # 988 будет готов.

@dstufft @xavfernandez @pfmoore Кто- нибудь из вас считает, что эту проблему следует закрыть?

_{Изменить (18.05.2017): добавлена ​​пунктуация + дополнительный текст}

Кажется разумным.

Привет всем,
Я сделал простой сценарий / суть, который выполняет свою работу.

https://gist.github.com/serafeimgr/b4ca5d0de63950cc5349d4802d22f3f0

Почему бы просто не сделать это?

pip install --upgrade $(pip list --outdated | awk '{print $1}' | tr '\n' ' ')

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

На основе и благодаря @serafeimgr «s сути , я написал , возможно, полезный инструмент командной строки, pip_upgrade_outdated ; источник на github . Обратная связь приветствуется.

(См. Также этот вопрос : да, параллельное выполнение особенно опасно, и, да, это может что-то сломать. Тем не менее многие люди все время запускают что-то подобное вручную, поэтому могут найти это полезным.)

Спасибо за то, что нашли время для создания полного решения.
Хотя я бы порекомендовал найти способ продвинуть эту функцию до пипса.

Я думаю, что pipenv и pipfile все равно заменят pip / requirements.txt.
Возможно, @kennethreitz знает больше о дорожной карте и функции --upgrade all.

@qoheniac | tr ... является избыточным.

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