Хм, может быть, нам нужна команда для вывода списка всех версий пакетов, доступных в PyPI.
Что ты думаешь?

Нравиться:

$ pip list Django

1.2.4

1.2.3

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

$

Original Comment By: Hugo Lopes Tavares

мне нравится эта идея.

Original Comment By: CarlFK

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

Проверьте это здесь: https://bitbucket.org/hltbra/pip-list-
команда/набор изменений/e5c135a46204

Original Comment By: Hugo Lopes Tavares

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

Original Comment By: Carl Meyer

Я был бы согласен добавить это в поиск, пока мой другой ER реализован
также, чтобы я не получал 3000 строк (на самом деле), когда я ищу версии django.
(более 1000 обращений к «pip search django» из-за всех django-foo
пакеты. )

Original Comment By: CarlFK

Я думаю, что нет необходимости показывать, какая версия будет установлена, пока
есть список доступных версий, ведь легко определить какая из
это последние. Кроме того, нет причин использовать новый флаг для
включить вывод этого списка, потому что накладные расходы стремятся к нулю. Это
просто небольшое изменение:
https://bitbucket.org/jumpa/pip/changeset/62076643cf33

Original Comment By: jumpa

Привет, Карл, я хотел добавить опцию в команду поиска, но я боюсь
произошло то, что произошло с командой установки: если вы хотите «обновить»
package, вам нужно использовать опцию «установить» — это странно, и мы это знаем.

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

Original Comment By: Hugo Lopes Tavares

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

И я согласен с CarlFK, что нам также нужны улучшения, чтобы сделать поиск
проще сузить. Проблема в том, что мы зависим от того, что дает нам API PyPI,
что немного: мы не собираемся загружать весь PyPI и делать регулярное выражение
ищите на месте! Я бы предпочел что-то вроде флага --exact для поиска как
часть этого изменения, поэтому вы можете искать, например, "--exact django" и получать только
сам django в вашем результате.

Original Comment By: Carl Meyer

Привет Jumpa, Отличная идея показать версии, используя версию, полученную из xmlrpc.
связь!

Я получил следующий фрагмент в поисках пункта:

pip                       - pip installs packages.  Python packages.  An

замена easy_install (версии: 0.2, 0.2.1, 0.3, 0.3.1, 0.4, 0.5, 0.5.1,
0,6, 0,6,1, 0,6,2, 0,6,3, 0,7, 0,7,1, 0,7,2, 0,8, 0,8,1, 0,8,2)

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

Original Comment By: Hugo Lopes Tavares

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

pip list Django


1.2.4

1.2.3 installed

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

Примечание. Многие популярные менеджеры пакетов, такие как YUM(RedHat), pkglist(BSD),
dpkg(Debain) предоставляет отдельный флаг списка или команду.

Original Comment By: Kelsey Hightower

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

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

Это немного странно.

Попробуем проиллюстрировать:

$ pip search -v --exact Django

против

$ pip list Django

Идея Келси показать, какая версия установлена, только улучшает список.
команда.

Original Comment By: Hugo Lopes Tavares

Я внес изменения в команду поиска.

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

Вот мой набор изменений: https://github.com/phuihock/pip/commit/46bad23b5bf31850a02803ea1ca18be5deca9db3

Каков статус с этим? Можно ли увидеть последнюю доступную версию PyPI с помощью pip?

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

Просто хотел добавить сюда, что я только что наткнулся на эту ветку, выполняя поиск того, как показать версии... Я попробовал pip search -v package - каким-то образом это имело бы для меня интуитивный смысл: подробное описание пакета для быть установлен, включая информацию о версии...

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

Я считаю, что этот PR может быть актуальным, над которым в настоящее время работают?

