Pipenv: Обновление только одной заблокированной зависимости

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

Здесь нужно учесть одну небольшую вещь: изменение одной зависимости может изменить общий набор требований.
Пример: для обновления foo с 1.0 до 2.0 может потребоваться обновить bar до> = 2.0 (раньше было <2.0) и т. Д.

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

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

Надеюсь, это поможет!

Действительно, именно это я имел в виду под:

Это приведет к созданию файла Pipfile.lock с обновлениями только для my-awesome-dep и его зависимостей.

Согласитесь на 100% - и я пойду дальше: это должно быть по умолчанию.

То есть pipenv install foo никогда не должен касаться ничего, кроме foo и его зависимостей. И pipenv lock никогда не должен ничего обновлять - он должен просто блокировать то, что уже установлено.

AFAICT, вот как работают npm , yarn , gem и т. Д .; нет смысла иметь файл блокировки, который на самом деле не блокирует пакеты, но доверяет авторам пакетов, чтобы они не ломали вещи в выпусках исправлений, и поэтому обновляет их без запроса. Я вижу смысл в разрешении обновлений, но это должно быть согласие, поскольку это более удивительно, чем не обновлять их.

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

Просто нашел и эту связанную проблему: https://github.com/kennethreitz/pipenv/issues/418

Возможность указать pipenv install --upgrade-strategy=only-if-needed кажется мне тем, что я ищу, хотя, конечно, как я уже упоминал, я думаю, что это должно быть по умолчанию, поскольку оно становится в пипе 10. Но возможность указывать его полупостоянно через В любом случае, env var будет чем-то.

Я был бы удивлен, если бы это изменение нарушило чей-либо рабочий процесс ( известные последние слова ), поскольку оно более консервативно, чем --upgrade-strategy=eager .

Пытался обойти это, установив export PIP_UPGRADE_STRATEGY=only-if-needed в конфигурации моей оболочки. Это не работает, и pipenv lock демонстрирует следующее удивительное поведение:

1. Он «обновляет» пакеты, которые не нужно обновлять (но ...)
2. На самом деле он не обновляет установленные версии! т.е. pip freeze и Pipfile.lock показывают разные версии!

Предполагается, что pipenv делегирует установку pip, и pip уважает настройки переменных среды, а pipenv lock - нет.

@ k4nar Что происходит сейчас, когда вы считаете нежелательным? Потому что, если вы обновляете зависимость, которая имеет каскадные требования, очевидно, это будет иметь последствия для других зависимостей. Вы предлагаете какую-то логику преобразователя для определения самой последней версии определенного пакета _ в контексте текущего файла блокировки_? Я не решаюсь поощрять слишком много взломов логики разрешения, которая уже сложна и трудна для отладки.

@brettdh Я думаю, что могу пролить свет, потому что у вас есть большинство деталей. pipenv lock ничего не устанавливает и не претендует на это. Он генерирует только файл блокировки с учетом среды вашего хоста, версии Python и предоставленного Pipfile . Если вы манипулируете своей средой каким-либо другим способом или если вы используете pip напрямую / управляете настройками pip вне pipenv /, не используете pipenv run или не используете pip freeze внутри подоболочки pipenv, это довольно легко сделать файл блокировки не синхронизирован с pip freeze . Эти двое на самом деле не связаны.

Чтобы было ясно:

1. Pipfile.lock - это строго закрепленное разрешение зависимостей с использованием преобразователя pip-tools на основе пользовательского Pipfile
2. Если вы хотите поддерживать строгие контакты всего при обновлении только одного пакета, я считаю, что вы можете сделать это, строго закрепив все в своих Pipfile кроме одной вещи, которую вы хотите обновить (поправьте меня, если я ошибаюсь @vphilippon)

Что касается вашего файла блокировки и pip freeze не согласны друг с другом, мне нужно было бы узнать больше информации, но я считаю, что у нас есть открытая проблема, связанная с нашим преобразователем файлов блокировки при использовании для решения несистемных версий python.

@techalchemy : если у меня есть Pipfile.lock с A, B и C, где B является зависимостью от A, я хотел бы иметь возможность обновлять A и B без обновления C или C без обновления A и B.
Опять же, конечно, я могу закрепить все свои зависимости и их зависимости в моем Pipfile, чтобы сделать это, но это будет бременем для поддержки (как и большинство requirements.txt ).

Я согласен со всем, что написал
все в файле requirements.txt и не используйте pipenv. Смысл pipenv в
иметь один инструмент, который делает это (и, конечно, вещи virtualenv)
проще в управлении; т.е. все пакеты по умолчанию заблокированы для версии
известно, что это работает, но обновить выбранную
немного (без неожиданного обновления других).
В чт, 26 октября 2017 г., в 4:28 Янник ПЕРУ [email protected]
написал:

@techalchemy https://github.com/techalchemy : Если у меня есть Pipfile.lock
с A, B и C, где B является зависимостью от A, я хотел бы иметь возможность
обновить A и B без обновления C или C без обновления A и B.
Опять же, конечно, я могу закрепить все свои зависимости и их зависимости в моем
Pipfile для этого, но это будет бремя для поддержки (например,
большинство требований.txt есть).

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kennethreitz/pipenv/issues/966#issuecomment-339591307 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAFlnqUOEKARiFD8kEk3GVczF3NXBdVOks5swEKcgaJpZM4QEf--
.