Вас также может заинтересовать доклад Linuxconf 2014 «Python Packaging 2.0: игра с другими» о текущей ситуации и будущем упаковки Python. Спикер сказал (если я правильно понял), что некоторые ограничения метаданных в pip являются следствием дизайна PyPI, который изначально был основан на CPAN, и что переработка бэкэнда PyPI (при этом оставаясь совместимым с текущим с использованием тестов) должны улучшить ситуацию. В основном он говорил о «системных интеграторах», т.е. о нижестоящих упаковщиках, но я предполагаю, что это повлияет на такие вещи, как эта проблема, и упростит их решение.

+1 000 000

и как сейчас?

Теперь, есть ли способ показать, какая версия является последней, не устанавливая ее?
Эта проблема открыта с 2011 года, и патч, который я видел выше, состоит всего из одной строки. :(

Это похоже на второстепенную функцию для включения, как на данный момент нет опции, эквивалентной apt-cache madison ?

Мне бы очень хотелось увидеть последнюю версию пакета PyPi при поиске. Точное совпадение работает, но я использую awk как обходной путь.

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

wget -qO- https://pypi.python.org/pypi/uWSGI | egrep -o "uwsgi-[0-9].[0-9].[0-9][0-9].tar.gz" | сортировать -у

wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep '"version"'

@andreif Это не всегда найдет правильную версию (pip игнорирует альфа-версии, бета-версии, кандидаты на выпуск и т. Д., Если не указан --pre). Это ближе (но и без гарантий):
wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep -E ' {8}"[0-9."]*": \[' | sort -V | tail -n 1 | tr -d ' ":['

Хорошо, тогда ответ JSON должен включать что-то вроде "pre-version": "1.2.3a4" , чтобы можно было найти их оба с помощью простого выражения.

Я не очень понимаю этот вопрос... О чем это?

• Добавление новой опции в pip install , которая заставит pip работать только до разрешения пакетов и печати выбранных пакетов и выхода (пропуская установку)?
• Отображение последней версии рядом с именами пакетов при использовании pip search ?
  
  
  
  • Возможность увидеть последнюю версию пакета на PyPI?
  
  

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

@pradyunsg Ну, если я правильно помню, мне нужен был простой способ проверить, какая версия доступна в настоящее время (как релизная, так и предварительная). Эта версия будет установлена pip install -U [--pre] .

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

pkg="foo"; pip install --download /dev/null --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

Опубликовать --download -устаревшую версию...

pkg="foo"; tmp="$(mktemp -d)"; pip download -d "$tmp" --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | tr A-Z a-z | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

Используя что-то вроде:

pip install foo==

дает список всех доступных версий (для действительного доступного пакета pypi, в данном случае molecule):

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

но было бы неплохо иметь возможность получить версию, которая будет установлена ​​с помощью pip, без фактической загрузки и/или установки в dev/null :-)

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

pip-tools — это инструмент, основанный на pip, который, я считаю, может помочь с некоторыми вещами, о которых спрашивают люди в этой теме: https://github.com/jazzband/pip-tools

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

pkg="django"; echo "$pkg" | pip-compile - --output-file - | egrep -i '^'"$pkg"'=' | cut -d '=' -f 3- примерно так же глупо (более глупо, если вы считаете, что это еще одна вещь, которую вам нужно установить [дальше глупо, если вам нужна поддержка python2])

Более того, весь смысл pip-tools (и pipenv) можно реализовать с помощью простого pip и файла ограничений. ( pip install -r reqs -c constraints; pip freeze > constraints ).

Добавление новой опции в pip install , которая заставит pip работать только до разрешения пакетов и печати выбранных пакетов и выхода (пропуская установку)?

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

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

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