Хм, я понимаю, что вы говорите. Предпосылка передачи параметра в pip - это не то, о чем я беспокоюсь, это решение с помощью pip-tools, которое меня беспокоит. Как это поведение выглядит сейчас?

@techalchemy Я упомянул pip freeze как сокращение для «версии пакетов, которые устанавливает pipenv install отличаются от версий пакетов, которые pipenv lock сохраняет в Pipfile.lock ».

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

Не могли бы вы немного уточнить свой вопрос? Я думаю, что «разрешение с помощью pip-tools» относится к тому, что делает pipenv lock , и почему это не влияет, когда я устанавливаю значения по умолчанию для pip? И не могли бы вы уточнить, что вы подразумеваете под «этим поведением»?

@brettdh Механизм блокировки включает понятие «разрешения зависимостей», которого нет в pip . Он обрабатывается pip-tools (или, скорее, его исправленной версией, особым образом интегрированной с помощью pipenv что вносит некоторые отличия от исходного инструмента). Короче говоря, механизм блокировки считывает Pipfile и выполняет полное разрешение зависимостей для выбора полного набора пакетов, который будет соответствовать всем ограничениям, определенным требуемыми пакетами и их зависимостями .

@techalchemy

[...] это решение с помощью pip-tools, что меня беспокоит.

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

«Исходное» поведение pip-tools заключается в том, что он обновляет только то, что необходимо в файле блокировки (в его контексте, это файл requirements.txt), но это было «потеряно» из-за того, как преобразователь был интегрирован в pipenv . Позвольте мне объяснить почему.

Возвращаясь к моему резюме о том, как работает pip-tools : https://github.com/kennethreitz/pipenv/issues/875#issuecomment -337717817
Помните часть «выберите кандидата»? Это делается путем запроса объекта Repository .
В pipenv мы напрямую настраиваем PyPIRepository для Resolver , но pip-tools делает что-то еще, он использует объект LocalRequirementsRepository , который сохраняет существующие контакты из ранее существовавших requirements.txt (если они есть) и «запасные» на PyPIRepository .

Итак, в pip-tools при выборе кандидата происходит следующее:

1. Запросите LocalRequirementsRepository кандидата, соответствующего foobar>=1.0,<2.0 .
2. Проверьте, соответствует ли существующий вывод этим требованиям:
   
   
   
   • Если да, верните этот значок в качестве кандидата.
   
   
   • Если нет, запросите proxied_repository ( PyPIRepository ) для кандидата.
   
   
3. Использовать возвращенного кандидата

По сути, это означает, что существующие контакты получают «приоритет» как кандидаты на попытку первыми.

Но в настоящее время в pipenv это просто:

1. Запросите PyPIRepository (напрямую) для кандидата, соответствующего foobar>=1.0,<2.0 .
2. Воспользуйтесь возвращенным кандидатом.

Итак, я думаю, что такое же поведение для блокировки в pipenv можно было бы сделать, проанализировав Pipfile.lock чтобы получить существующие контакты и использовать LocalRequirementsRepository , например pip-tools делает в своей команде pip-compile .

@vphilippon, представляете ли вы, насколько сложной будет эта реализация?

@techalchemy

• Разбор Pipfile.lock для извлечения существующих контактов: не смотрел на это. Зависит от того, как все устроено в pipenv . Нам нужен набор InstallRequirements который представляет контакты в Pipfile.lock .
• Использование LocalRequirementsRepository : Довольно просто: замените текущий PyPIRepository на LocalRequirementsRepository .

Но, изучая это и следуя комментариям @brettdh , я понимаю несколько вещей:

1. Текущее поведение по умолчанию pipenv install не соответствует поведению pipenv lock . Выполнение одного только pipenv install requests не приведет к обновлению requests если выйдет новая версия (очень похоже на pip install ). Однако выполнение pipenv lock обновит Pipfile.lock последней версией requests которая соответствует спецификатору Pipfile и ограничениям зависимостей.
   Есть два основных способа увидеть это:
   
   
   
   • A) Pipfile.lock по умолчанию должен оставаться максимально стабильным, не меняя контакты, если это не требуется, чтобы оставаться в соответствии с текущей средой, и изменяться только в том случае, если мы меняем среду.
   
   
   • Б) Pipfile.lock должны получить новейшие версии, которые соблюдают ограничения / зависимости среды, чтобы беспрепятственно пользоваться открытыми диапазонами в зависимостях Pipfile и lib, что позволяет постоянно получать новые совместимые версии в ваше окружение. Затем вы можете запустить pipenv update чтобы воспользоваться новой блокировкой.
   
   

IMHO, I would align the default behavior, which would be to go with A) by default. Because right now, everytime a lock is performed (i.e. after each installation), new versions can come in, which make the lockfile *drive the update of the environment*, which seems weird. But, this is arguable of course. While in development, I might want to continuously update my requirements to no get stale, like with B), so that should also be easily doable.