Поскольку этот тикет заблокирован разработкой распознавателя зависимостей (#988), я решил упомянуть здесь, что команда ищет помощи у сообщества, чтобы продвинуться вперед в этом вопросе.

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

1. Попробуйте новый преобразователь (используйте версию 20.1, запустите --unstable-feature=resolver )
2. Сломай его :Р
3. Сообщить о проблеме

Вы можете найти более подробную информацию и более подробные инструкции здесь

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

Мы разрабатываем метод упаковки для больших, как правило, приложений машинного обучения в Twitter, которые мы называем «ipex», которые можно отправлять без стороннего кода до их первого запуска (что значительно уменьшает их размер). В случае pantsbuild/pants#8793 мы создаем исполняемый pex-архив, который вызывает библиотеку времени выполнения pex для решения требований (pex выполняет pip под прикрытием). В настоящее время я работаю над прототипом, который заменяет шаг полного разрешения pex/pip во время выполнения заменой, которая записывает только URL-адреса для загрузки дистрибутивов ( req.link ). На практике это очень быстро (и может кэшироваться очень детально), поскольку загрузка и копирование файла для создания «гидратированного» pex-файла могут выполняться полностью параллельно.

Эта возможность (параллельная загрузка и установка множества колес/не колес) зависит от дополнительного просто раскрытия URL-адреса любого колеса или не колеса, который мы поместили бы в файл блокировки, о котором я еще не упоминал здесь. Это позволяет штанам вызывать pip ровно один раз (для разрешения URL-адресов загрузки) при создании обезвоженного файла ipex, а затем результат этого шага «разрешения» с URL-адресами может быть использован для загрузки требований, когда файл ipex впервые вызывается на полностью другую машину без повторного вызова pip.

В #7819 потребовалось много усилий, чтобы распространить URL-адреса из внутренностей распознавателя v1 на выход. Было намного меньше усилий, когда я в последний раз пытался заставить его работать с преобразователем v2. Прямо сейчас мы, вероятно, планируем выпустить экспериментальную версию внутренней команды --dry-run или resolve , которая выдает URL-адреса для загрузки. оставшиеся проблемы с --unstable-feature=resolver тем временем! :Д :Д

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

Спасибо за ссылку!!

Вс, 24 мая 2020 г., 19:34, Цзы-пинг Чанг, notifications @github.com
написал:

Как вы упомянули, дизайн формата файла блокировки ортогонален
реализация резольвера. Однако это также означает, что он выходит за рамки
текущий пип-проект. Были обсуждения на тему
https://discuss.python.org/t/structured-exchangeable-lock-file-format-requirements-txt-2-0/876/1
(предупреждение: очень длинная ветка), но учитывая нехватку времени разработчика
доступны, это, в свою очередь, означает, что серьезного обсуждения, скорее всего, не будет.
произойти до того, как резольвер, по крайней мере, стабилизируется.

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

@cosmicexplorer Вы уже отправили эту экспериментальную версию команды --dry-run или resolve для внутреннего использования? Если да, то как дела?

Вы могли заметить, что я очень заинтересован в этой функции 😄

Используя что-то вроде:

pip install foo==

дает список всех доступных версий (для действительного доступного пакета pypi, в данном случае molecule):

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

но было бы неплохо иметь возможность получить версию, которая будет установлена ​​с помощью pip, без фактической загрузки и/или установки в dev/null :-)

Хороший трюк !! Полезно и удобно!! Действительно впечатляет!!

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

Не зря, правда, но это то, что происходит, когда вы позволяете ошибке задерживаться очень долго (7,56 года в случае моего самого последнего добавленного «самородка», хотя этой все еще открытой ошибке уже 9,25 года). Старый). Люди делятся своими обходными путями.

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

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

Не волнуйтесь, я, например, больше не буду добавлять неспровоцированные комментарии, если pip снова не сломает мой скрипт и эта ошибка все еще не устранена.

Спасибо за то, что вы делаете. :)

@brainwane @ei8fdb Я хочу отметить эту проблему как важную с точки зрения UX, связанную с #8377.

Резюме высокого уровня, основанное на моем понимании:

• с новым распознавателем pip будет менее разрешительным и откажется устанавливать конфликтующие зависимости ( ResolutionImpossible )
• конфликты зависимостей могут существовать в любом месте дерева зависимостей
• существующие инструменты (pipdeptree pip-conflict-checker) показывают только те пакеты, которые уже установлены, а не те, которые были запрошены, но не удалось
• В настоящее время у пользователей нет возможности выяснить, где возникает конфликт зависимостей _до_ установки пакета или при возникновении ошибки ResolutionImpossible (кроме ручной проверки зависимостей каждого проекта).

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

Если мы решим это сделать, предлагаемое имя флага ( --dry-run ) должно быть исследовано/обсуждено.

@uranusjr @pfmoore - пожалуйста, поправьте меня, если я что-то не так понял или что-то упустил из-за нашего обсуждения. Спасибо

@nlhkabu Я согласен со всеми вашими комментариями выше. Однако, чтобы было ясно, стиль команды --dry-run позволит пользователям проверить, не возникнет ли конфликт зависимостей. Но, как описано, он не предлагает никакой дополнительной помощи в диагностике возникновения конфликта. Таким образом, это в основном команда установки «посмотри, прежде чем прыгать», в отличие от обычного подхода «попроси прощения», когда мы устанавливаем, если можем, но ничего не делаем и сообщаем об ошибке, если нет.

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

Это также может принимать форму команды pip resolve .

pip resolve - это то, что большинство ожидает, пожалуйста, назовите это так 😄 В конечном итоге это также позволит использовать свои собственные флаги.

Спасибо за разъяснение @pfmoore. С точки зрения пользователя, я не уверен, сколько использования --dry-run без resolve ?

ИМО, недостаточно сказать пользователям, что они получат ошибку — нам также нужно предоставить им достаточно информации, чтобы найти , где она находится, и что-то с этим сделать.

Итак, представьте, что пользователь запускает --dry-run ... мы могли бы включить что-то вроде этого в ответ:

Обнаружен конфликт зависимостей. pip не сможет установить d 1.0 и c 1.0.
Причиной конфликта являются:
d 1,0 зависит от E==2,0
c 1,0 зависит от E==1,0
Запустите pip resolve , чтобы проверить дерево зависимостей.

Мы также могли бы повторно использовать pip resolve в сообщении об ошибке ResolutionImpossible (см. #8377), что было бы большой победой.

@pradyunsg у нас есть отдельный билет на pip resolve ?

@nlhkabu https://github.com/pypa/pip/issues/7819

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

1. перенаправить вывод в файл (который обычно фиксируется) или
2. другие инструменты будут использовать/анализировать вывод

Для твиттера с помощью инструмента «ipex», как описано в #7819, мы создаем исполняемые pex-файлы с помощью команды pip resolve , которая будет выводить URL-адреса загрузки для всех разрешенных дистрибутивов вместо того, чтобы загружать что-либо (еще не используется в производстве). ). Это, наряду с несколькими другими оптимизациями, например #8448, позволяет создавать эти файлы ipex за считанные секунды. Затем эти файлы ipex загружают все дистрибутивы, выводимые командой pip resolve , при первом их выполнении из того же центра обработки данных — это позволяет самим файлам ipex иметь размер в мегабайтах, а не в гигабайтах, что сокращает время загрузки. из многих регионов.

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

Есть новости по этому поводу?

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

Пожалуйста, поправьте меня, если я ошибаюсь, но следующее кажется правдой:

• Установка пакета Python включает в себя выполнение его setup.py.
• Без опции --dry-run нет простого и надежного способа узнать, какие пакеты резолвер pip выберет для установки.

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

Это зависит от того, имеет ли устанавливаемый проект и версия только исходный дистрибутив (sdist, содержит setup.py) или также колеса (встроенный дистрибутив, содержит текстовый файл метаданных, устанавливается копиями файлов без запуска произвольного кода)

Даже с --dry-run вполне вероятно, что pip потребуется запускать бэкэнды сборки для пакетов (что для setuptools включает запуск setup.py), у которых нет колес.