1. Даже если мы используем LocalRequirementsRepository чтобы избежать обновления правильных существующих выводов, и в конечном итоге выровняем поведение по умолчанию, тогда нам нужно обратиться к эквиваленту --upgrade и --upgrade-strategy для блокирующей части. . В настоящее время определение некоторых переменных среды (например, PIP_UPGRADE и PIP_UPGRADE_STRATEGY ) повлияет на поведение pipenv install , но не повлияет на pipenv lock , так как не влияет поведение pip-tools (я подтвердил это, поскольку сначала не был уверен).
   В противном случае не будет возможности обновить среду, не удалив Pipfile.lock (кажется неуклюжим и «все или ничего») или не потребовав более новую версию (я имею в виду явное указание pipenv install requests>2.18.4 , который требует, чтобы вы знали, что новая версия вышла, и изменяет спецификатор в самом Pipfile , увеличивая нижнюю границу), что неверно. Поскольку "исходный pip-tools " не относится к pip чтобы справиться с этим (поскольку это не связано с тем, что установлено в настоящее время), он предлагает возможность указать зависимости для обновления в lockfile и просто удалите контакты для этих пакетов (или всех) из списка существующих_пинов, возвращаясь к запросу PyPI. Я не уверен, как мы можем сопоставить с этим понятие «--upgrade-strategy».

@techalchemy
Итак, хотя я говорил, что было довольно легко просто «выровнять поведение по умолчанию», теперь я понимаю, что это вызовет некоторые серьезные проблемы с возможностью обновления пакетов (например: просто загрузите последнюю версию, которая соответствует моим текущим ограничениям) .

Если что-то неясно, спросите, когда я писал это, много редактировалось.

(Разрешение зависимостей непросто. Хорошее и практичное разрешение зависимостей - еще худшее 😄)

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

Б) Pipfile.lock должен получить новейшие версии, которые учитывают ограничения / зависимости среды, чтобы свободно использовать открытые диапазоны в зависимостях Pipfile и lib, позволяя постоянно получать новые совместимые версии в вашей среде. Затем вы можете запустить pipenv update, чтобы воспользоваться новой блокировкой.

Этот рабочий процесс может работать с текущей конфигурацией. Вы можете использовать pipenv lock для создания файла блокировки, но pipenv update переустановит всю среду. Я почти уверен, что мы можем использовать один из наших различных форматов вывода для разрешения графа зависимостей (у нас уже есть формат json, как вы знаете) и переустанавливать только те элементы, которые не совпадают с файлом блокировки. Это могло бы быть более разумным, но мне было бы интересно узнать о вводе @nateprewitt или @erinxocon, прежде чем принимать решение.

@vphilippon Полностью согласен с тем, что A и B являются желательными рабочими процессами в разных ситуациях. Некоторые из ваших фраз вокруг B меня немного сбили с толку, казалось, что pipenv lock может привести к блокировке файла, который на самом деле не соответствует среде - я особенно слышал это в том, что нужно "запустить pipenv update для получения выгоды от новой блокировки »- как если бы блокировка« опережала »среду, а не соответствовала ей.

Независимо от того, работаете ли вы в рабочем процессе A или B, некоторые вещи кажутся мне постоянными, и я думаю, что это также согласуется с тем, что

• Результатом pipenv lock всегда должен быть файл блокировки, соответствующий среде.
• Результатом pipenv install всегда должна быть среда, соответствующая файлу блокировки.

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

Периодический запуск pipenv update позволяет вам оставаться в режиме B до тех пор, пока вы хотите, чтобы все было свежим, а возможность pipenv install --upgrade requests позволит выполнять определенные обновления одного пакета и его зависимостей, не затрагивая пакеты которые не нужно обновлять без необходимости.

Я упускаю какие-либо варианты использования? Я могу думать об оптимизации для B - например, о флаге или env var, которые говорят ему всегда обновляться с нетерпением, - но я думаю, что это охватывает основы. Я также знаю, что возвращаюсь к той земле, которую вы уже прошли; Мне просто полезно убедиться, что я понимаю, о чем вы говорите. :)

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

@brettdh, это правильно - преобразователь pip-tools мы используем для генерации Pipfile.lock , не запрашивает у virtualenv список установленных пакетов. Вместо этого он составляет список пакетов, которые соответствуют критериям, указанным в списке контактов из Pipfile . Поскольку сам преобразователь запускается с использованием системной или внешней установки python / pipenv / pip-tools, мы делаем некоторую ерунду, чтобы убедить его разрешать пакеты с той же версией python, которая используется в virtualenv. Предполагается, что pip install решит все аналогичным образом, но это не всегда так, хотя даже я не уверен на 100% в этом. Но да, pipenv lock не создается на основе virtualenv, он создается на основе Pipfile . Это файл блокировки разрешения зависимостей, а не вывод состояния среды.

В качестве потенциального решения этой проблемы: то, что в настоящее время поддерживает сам pip, а pip-compile - нет, - это понятие файла ограничений.

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

Это функция, которая в настоящее время отсутствует в pipenv , так как желаемые входы для генерации Pipfile.lock :

1. Обновленное содержимое Pipfile как новый входной файл требований
2. Полный набор существующих зависимостей из Pipfile.lock в качестве файла ограничений, за исключением пакетов, специально названных в текущей команде

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

в настоящее время не поддерживается, спасибо за отзыв

@kennethreitz

Ты имеешь ввиду:

1. Это поведение следует изменить, но в настоящее время оно не является приоритетным,
2. Это поведение следует добавить как нечто необязательное, но в настоящее время оно не является приоритетным, или
3. Такое поведение добавлять не стоит?

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

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

Я имею в виду, что в настоящее время это не поддерживается, и я ценю отзывы.

Я так понимаю, что это не поддерживается. Вы также говорите, что не примете PR, изменив это поведение или добавив это в качестве опции?

Понятия не имею.

@ k4nar все еще заинтересован в пиаре для этого? В частности, что-то вроде pipenv install --only <dep-to-update которое предотвращает обновление несвязанных зависимостей. Поскольку @kennethreitz, похоже, не заинтересован в дальнейшем обсуждении, мне кажется, что это единственный способ узнать, может ли это добавление / изменение поведения быть приемлемым (и, соответственно, могут ли такие люди, как @taion и я, продолжать использовать pipenv).

Мне интересно, но я не уверен, что знаю, как лучше всего это реализовать. В действии много компонентов (pip, pip-tools, pipfile, pipenv…) и, ​​вероятно, множество возможных решений.

Согласно https://github.com/kennethreitz/pipenv/issues/966#issuecomment -339707418, это должно быть относительно просто. Эта логика разрешения депозита в значительной степени основана на инструментах pip. Я планировал отправить PR, но я не могу оправдать затраты работы, если мы не хотим говорить о том, как мы хотим, чтобы API выглядел, прежде чем потратим время на написание кода.

В настоящее время я ищу альтернативный подход - поскольку Pipfile является стандартом, взаимодействия с ним не должны проходить через pipenv, и я хотел бы обойти некоторые из других странных семантик здесь, например, стирание существующих virtualenv на https : //github.com/kennethreitz/pipenv/issues/997.

Извините за комментарий к закрытой проблеме, но я хотел бы указать, что, насколько я понимаю, использование pipenv в моих проектах в настоящее время требует такого рабочего процесса:

pipenv install foo
vim Pipfile.lock  # Manually remove all the unwanted updates
git add && git commit && git push

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

IIUC, это поведение эквивалентно выполнению apt неявного apt dist-upgrade при каждом запуске apt install foo .

Это усугубляется тем фактом, что pipenv install обновляет материал в Pipfile.lock , но не устанавливает обновления в локальный virtualenv. Если разработчик не внимательно изучит разницу Pipfile.lock , он по-прежнему будет использовать старые версии локально, но как только они поделятся кодом, все остальные среды увидят неожиданные обновления. Люди имеют тенденцию игнорировать разницу Pipfile.lock потому что она считается автоматически созданным файлом.

Я твердо убежден, что «обновить все до последней версии, разрешенной Pipfile » должно быть явно запрошенной операцией, отдельной от «install foo».

должен быть исправлен в мастере

Поведение все еще присутствует, я тестировал его в pipenv 11.8.3 , @kennethreitz.

@ marius92mc Комментарий «исправлено в главном» относится к параметрам --selective-upgrade и --keep-outdated , добавленным в последних выпусках: https://docs.pipenv.org/#cmdoption -pipenv-install-keep - устаревший

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

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

Например: использование --selective-upgrade и --keep-outdated прежнему приведет к обновлению устаревших библиотек в Pipfile.lock , если они не имеют прямого отношения к "выбранному" пакету, который нужно обновить. .

Похоже, что здесь могут быть ошибки в реализации.

Они предназначены для того, чтобы оставить pipfile.lock как есть, за исключением нового изменения.

Сообщите мне, будет ли полезно предоставить тестовый файл Pipfile + .lock.

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

На самом деле, ваш pipfile / lock был бы отличным, если бы он содержал устаревшие результаты.

@ncoghlan , спасибо за подробности.
Я попробовал еще раз с вашими упомянутыми параметрами, и результат кажется таким же, он по-прежнему обновляет и другие пакеты, изменяя их в файле Pipfile.lock .

@kennethreitz https://github.com/simonpercivall/pipenv-selective-upgrade-test

Есть какие-нибудь обновления по этой проблеме, @kennethreitz?

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

Взносы, как всегда, приветствуются!

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

1. Обновите ограничение версии для зависимости в setup.py
2. Запустите pipenv lock --selective-upgrade ; pipenv sync или pipenv install --selective-upgrade "-e ."

@wichert Если Pipfile был отредактирован таким образом, что минимальная требуемая версия была увеличена сверх того, что находится в текущем файле блокировки, тогда --keep-outdated уже должно покрывать то, что вам нужно. --selective-upgrade предназначен для случая, когда Pipfile не изменилось, но вы все равно хотите выполнить обновление до новой закрепленной версии.

@ncoghlan Pipfile в этом сценарии не изменился, только setup.py путем изменения требования минимальной версии для зависимости, обычно на что-то более новое и в настоящее время находится в Pipfile.lock .

@wichert pipenv не фиксирует изменения в вашем setup.py автоматически, потому что это не инструменты настройки. Вы должны запустить pipenv lock если хотите, чтобы это произошло.

Каков текущий статус этого? 25 марта кто-то сказал, что, по их мнению, проблемы с реализацией будут решены «в ближайшие пару дней», а другие отчеты об ошибках были закрыты из-за их отслеживания здесь; но с 2018.7.1 я все еще вижу ошибку, о которой сообщил Саймон Персивалл (косвенные зависимости всегда обновляются), и эта ошибка не обсуждалась с момента первоначального отчета. Проблема все еще отслеживается?

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

PS: Спасибо, что сделали Pipenv, это круто <3

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

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

@uranusjr FWIW, я не видел никаких требований по целесообразности в комментарии @benkuhn выше - просто вопрос о том, где дела; т.е. какая работа была проделана, чтобы сторонние наблюдатели могли делать свои собственные оценки / решения.

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

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

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

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

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

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

Я думаю, что это немного удивительно, но не совсем необоснованно, что pipenv интерпретирует foo = "*" как «Мне просто нужно убедиться, что установлена ​​_некоторая_ версия foo, пользователю все равно, какая». С этой целью наличие чего-то вроде pipenv install --pin foo которое приводит к foo = "==1.2.3" вместо foo = "*" в Pipfile (где 1.2.3 - это текущая последняя версия foo), похоже, может Помогите.

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

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

Фактический вариант использования, с которым я боролся уже несколько часов: я хочу измерить тестовое покрытие в проекте Django 2.0. Даже pipenv install --keep-outdated --selective-upgrade --dev coverage настаивает на обновлении пакета Django, отличного от разработчика, до версии 2.1, которую я пока не могу использовать из-за поломки в другом месте. На самом деле должен быть способ изменить набор установленных пакетов без обновления полностью несвязанных пакетов до возможных критических версий. Возможность поломки в последней версии будет всегда.

Я попробую обходной путь , но я не знаю, сломает ли что-нибудь предположительно неправильное свойство _meta hash .

@ l0b0 Если ваше приложение действительно не может обрабатывать определенную версию Django, я думаю, имеет смысл указать это ограничение в вашем Pipfile?

@AlecBenzer Для меня это звучит как что-то для setup.py.

@wichert Это тоже может иметь смысл (на самом деле я не совсем понимаю, при каких обстоятельствах вы хотели бы иметь и setup.py, и Pipfile), но если у вас есть строка в вашем Pipfile, которая говорит:

Django = "*"

вы говорите pipenv, что хотите, чтобы он установил _ любую_ версию Django. Если вы действительно хотите, чтобы он установил 2.0 или ниже, скажите вместо этого:

Django = "<=2.0.0"

Хотя в этом конкретном случае pipenv обновляет Django без реальной причины, возможно, где-то в будущем вы попытаетесь установить пакет, требующий Django> 2.0.0, и в этот момент pipenv с радостью установит его, если вы не сказали это то, что вам нужно <= 2.0.0.

Если вы действительно хотите, чтобы он установил 2.0 или ниже, скажите, что вместо этого

@AlecBenzer, подумав , теперь мне приходит в голову, что это то, что npm / yarn делает по умолчанию при установке пакета; они находят последнюю версию major.minor и указывают ^major.minor.0 в package.json, что предотвращает неожиданное обновление основной версии, даже если явно запрашивается обновление до последней. Интересно, должен ли Pipenv сделать то же самое, но это отдельная тема.

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

Я думаю, что это обсуждалось выше и в другом месте, но в пространстве дизайна есть напряжение / компромисс между npm / yarn и pipenv. Любой менеджер пакетов якобы преследует эти цели с некоторым относительным приоритетом:

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

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

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

@brettdh

подумав, мне пришло в голову, что это то, что npm / yarn делает по умолчанию при установке пакета; они находят последнюю версию major.minor и указывают ^ major.minor.0 в package.json, что предотвращает неожиданное обновление основной версии, даже если явно запрашивается обновление до последней. Интересно, должен ли Pipenv сделать то же самое, но это отдельная тема.

Да, это похоже на то, что я пытался предложить в https://github.com/pypa/pipenv/issues/966#issuecomment -408420493

Очень рад услышать, что над этим работают!

Между тем, есть ли у кого-нибудь предлагаемый обходной путь, который менее трудоемок и подвержен ошибкам, чем запуск pipenv lock и ручной возврат полученных изменений файла блокировки, которые я не хочу применять?

@benkuhn Не то, чтобы я знал - я все время танцую один и тот же танец с блокировкой и

Ну ладно, иногда можно хотя бы избежать ручного возврата:

1. pipenv lock
2. git commit -m "FIXME: revert"
3. pipenv install packagename
4. git commit -m 'Add dependency on packagename'
5. git rebase -i
6. Отбросьте фиксацию FIXME: revert

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

--keep-outdated кажется, систематически сохраняет устаревшими только явные зависимости, которые указаны (откреплены) в Pipfile, в то время как все неявные зависимости обновляются.

Правильно ли я, что невозможно обновить / установить единую зависимость с помощью pipenv==2018.7.1 без обновления других зависимостей? Я пробовал разные комбинации --selective-upgrade и --keep-outdated но безуспешно.

Редактировать Pipfile.lock вручную - неинтересно ...

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

Конечно, ###, если обновление является обязательным, можно обновить все необходимые зависимости, но только те, а не все устаревшие.

Кроме того, параметры --selective-upgrade и --keep-outdated не ясны для того, для чего они полезны, есть еще одна проблема, которая выделяется здесь # 1554, и никто не может ответить, что эти параметры делают, невероятно.

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

@mrsarm Спасибо за ваше мнение. Извините, у вас ничего не работает. Однако я не понимаю, откуда взялось разочарование. Никто никому не навязывает Pipenv; если это не работает для вас, не используйте его. Так работают рекомендации.

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

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

Но сейчас все становится хуже, и то, что я собираюсь сказать, это не мнение, а факт.

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

Новая зависимость - PyYAML, скажем, последняя версия. Если вы установите его в любой новой среде с помощью pip , вы увидите, что библиотека не добавляет никаких зависимостей, поэтому установлен только PyYAML, это так просто в этих случаях с Pip. Но при добавлении зависимости с Pipenv (поскольку проект, который я не создавал, управляется с помощью Pipenv), возникла та же проблема, несмотря на то, что PyYAML не имеет никакой зависимости и ранее не был установлен в проекте (более старая версия), pipenv обновляет все мои зависимости в файле блокировки и в виртуальной среде, но я не хочу обновлять другие зависимости, я просто добавляю один новый модуль без какой-либо зависимости.

Итак, вывод (и снова мнение, а не факт, как pipenv сломал все мои зависимости) заключается в том, что Pipenv вместо того, чтобы помочь мне справиться с управлением зависимостями, превращает это в ад.

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

Около месяца назад я опробовал более полную альтернативу pipenv , poetry ; он решил проблемы, которые _I_ нужно было решить:
1) управление одним набором зависимостей (setup.py, setup.cfg, pip и pipfile -> pyproject.toml)
2) ориентированный на будущее, обратно совместимый (опять же pyproject.toml )
3) довольно непредубежденный ( нет, я действительно не прошу установить redis )
4) и решение классической проблемы Pipenv: «Кроме того, вы должны явно указать ему [pipenv], чтобы он не обновлял заблокированные пакеты при установке новых. Это должно быть по умолчанию». [[1] (https://github.com/sdispater/poetry#what-about-pipenv)] [[2] (https://github.com/pypa/pipenv/issues/966#issuecomment-339117289)]

Я хотел поделиться этими мыслями по проблеме pipenv , но, как сказал @uranusjr , «никто никого не навязывает Pipenv», и я не навязываю Poetry. Мне это нравится, он хорошо работает и решает мои проблемы, но я просто делюсь альтернативным, более комплексным решением возникшей у меня проблемы. Просто примите все это как мои 2 цента.

• в качестве заявления об отказе от ответственности я не являюсь членом команды Poetry и не связан с ними.

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

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

Для пользователей, которые хотят попробовать альтернативный преобразователь, который мы с https://github.com/sarugaku/passa, который создаст совместимые файлы блокировки. Поэзия делает много разных вещей, но она также имеет ограничения и проблемы, и у нас есть разногласия по поводу масштабов философии дизайна.

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

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

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

@dfee Я не совсем уверен, что стирание

@techalchemy

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

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

у него также есть ограничения и проблемы

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

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

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

Я думаю, здесь есть две сильные темы:

• Если pipenv обновит все ваши устаревшие зависимости, где вы пытаетесь просто установить новую зависимость: те, которые не нужны для обновления, потому что новый пакет / версия, которую мы пытаемся установить, может работать с существующими зависимостями, и даже с теми, которые не нужны Нет ли зависимостей нового пакета, который мы пытаемся установить? Возможно, это выходит за рамки этого билета, но это действительно важная тема для обсуждения.
• Позволяет ли один из этих параметров --keep-outdated --selective-upgrade избежать такого поведения? Непонятно, что делают эти параметры, о них не хватает документации, и даже в связанной проблеме (№ 1554) никто не отвечает.

В случае, если это ошибка в одном из этих параметров --keep-outdated --selective-upgrade , я все еще думаю, что не устанавливать какой-либо параметр, решающий ненужное обновление зависимостей по умолчанию, это действительно плохая идея.

Чтобы сравнить с аналогичным сценарием, представьте, что вы выполняете apt-get install vim чтобы просто установить инструмент vim в свою систему (и необходимые зависимости или обновления vim, если применимы), но представьте также, что в этой ситуации apt обновляет все другие зависимости вашей системы: python, систему QT, ядро ​​Linux ... и так далее. Дело не в том, что apt не должен позволять нам обновлять другие зависимости, но для этого есть четкая команда: apt-get upgrade , а apt-get install PACKAGE просто устанавливает / обновляет ПАКЕТ и его зависимости.

@sdispater, различие лежит в основе каждого разногласия, которое у нас когда-либо было, и оно невероятно тонкое, но я бы указал вам на https://caremad.io/posts/2013/07/setup-vs-requirement/ или на хороший статья для случая использования эликсира: http://blog.plataformatec.com.br/2016/07/understanding-deps-and-applications-in-your-mixfile/

pyproject.toml самом деле не поддерживается для метаданных определения библиотеки - и вообще не поддерживается любой версией pip, которая не реализует peps 517 и 518 (оба из которых все еще разрабатывают детали реализации) в качестве авторитетного файл объявления библиотеки. Для этой цели существует setup.cfg (фактический преемник setup.py ), и ИМХО оба из них действительно должны поддерживаться. Библиотека опубликована и предназначена для использования с абстрактными зависимостями, чтобы они могли хорошо играть в песочнице с другими; приложения обычно представляют собой большие и сложные системы, иногда с сотнями прямых зависимостей. Итак, одно из наших основных расхождений заключается в том, что при разработке и создании наших инструментов мы также учитываем это.

@mrsarm Что касается вашего первого вопроса, то поведение обновления было преднамеренным (и подробно обсуждалось в то время, / cc @ncoghlan и касалось проблем безопасности OWASP). По второму пункту поведение в настоящее время не реализовано должным образом, поэтому проблема все еще остается открытой, что привело нас к переписыванию вспомогательного преобразователя за pipenv, о котором я упоминал выше. Он просто не поддерживал такое поведение. --selective-upgrade предполагает выборочное обновление только тех вещей, которые являются зависимостями нового пакета, в то время как --keep-outdated сдерживает все, что удовлетворяет зависимостям, требуемым новым пакетом. Немного по-другому, но я почти уверен, что сейчас ни один из них не работает правильно.

pyproject.toml на самом деле не поддерживается для метаданных определения библиотеки - и вообще не поддерживается какой-либо версией pip, которая не реализует peps 517 и 518 (оба из которых все еще имеют детали реализации) в качестве авторитетного файла объявления библиотеки . setup.cfg существует для этой цели (фактический преемник setup.py), и IMHO оба они действительно должны поддерживаться.

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

На самом деле в настоящее время нет стандарта вокруг setup.cfg кроме соглашений, установленных distutils и setuptools. pyproject.toml предназначен исключительно для метаданных библиотеки в качестве преемника setup.py иначе сообщество поместило бы требования сборки в setup.cfg вместо этого.

pyproject.toml описывает, как построить проект (PEP 518), а часть построения описывает метаданные. Я НЕ говорю, что pyproject.toml требует стандартного расположения для этих метаданных, но PEP 518 использует этот файл для установки инструмента сборки, и оттуда очень разумно ожидать, что инструмент сборки будет использовать декларативную конфигурацию откуда-то еще. в файле, чтобы определить, как построить проект.

В любом случае, возвращаясь к pipenv и поэзии - кажется, есть какая-то идея, что приложениям не нужны определенные функции, которые получают библиотеки, например точки входа, и это просто неверно. Приложение должно быть просто пакетом Python.

Единственная разница между приложением и библиотекой в ​​моем опыте работы с python и другими экосистемами заключается в том, используете ли вы файл блокировки или нет. Конечно, есть и третий случай, когда вам просто нужны requirements.txt или Pipfile и никакого фактического кода, и это, похоже, все, на чем пока сосредоточился pipenv ( pipenv install -e . падает в эту категорию, поскольку pipenv все еще боится пытаться поддерживать метаданные пакета). К сожалению, хотя дизайн pipenv при таком подходе более понятен, он также менее полезен для большинства приложений, потому что PEP 518 решил попытаться установить проекты в редактируемый режим, поэтому, чтобы продолжить использование pipenv, мы довольно сильно застрянем на инструментах настройки. в то время как дольше, поскольку вы не можете использовать pyproject.toml чтобы отказаться от инструментов настройки и по-прежнему использовать pipenv install -e . .

На самом деле в настоящее время для setup.cfg нет никаких стандартов, кроме соглашений, установленных distutils и setuptools. pyproject.toml предназначен исключительно для метаданных библиотеки, поскольку преемник setup.py, иначе сообщество поместило бы требования сборки в setup.cfg.

Distutils является частью стандартной библиотеки, а setuptools теперь устанавливается вместе с pip, поэтому говорить о том, что стандарта нет, немного глупо. Не говоря уже о том, что он использует стандарт, описанный в pep 345 для метаданных, среди прочего, а также может использоваться для определения требований к сборке.

вместо этого сообщество поместило бы требования к сборке в setup.cfg.

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

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

Это недавно появилось в списке рассылки - нигде не было объявлено о стандарте pyproject.toml кроме того, что он будет использоваться для объявления системных требований сборки. Все остальное - предположение; вы можете назвать это «метаданными определения библиотеки», но это не так. Попробуйте определить только систему сборки без дополнительной информации о вашем проекте (т.е. без метаданных, совместимых с pep-345), загрузите ее в pypi и дайте мне знать, как это происходит.

В любом случае, возвращаясь к pipenv и поэзии - кажется, есть какая-то идея, что приложениям не нужны определенные функции, которые получают библиотеки, например точки входа, и это просто неверно. Приложение должно быть просто пакетом Python.

Кто сказал, что приложениям не нужны точки входа? У Pipenv есть целая конструкция, чтобы справиться с этим.

поэтому, чтобы продолжить использование pipenv, мы задержимся на setuptools на некоторое время, поскольку вы не можете использовать pyproject.toml, чтобы отказаться от setuptools и по-прежнему использовать pipenv install -e.

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

Это недавно появилось в списке рассылки - нигде не было объявлено о стандарте pyproject.toml

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

Итак, по той же логике, которую вы использовали здесь:

Distutils является частью стандартной библиотеки, а setuptools теперь устанавливается вместе с pip, поэтому говорить о том, что стандарта нет, немного глупо.

pyproject.toml - это стандарт, и сообщество приняло его как стандартное место для размещения информации, связанной с системой сборки и другими частями проекта Python.

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

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

Distutils является частью стандартной библиотеки, а setuptools теперь устанавливается вместе с pip, поэтому говорить о том, что стандарта нет, немного глупо. Не говоря уже о том, что он использует стандарт, описанный в pep 345 для метаданных, среди прочего, а также может использоваться для определения требований к сборке.

Да, ожидается, что система сборки выведет файл PKG-INFO, описанный в PEP 345. Это формат передачи, который входит в sdist или wheel и генерируется из setup.py/setup.cfg, он не является заменой, поскольку например, для метаданных, обращенных к пользователю. PEP 518 использует pyproject.toml поддержки альтернатив distutils / setuptools в качестве системы сборки, никто прямо сейчас не пытается заменить форматы sdist / wheel. Этим заменяющим системам сборки нужно место для размещения их метаданных, и, к счастью, PEP 517 зарезервировал пространство имен tool. для этих систем. Это не предположение - и flit, и поэзия приняли это пространство имен для «метаданных определения библиотеки».

Попробуйте определить только систему сборки без дополнительной информации о вашем проекте (т.е. без метаданных, совместимых с pep-345), загрузите ее в pypi и дайте мне знать, как это происходит.

Как конструктивно.

Кто сказал, что приложениям не нужны точки входа? У Pipenv есть целая конструкция, чтобы справиться с этим.

Где эта конструкция? Я даже не могу найти слово «запись» ни на одной странице документации pipenv по адресу https://pipenv.readthedocs.io/en/latest/, так что «вся конструкция» звучит довольно надуманно? Если вы имеете в виду редактируемые установки, то мы достигли точки, о которой я говорил выше: pipenv решает присоединиться к pipenv install -e . как единственный способ подключиться и разработать приложение как пакет для поддержки pipenv в обозримом будущем. здесь связан с setuptools. Я думаю, что все противоречия действительно сводятся к этому пункту, и люди (конечно, я) разочарованы тем, что мы теперь можем определять библиотеки, которые не используют setuptools, но не могут развиваться на них с помощью pipenv. Чтобы быть совершенно ясным, это не строго вина pipenv (PEP 518 решил использовать редактируемые установки), но его отказ признать проблему разочаровывает в дискурсе, поскольку поэзия предоставляет альтернативу, которая решает эту проблему таким образом, чтобы в формате pyproject.toml . Пипенв постоянно повторяет, что поэзия принимает плохие решения, но на самом деле не пытается указать путь вперед.

https://pipenv.readthedocs.io/en/latest/advanced/#custom -script-shortcuts

Пожалуйста, прочтите документацию.

@bertjwregeer :

pyproject.toml - это стандарт, и сообщество приняло его в качестве стандартного места для размещения информации, связанной с системой сборки и другими частями проекта Python.

Отлично, и мы рады разместить sdist и колеса, созданные с использованием этой системы, и до тех пор, пока не будет стандарта для редактируемых установок, мы продолжим использовать pip для создания sdists и wheel и таким образом обрабатывать разрешение зависимостей. Пожалуйста, прочтите мои ответы полностью. Авторы и сопровождающие pip, рассматриваемых peps, а также я и @uranusjr довольно хорошо разбираемся в различиях между редактируемыми установками и последствиях их создания в условиях pep 517 и 518. Пока все, что я вижу в том, что рассматриваемые peps не указали конкретно, как их создавать, потому что они оставляют это на усмотрение инструментов, что по какой-то причине все думают, что pipenv никогда не сможет использовать ничего, кроме setuptools?

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

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

https://pipenv.readthedocs.io/en/latest/advanced/#custom -script-shortcuts
Пожалуйста, прочтите документацию.

Точки входа - это более общая концепция, чем просто консольные скрипты, и эта ссылка полностью ошибочна для решения этих проблем. <soapbox> Забаньте - вы не единственный сопровождающий здесь крупные проекты с открытым исходным кодом, и ни один из моих комментариев не был личной атакой на вас или проект. Люди, комментирующие здесь, делают это, потому что хотят использовать pipenv и ценят то, что он делает. Мой комментарий не был первым постом не по теме в этой ветке, но он единственный отмечен. Ваши язвительные комментарии, указывающие на то, что вы думаете, что я не понимаю, о чем говорю, смущают и отравляют.

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

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