4799 — место, где происходит много споров. В основном это было вызвано:

1. Я понял, что единственным блокировщиком поддержки PEP 518 был # 4764 (через https://github.com/pypa/pip/pull/4144#issuecomment-302711736)
2. Затем появился номер 4799, и я посмотрел на него, чтобы понять, могу ли я понять всю незавершенную работу, которую делал @xoviat .
3. В ходе этого всплыл # 4647 как блокировщик релиза, говорящий, что поддержка PEP 518 нарушена.

Когда я пытался понять, что @xoviat говорил в # 4799, стало очевидно, что у нас есть некоторые проблемы с рекурсивным построением среды сборки (X нужно Y для сборки, а Y нужно Z, ...), хотя я Пока неясно, являются ли они ошибками реализации, более глубокими проблемами дизайна или неприятными побочными случаями, которые мы можем отложить без особых проблем.

Лично я нахожусь в точке, где я не в своей тарелке. Я не понимаю реализацию @xoviat , чтобы судить, нужно ли это, или нам все еще нужно просто объединить # 4764 и исправить # 4647, чтобы быть готовым к работе. Я также не знаю, насколько легко будет исправить #4647 ( @xoviat , кажется, говорит, что нам нужно объединить #4799, чтобы исправить #4647, но это приносит свои проблемы).

У меня кончились время и силы, чтобы продолжить обсуждение в эти выходные, поэтому я собираюсь бросить учебу на этом этапе (по крайней мере, на время). Для меня ключевым моментом является то, что нам нужен приемлемый уровень поддержки PEP 518 для 10-го пункта. можно не заставлять людей загораться тем, что 10-й пункт придет только для того, чтобы потом сказать, что это не будет до нового года ...

Спасибо за очень полезное резюме @pfmoore.

@ncoghlan @dstufft @xoviat Можем ли мы перенести обсуждение сюда? Делать это на закрытом PR мне кажется странным. ._.

Конечно вещь.

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

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

pip имеет иерархию объектов, как это принято в большинстве проектов Python. Все это запускает команду, которая создает новые ссылки на объекты, которые создают новые ссылки на нижележащие объекты. Это как дерево.

Я буду определять «сферу» объекта как своего рода время жизни. Это продолжительность существования объекта. Прямо сейчас областью действия PEP 518 в pip является WheelBuilder . Среда PEP 518 настроена на bdist_wheel , затем в этой среде запускается bdist_wheel , а затем среда разрывается.

Так в чем проблема? Проблема в том, что область действия среды PEP 518 должна быть равна или больше области действия всех вызовов setup.py . Точнее, он должен инкапсулировать объект, который существует на протяжении вызовов setup.py . Этот объект Requirement .

Первое очевидное решение, с которым вы столкнетесь: что должно иметь ссылку на BuildEnvironment , а Requirement — это хорошее место, как и любое другое. На самом деле, ИМХО, это лучшее место для размещения ссылки, потому что setup.py вызывается тогда и только тогда, когда Requirement существует.

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

Другая проблема заключается в том, какой вызов оболочки мы должны сделать? На самом деле это сложнее, чем вы думаете, потому что получение параметров командной строки — это, откровенно говоря, PITA, где вам нужно сделать этот вызов. Таким образом, у вас могут возникнуть проблемы с передачей исходных параметров, которые пользователь передал дочернему элементу. Решение, использованное первоначальным разработчиком, включало использование finder , но я думаю, вы знаете, в чем проблема.

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

Вот некоторые возможные решения этой проблемы:

1. Если вы хотите получить PEP 518 за дверь, ваш лучший выбор, вероятно, какой-то файл блокировки, который позволяет только до 10 блокировок или около того, чтобы убедиться, что pip не умножается бесконечно. Затем вы можете просто передать точные требования дочернему элементу вместе с аргументами командной строки.

2. Правильное решение, которое я хотел бы реализовать после PEP 517, состоит в том, чтобы иметь класс BuildEnvironmentManager , который инициализируется непосредственно в команде install . BuildEnvironmentManager будет иметь ссылку на все объекты там ( RequirementPreparer , WheelBuilder и т. д.) и будет иметь единственный метод: get_build_environment(requirement_set) . Затем вы можете реализовать метод на RequirementPreparer , что-то вроде set_build_environment_manager , который затем можно использовать для получения среды сборки. BuildEnvironmentManager может даже обнаруживать многократное использование одной и той же среды (чаще всего ['setuptools', 'wheel'] ) и предоставлять одну и ту же среду, если она требуется несколько раз, поэтому вам не нужно ее создавать ( очень распространено изначально с проектами, не имеющими pyproject.toml ). В идеале также должен быть какой-то ООП-дизайн, чтобы попытаться удалить циклические ссылки (не тривиально).

@xoviat Хотя это может не охватывать случай преднамеренного злого умысла, я прав, думая, что кеш сборки (который использовался даже при указании --no-binary :all: ) с возможностью отслеживать не только завершенные сборки, но и в -progress, было бы достаточно, чтобы гарантировать завершение циклов зависимостей сборки? Это будет вариант вашего первого предложения (ограничение между процессами на количество одновременных вызовов пипсов), но переформулированное как:

1. Только один процесс на машине может одновременно собирать один и тот же пакет.
2. Существует «идентификатор сборки» верхнего уровня, который pip передает любым подсборкам, которые он порождает (например, PID процесса верхнего уровня в сочетании с именем создаваемого пакета)
3. Если кеш сборки указывает, что что-то собирается с другим идентификатором сборки, дождитесь завершения этой сборки.
4. Если кеш сборки указывает, что что-то уже создается для того же идентификатора сборки, затем выйдите из строя с ошибкой, сообщающей о циклической зависимости и указывающей, что для работы сборки потребуется --binary <name>

pip также необходимо будет реализовать предложение @pfmoore об исключении setuptools и wheel из логики по умолчанию, требующей как setuptools , так и wheel в качестве зависимостей сборки, иначе неявная инъекция зависимостей сборки по своей сути вызовет циклическую логику обнаружения зависимостей.

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

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

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

На самом деле я раньше не смотрел на код #4144. Я только что сделал, и я действительно не хочу, чтобы это было доставкой.

реализовать PEP 518 совершенно правильно и просто что-то взломать.

Честно говоря, я думаю, что это сводится к этому. Полная и правильная реализация PEP 518 — это задача, которая задержит/может задержать 10 пунктов на (справедливо) бит, если мы пойдем по этому пути.

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

Как это звучит?

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

Полная и правильная реализация PEP 518 — это задача, которая задержит/может задержать 10 пунктов на (справедливо) бит, если мы пойдем по этому пути.

Спасибо, что подтвердили это - это был мой страх.

Однако теперь я в замешательстве, так как думал, что по крайней мере частичный PEP 518 уже был в мастере. В частности, насколько я понимаю, № 4647 демонстрирует ошибку в поддержке PEP 518 в мастере - так что очевидно, что у нас уже что -то есть, так как что-то не так...

Итак, мы должны что-то сделать, и, похоже, варианты таковы:

1. Вырвите все, что у нас есть для поддержки PEP 518 на данный момент.
2. Приведите в порядок то, что у нас есть, и отправьте частичную поддержку.
3. Полностью внедрите PEP 518, прежде чем мы выпустим пункт 10.

Как вы сказали, (3) означает большую задержку перед 10-м пунктом, и у нас есть другие исправления, которые я бы очень хотел, чтобы были выпущены (исправления Unicode — это те, с которыми у нас регулярно возникают проблемы). Так что я не в восторге от этого. Вы не упомянули (1), и я не уверен, было ли это потому, что вы думали, что у нас нет поддержки PEP 518, или вы предположили, что отказаться от нее невозможно. Лично мне эта идея не нравится - это шаг назад, и он посылает довольно негативное сообщение о самом PEP, если его так сложно правильно реализовать. Но я думаю, что мы должны прямо заявить об отказе от него.

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

Так что я чувствую, что мы застряли, что бы мы ни делали, но частичная поддержка, охватывающая только колеса, поскольку зависимости сборки — лучший вариант из плохой партии :-(

Авторы PEP (в https://github.com/pypa/pip/pull/4799#issuecomment-338331267 и https://github.com/pypa/pip/pull/4799#issuecomment-338332575 в ответ на мой вопрос в https://github.com/pypa/pip/pull/4799#issuecomment-338325354) были совершенно уверены, что полная поддержка PEP требует создания любых зависимостей сборки, поэтому это должно быть только временное решение.

Но реализовывать это буду не я, так что я буду рад согласиться с мнением того, кто это сделает. Одна вещь, которую я сделал, это создал # 4803 и пометил его как блокировщик релиза, как напоминание о том, что мы должны документировать, как мы отклоняемся от спецификации, если нам это нужно.

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

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

Так что для pip, я думаю, разумно сказать, что зависимости сборки всегда будут устанавливаться из файлов колес. Уточнение, которое вы можете внести после 10.x, заключается в том, чтобы иметь кеш сборки, отличный от обычного кеша колес, чтобы пользователи кеша могли быть уверены, что все колеса в нем были созданы в контролируемой среде, а не загружены из PyPI. или другой индексный сервер.

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

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

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

На самом деле это именно то, что делает # 4799. Если хотите, я могу восстановить эту ветку, а затем вы можете разветвить ее и отправить как PR.

Две вещи на стороне реализации вещей (2) все еще остаются в силе - как указал @xoviat выше:

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

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

Я не уверен, у кого было бы время, чтобы сделать это все же.

он посылает довольно негативное сообщение о самом PEP, если его так сложно правильно реализовать.

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

Вы не упомянули (1), и я не уверен, было ли это потому, что вы думали, что у нас нет поддержки PEP 518, или вы предположили, что отказаться от нее невозможно.

Я предположил, что отступить не вариант.

Теперь, когда я думаю об этом, насколько важно отправить PEP 518 в 10-м пункте? Я чувствую, что если это можно отложить до следующего крупного релиза, это будет (помимо того, что это простой выход из этой ситуации) будет простым, и оба 517 + 518 могут попасть в один большой релиз. Это кажется достаточно чистым, чтобы я не был тем, кто говорит, что это не тот путь.

@dstufft @xavfernandez мысли?

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

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

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

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

У нас была именно такая дискуссия, за исключением того, что вы, вероятно, даже не знали об этом. Это ситуация X. Вызов egg_info перед настройкой среды сборки — это ситуация Y (#4799).

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

Я предполагаю, что это означает, что # 4799 снова на столе? Пока он проходит все тесты и делает то, на что претендует?

Аааа, эти X и Y снова преследуют меня :wink: Да, я говорю, что не чувствую относительную вероятность этих двух случаев. Насколько я понимаю, вы говорите, что требования к сборке, которые не являются колесами, достаточно редки, поэтому мы можем игнорировать этот случай. Так же, как и один голос «все в порядке» и один голос «не знаю» между нами, по сути. Я не пытаюсь заблокировать этот вариант, просто говорю, где лежат пределы моей интуиции, вот и все.

@xoviat У меня есть несколько вопросов. Было бы здорово, если бы вы ответили на них, прежде чем делать новый PR. :)

• Как вы собираетесь определить, какие пакеты будут установлены?
• Собираетесь ли вы ограничиться только бинарными зависимостями сборки?

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

@rgommers вы согласны с тем, что PEP 518 поддерживает только зависимости сборки, доступные в виде колес, если это будет в следующем пункте?

Как вы собираетесь определить, какие пакеты будут установлены?

Подпроцесс получает список требований точно так, как указано. Таким образом, он проходит через резольвер.

Собираетесь ли вы ограничиться только бинарными зависимостями сборки?

Да, именно поэтому тест был xfailed. Зависимость сборки в тесте — это не колесо.

Теперь, когда я думаю об этом, насколько важно отправить PEP 518 в 10-м пункте? Я чувствую, что если это можно отложить до следующего крупного релиза, это будет (помимо того, что это простой выход из этой ситуации) будет простым, и оба 517 + 518 могут попасть в один большой релиз. Это кажется достаточно чистым, чтобы я не был тем, кто говорит, что это не тот путь.

Что мы чувствуем, если у нас есть время, чтобы сделать PEP 517 и 518 для пункта 11? Я не оптимистичен. Мне кажется, что они оба являются большими кусками работы, и у нас также продолжается работа над распознавателем. Хотя я не за то, чтобы задерживать 10 пипсов дольше, чем необходимо, мне в равной степени неудобно позволять всем нашим планам основных функций дрейфовать, пока мы выпускаем серию по существу второстепенных выпусков.

Иными словами, фраза «давайте выпустим 10-й пункт» вызвала всплеск активности в работе над PEP 518. Если мы удалим это из пункта 10, я, например, сосредоточусь на подготовке к выпуску, и я подозреваю, что PEP 518, вероятно, снова потеряет импульс. Что может снова привести вещи в действие? @xoviat работал над реализацией, но у него были проблемы с попыткой заставить кого-либо из нас понять проблемы, с которыми он боролся до сих пор. Я не хочу, чтобы он снова работал без обратной связи.

Что мы могли бы сделать, так это выпустить «pip 9.1» только с добавочными исправлениями, которые у нас есть, и зарезервировать номер версии «pip 10» для реализации (по крайней мере, одной из) 3 крупных функций, которые находятся в стадии разработки. Но если мы это сделаем, я хотел бы попытаться [1] зафиксировать выпуск 10 пунктов в первом квартале 2018 года. Я бы согласился с таким подходом. Но есть ли у кого-нибудь представление о том, что будет связано с отказом от частичной поддержки, которую мы сейчас имеем в мастере? Или в документировании того, что у нас есть, и каковы его ограничения (чтобы люди не пытались использовать его, предполагая, что он завершен, выявлять ошибки и поднимать проблемы, на которые мы должны ответить: «эта функция еще не завершена, извините, но подождите, пока 10")? Мы просто обмениваем один большой кусок работы на другой?

[1] В той мере, в какой мы можем посвятить себя чему-либо с чрезвычайно ограниченными добровольческими ресурсами, поскольку все, что у нас есть.

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

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

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

Мне действительно это нравится. +1 к пункту 9.1.0 вместо пункта 10.0.0

Я хотел бы попытаться [1] зафиксировать выпуск 10-го пункта в первом квартале 2018 года. Я бы согласился с этим как с подходом.

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

Я подозреваю, что PEP 518 снова теряет импульс.

Я сделаю все, что в моих силах, чтобы убедиться, что это не так. Надеюсь, @xoviat тоже хочет. :)

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

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

Примечание. Я бы не хотел делать что-то столь радикальное, как отказываться от чего-либо без согласия @dstufft и @xavfernandez — так что давайте посмотрим, что они тоже скажут.

@dstufft не хватает времени в сутках. Он также должен убедиться, что склад не рухнет.

посмотрим, что они тоже скажут.

Да, пожалуйста. :)

С точки зрения UX: всестороннее противодействие атаке «доверительного доверия» действительно болезненно [1], и вы обнаружите, что многие люди, говорящие «я компилирую все из исходников», на самом деле этого не делают — где-то в их процессе будет шагом начальной загрузки, когда они доверяют двоичному файлу, предоставленному либо кем-то другим (например, средой выполнения и набором инструментов сборки от их поставщика операционной системы), либо их собственной платформой предыдущего поколения (например, корнями сборки для новых версий Fedora и RHEL запускается из предыдущих версий Fedora и RHEL, они не начинаются полностью с нуля). Даже исходный дистрибутив Linux, такой как Gentoo, начинается с установщика, который дает вам рабочую среду сборки с ядром Linux, компилятором C, аппаратными драйверами и т. д.

Поэтому я думаю, что для пункта 10 вполне разумно сказать, что --no-binary :all: применяется только к зависимостям во время выполнения, а не к зависимостям сборки. Если люди хотят явно построить свой buildroot из исходного кода, они все равно могут - просто pip 10 не будет неявно автоматизировать это для них из-за присущих проблем рекурсивной начальной загрузки, связанных с разрешением неявных исходных сборок для ваших зависимостей сборки.

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

pip install --no-binary :all: --no-implicit-builddeps -r build-requirements.txt
pip install --no-binary :all: --no-implicit-builddeps -r requirements.txt

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

Потенциальным будущим дополнением к этой концепции было бы предоставление людям возможности сказать --buildenv <path> , чтобы указать предварительно сконфигурированную среду сборки для использования для любых необходимых исходных сборок, а не выполнять каждую сборку в изолированной среде. Тем не менее, я бы не стал пытаться включить это в пункт 10 - я бы предложил ограничить 10.x счастливым путем «разрешены зависимости двоичной сборки» и альтернативный вариант «сбой сборки, если требуется зависимость двоичной сборки». и еще не доступен в работающем в данный момент интерпретаторе».

[1] https://www.schneier.com/blog/archives/2006/01/countering_trus.html

Я подумал о другом варианте, который кажется разумным и не потребует слишком большого рефакторинга: по сути, использование многопоточности для приостановки основного потока, пока настраивается среда сборки. Идея примерно такая: в install.py у вас будет BuildEnvironmentManager :

class BuildEnvironmentManager(Thread):
    '''Has references to literally everything (cache, resolver, etc.)'''
    def run(self):
        while True:
            requirement_list, future = self.build_environment_queue.get()

            # install the requirements using all of the things
            # that we have

            # then put the build environment in the future
            future.put(BuildEnvironment())

Затем у вас будет другой файл (я использую backend.py, потому что он недостаточно заполнен и, вероятно, может использовать в нем больше вещей, и он находится в нижней части дерева):

class Future(Queue):
    pass

class BuildEnvironmentQueue(object):
    def __init__(self):
        self._queue = Queue()

    def request_build_environment(self, requirement_list):
        f = Future()
        self._queue.put((requirement_list, f))
        return f.get()

    def get():
        return self._queue.get()

И в Operations/prepare.py:

# This call will put the thread to sleep until we have a build environment
# with the requirements installed
self.build_environment_queue.request_build_environment(requirement_list)

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

Отвечая на мой собственный вопрос о подходе на основе queue.Queue: лучше не полагаться на concurrent.futures, так как для его использования потребуется вендор https://pypi.org/project/futures/ в Python 2.7.

Без хорошего знания кодовой базы pip идея консолидации управления средой сборки в одном месте по-прежнему кажется привлекательным вариантом.

Для этого подхода concurrent.futures не требуется. Future — это просто более описательная оболочка.

Требуется только примитив — это очередь: https://docs.python.org/2/library/queue.html

Думаю, мы можем просто переместить эти строки в BuildEnvironmentManager .

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

Ну, во-первых, есть все ОС, кроме [Windows, macOS, Linux], IIRC, на которые не распространяется manylinux1 .

@rgommers вы согласны с тем, что PEP 518 поддерживает только зависимости сборки, доступные в виде колес, если это будет в следующем пункте?

Не мой выбор, но я буду рад любому шагу вперед. Поддержка PEP 518 в любом случае необязательна, поэтому она работает только при наличии колес (я бы сказал, охватывает> 90% случаев) в пункте 10 по-прежнему является значительным улучшением.

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

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

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

+1 к пункту 9.1.0 вместо пункта 10.0.0

Наконец-то у меня появилось время как следует прочитать ветку distutils-sig и просмотреть соответствующие PR и обсуждения (#4351, #4144, #4799 и многие другие). Теперь я думаю, что, поскольку мы объявили о 10-м пункте; это то, что мы должны сделать, с частичной поддержкой PEP 518 - нет 9.1.0.

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

облом. :(

@ncoghlan Возможно, этот комментарий ускользнул от внимания — https://github.com/pypa/pip/pull/4799#issuecomment -338416543

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

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

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

он не распространяется на построение циклов зависимостей,

Этого не произойдет с зависимостями сборки только для двоичных файлов?

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

Ах да. Спасибо! :)

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

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

• Любой Linux, который не использует glibc (популярным является Alpine Linux внутри Docker).
• Любая операционная система *nix, кроме Linux, например FreeBSD и т. д.

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

Возможно, это уже обсуждалось! Я буду читать эту тему позже.

@dstufft Это правильно. Но мы предлагаем использовать кэш пипсов как вариант. Таким образом, вы можете сначала просто pip wheel или pip install свои зависимости сборки, а затем они будут сохранены в кеше.

Возможно, это уже обсуждалось!

Неа. :)

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

Верно. :-(

Обойти это в моей голове было бы так, что мы могли бы настроить поведение PEP 518 — если есть файл pyproject.toml , мы используем среду изоляции + сборки, в противном случае возвращаемся к текущему поведению с использованием setup.py .

Я буду читать эту тему позже.

Пожалуйста, сделай. :)

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

Если вместо этого было предложено постоянное решение, то -1, конечно.

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

Это правильно. pip должен поддерживать исходные зависимости, но у нас не хватает рабочей силы.

Обойти это в моей голове было бы так, что мы могли бы сделать выбор поведения PEP 518 - если есть файл pyproject.toml, мы используем среду изоляции + сборки, в противном случае возвращаемся к текущему поведению использования setup.py.

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

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

Error: build dependency X is not in the pip cache. Run "pip install X" before installing Y.

Резюмируя свою собственную точку зрения:

1. Я рассматриваю «Отсутствие неявной поддержки сборки для зависимостей сборки» как временное ограничение в пункте 10, чтобы сделать определенные классы проблем (например, циклы зависимостей сборки) невозможными для возникновения в первой выпущенной итерации функции. Будущие итерации поддержки подключаемого бэкэнда сборки могут разрешить неявные сборки исходного кода для зависимостей сборки, в то же время предприняв соответствующие меры, чтобы избежать новых проблем, возникающих после того, как вы разрешите это.
2. Выдача соответствующей команды python -m pip wheel X Y Z в сообщении об ошибке без фактического неявного запуска сборки является адекватным обходным путем на данный момент, поскольку это гарантирует, что pip не сможет непреднамеренно разветвить бомбу на машине.
3. Изолированные сборки, вероятно, еще не должны использоваться по умолчанию, если только конкретное создаваемое колесо не имеет файла pyproject.toml или изолированные сборки явно не запрашиваются из командной строки. Это проблема обратной совместимости, поскольку существующие проекты будут ожидать неизолированного поведения. После того, как изолированные сборки будут доступны для выпуска или двух, и все проблемы с их использованием будут устранены, они могут стать общими сборками по умолчанию (возможно, с параметром командной строки, чтобы указать конкретную среду сборки для использования, а не неявно генерировать изолированные те)

@ncoghlan Просто чтобы предупредить вас: отсутствие изоляции сборки по умолчанию означает отсутствие PEP 517 (по крайней мере, с моим подходом), потому что его поддерживает только новейшая версия setuptools (нам нужно установить более новую setuptools независимо от того, что находится на компьютере пользователя). компьютер). Практически я думаю, что это может задержать PEP 517 по крайней мере на год, потому что это резко увеличит количество усилий, необходимых для его реализации (требуется код PEP 517 и не-PEP 517).

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

У большинства людей есть CI-скрипты, которые запускают pip install X , а затем запускают pip install Y . Эти проекты должны будут добавить pypproject.toml . Но добавить pyproject.toml не так уж и сложно, и мы можем добавить флаг командной строки, чтобы при необходимости отключить изоляцию сборки.

По крайней мере, мы должны выдать предупреждение, если проект не имеет pyproject.toml в 10-м пункте (который, похоже, в любом случае не будет поддерживать PEP 517).

@xoviat «Настроить не так уж и много работы» - это не то, как работает обратная совместимость. Если бы это было так, pip уже переключился бы на --user в качестве модели установки по умолчанию, отличной от venv :)

Что касается PEP 517, вы не можете полагаться на PEP 517 как на издателя пакетов без добавления файла pyproject.toml , так что это нормально, если проекты только setup.py не получают поддержку PEP 517. по умолчанию.

Не могли бы вы выплюнуть предупреждение?

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

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

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

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

Ага. Точно.

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

+1

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

Я согласен с выводом Ника и...

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

Нет. Я не думаю, что реализация PEP 518 таким образом имеет какие-либо серьезные препятствия; Я сделал короткий комментарий по https://github.com/pypa/pip/pull/4799#issuecomment -339219397 о том, как это можно реализовать в pip.

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

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

Нет. Я не думаю, что реализация PEP 518 таким образом имеет какие-либо серьезные препятствия;

Обсуждение PEP 517 здесь. Извините за путаницу.

Нам пришлось бы запускать тесты дважды, чтобы проверить оба пути кода. Что ж, PEP 517, вероятно, отложен.

ИМО,

1. Предупреждение, если в проекте нет pyproject.toml , звучит как очень плохая идея. В конце концов, 99% проектов в PyPI в настоящее время не имеют pyproject.toml , и мы не можем спамить конечных пользователей предупреждениями, с которыми они ничего не могут сделать (кроме как сообщить о проблеме проекту(ам). ). Я что-то упускаю?
2. Я не верю, что изоляция сборки вообще упоминалась в PEP 518. Это дополнительная функция, которую pip хотел включить в течение некоторого времени, но она не привязана к поддержке PEP 518, за исключением случайного факта, что тот же PR реализован оба (AFAIR). Так что, если изоляция сборки — это то, что вызывает у нас проблемы, я согласен с тем, что изначально у меня есть только PEP 518, и я добавляю изоляцию в качестве фазы 2. Однако я оставлю это решение людям, реализующим вещи.

Я что-то упускаю?

Неа.

Я согласен с тем, что изначально у меня есть только PEP 518, и я добавляю изоляцию в качестве фазы 2.

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

Хотя ни PEP 518, ни PEP 517 не требуют изолированных сборок, PEP 517 рекомендует их по веским причинам: https://www.python.org/dev/peps/pep-0517/#recommendations -for-build-frontends-non-normative.

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

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

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

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

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

• Поддержка PEP 517 не блокирует пункт 10
• PEP 518 в пункте 10
  
  
  
  • подписаться через pyproject.toml
  
  
  • поддерживает только бинарные сборки-зависимости
  
  
  • изолированные сборки
  
  

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

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

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

Во-вторых, что дает раскошеливание по сравнению с вызовом функции pip из Python? Есть ли какая-то причина, по которой внутренняя функция API не может быть создана/рефакторинг, которая будет делать все, что пытается достичь обстрел? Это должно обеспечить большую гибкость при вызове вызова (по сравнению с параметрами CLI). Это также может обеспечить больший контроль, позволяя более легко управлять состоянием всего процесса.

Есть ли какая-то причина, по которой внутренняя функция API не может быть создана/рефакторинг, которая будет делать все, что пытается достичь обстрел?

Во-вторых, что дает раскошеливание по сравнению с вызовом функции pip из Python?

Это позволяет выиграть время, которого у нас сейчас нет. pip уже отстает от графика выпуска.

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

Я не против рекурсии. Я против рекурсии процесса. Я думаю, что это нормально, если вы хотите использовать 100% ЦП (ну, это было бы 20% в Python), но в конечном итоге пользователь должен иметь возможность открыть диспетчер задач и убить максимум 15 процессов, которые там есть. Для меня ситуация, которая потенциально может вызвать взрыв процесса, неприемлема.

Однако это не отвечает на вопрос, почему это позволяет выиграть время. Что мешает создать внутреннюю функцию API, которая делает то же самое?

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

Однако это не отвечает на вопрос, почему это позволяет выиграть время. Что мешает создать внутреннюю функцию API, которая делает то же самое?

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

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

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

Это не означает, что вам нужно вызывать pip , вы можете создать API, который сериализует данные через интерфейс командной строки, вызывать python -c "from pip._internals import coolapithing; coolapithing(sys.stdin.read())" и считывать дополнительные данные со стандартного вывода. Можно было бы превратить рекурсивное решение, когда пипсы вызывают пипсы, вызывающие пипсы, вызывающие пипсы, превращая его в стек с помощью такого API (поскольку вся рекурсия также может быть описана как стек), вы просто по существу делаете частный API который вызывается как процесс.

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

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

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

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

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

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

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

Мне нравится идея @dstufft о преобразовании в итеративный / основанный на стеке подход и использование внутренней функции пипса с использованием шаблона python -c "from pip._internals import coolapithing; coolapithing(sys.stdin.read())" . Судя по обсуждению, это кажется самым простым, а также надежным.

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

Я изучил / немного подумал о преобразовании рекурсивного подхода в итеративный. Частичная работа @xoviat над PEP 518 (PR #4799) помогла мне найти точку рекурсии (с которой некоторые из вас, вероятно, уже знакомы). Это в его комментарии к коду:

# TODO: Use single process with recursion handling

где он затем вызывает pip install ... .

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

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

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

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

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

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

Мне также нравится идея @dstufft .

Вс, 29 октября 2017 г., 08:47 xoviat, уведомления@github.com написал:

@cjerdonek https://github.com/cjerdonek Я не вижу проблем с
эта идея. Но в конечном итоге кто-то должен это реализовать (я думаю
@pradiunsg https://github.com/pradiunsg собирался над чем-то поработать
в эти выходные?) и, как всегда, тогда могут быть обнаружены новые трудности.

—
Вы получаете это, потому что вас упомянули.

Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/pypa/pip/issues/4802#issuecomment-340234567 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ADH7SYImpWgJGg-DzQRcO_9hHfE6ZxEAks5sw-5RgaJpZM4QBdSg
.

Возвращаясь к этому, хотим ли мы продолжить подход стека + внутренний вызов, предложенный @dstufft?

/ping @ncoghlan @pfmoore @xavfernandez

Да, пожалуйста. Что-нибудь, чтобы продвинуть это вперед.

Есть ли кто-нибудь, кто может обобщить, где мы находимся с PEP 517 и PEP 518 по отношению к выпуску 10 пунктов? Конкретно:

1. Находится ли master в настоящее время в готовом к выпуску состоянии? Последнее, что я слышал, это то, что поддержка PEP 518 была нарушена (есть по крайней мере одна открытая проблема с блокировкой выпуска, связанная с PEP 518 - # 4647).
2. Вероятно ли, что у нас будет работающая реализация PEP 517 и/или PEP 518 в сроки, позволяющие отложить 10-й пункт до тех пор, пока они не будут доступны?
3. Предполагая, что мы исправим материал в (1), хотим ли мы сделать выпуск 10 пунктов без PEP 517/518? Мы подготовили хедз-ап электронное письмо о выпуске, чтобы люди знали, что это произойдет. И там есть несколько достаточно важных исправлений (например, исправления кодировки для Windows), которые было бы неплохо выпустить.

Я чувствую, что мы ждем блокировщиков релизов, но мы недостаточно близки к поддержке PEP 517/518, чтобы заблокировать на них 10-й пункт. Но я не думаю, что кто-то работает над #4647, кроме как в рамках реализации PEP 518.

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

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

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

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

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

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

Находится ли master в настоящее время в готовом к выпуску состоянии?

IIUC, на данный момент он может разветвить систему; это правильно? Если да, то я думаю, что нет.

Вероятно ли, что у нас будет работающая реализация PEP 517 и/или PEP 518 в сроки, позволяющие отложить 10-й пункт до тех пор, пока они не будут доступны?

Я думаю, что простым (краткосрочным) решением было бы просто ограничиться колесами для зависимостей сборки. Попробую на следующей неделе поковыряться. Если этого не произойдет, я буду в порядке, если мы удалим текущую поддержку PEP 518 из master и вырежем из нее 10.0.0.

Я не думаю, что кто-то работает над # 4647, кроме как в рамках реализации PEP 518.

Я думаю, вы имеете в виду полную реализацию PEP 518 с разрешенными зависимостями исходной сборки?

Да, и о # 4647 - описание @xoviat выше говорит, что исправление этого потребует изменения/перемещения кода и владения/видимости объектов (в частности, BuildEnvironment ), что нетривиально.

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

https://github.com/pypa/pip/blob/fc6b2c192088737f81259b6446f627f20ce46443/src/pip/_internal/wheel.py#L696

к:

finder.format_control = FormatControl(set(), set([':all:']))

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

да. Но это само по себе не будет адресом № 4647. Кроме того, ни один из этих кодов не идет
через резолвер.

В субботу, 2 декабря 2017 г., в 01:23 Томас Клюйвер, [email protected] написал:

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

https://github.com/pypa/pip/blob/fc6b2c192088737f81259b6446f627f20ce46443/src/pip/_internal/wheel.py#L696

к:

finder.format_control = FormatControl(set(), set([':all:']))

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

—
Вы получаете это, потому что вас упомянули.

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

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

Если кто-то хочет взять на себя мой первоначальный PR («исправить проблемы с PEP 518»),
не должно быть сложно изменить его, чтобы изоляция сборки не была
включен без pyproject.toml. Первоначальная причина, по которой он не был объединен
заключалась в том, что он отказался от поддержки установки зависимостей из исходного кода с помощью
PEP 518. Однако теперь, когда люди начинают понимать, что PEP 518 может
не быть в пункте 10 вообще, они могут быть более склонны принять этот PR. я
у меня лично нет времени отстаивать это, но это не должно останавливать других
от продвижения вперед, так как потребуется всего несколько строк изменений
(помимо xfailing теста PEP 518).

На самом деле, вопреки моему здравому смыслу, я готов реализовать как PEP 517, так и 518 в ближайшее время, если разработчики pip согласятся с моими условиями:

1. Зависимости будут только от колес изначально
2. Изначально у pip будет внутренний бэкенд сборки, хотя в конечном итоге он будет удален.

У меня нет проблем с 1; У меня нет предпочтений в любом случае для 2.

В воскресенье, 3 декабря 2017 г., в 02:36 [email protected] написал:

На самом деле, вопреки моему здравому смыслу, я готов реализовать как PEP,
517 и 518 в ближайшее время, если разработчики пипсов согласятся с моими условиями:

1. Зависимости будут только от колес изначально
2. pip изначально будет иметь внутренний бэкенд сборки, даже если он
   в конечном итоге будет удален

—
Вы получаете это, потому что вас упомянули.

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

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

Меня не особенно устраивает тон предложения «вопреки здравому смыслу… согласен с моими условиями». Я не собираюсь возражать, если другие разработчики pip будут рады принять это предложение, но лично у меня сейчас нет времени, чтобы возобновить всю дискуссию о деталях реализации. По сути, я уступлю в этом вопросе @dstufft и @xavfernandez ( @pradiunsg уже высказал свое мнение).

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

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

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

В воскресенье, 3 декабря 2017 г., 23:37 xoviat, уведомления@github.com написал:

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

—
Вы получаете это, потому что вас упомянули.

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

Честно говоря, дальнейшее обсуждение тона поста, вероятно, не является эффективным использованием чьего-либо времени, поскольку это не имеет отношения к включению этих функций в пункт 10. Однако мне нужна уверенность в том, что мои условия приемлемы для слияния с @pfmoore ( который указал, что не может дать такую ​​гарантию, что приемлемо, учитывая, что никому не платят за проведенное здесь время), @dstufft или @xavfernandez.

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

Согласен насчет тона. Я просто хочу сказать, что не буду объединять изменения[1], так что моя точка зрения здесь не так важна.

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

@xoviat Каковы ваши планы реализации в отношении итеративного и рекурсивного подходов, которые мы обсуждали выше?

Кроме того, чтобы уточнить, вы говорите, что сначала завершите частичную реализацию PEP 517 и 518, которые можно объединить, а затем полную реализацию, которую можно объединить? Или вы говорите, что будете выполнять только частичную реализацию, или вы говорите, что будете выполнять полную реализацию, проходящую через более ранние этапы, которые не обязательно будут объединяемыми? (Я частично пытаюсь лучше понять, что вы подразумеваете под «изначально» и «в конечном итоге» в своем комментарии .)

Первое условие полностью устраняет проблему рекурсии.

Кроме того, чтобы уточнить, вы говорите, что сначала завершите частичную реализацию PEP 517 и 518, которые можно объединить, а затем полную реализацию, которую можно объединить?

Я говорю о том, что я завершу частичную реализацию, которая будет работать в 95% случаев использования; особенно в случае, когда у зависимостей есть колеса (сейчас это очень распространено), и вы работаете на многих платформах Linux/Windows/OSX (подавляющее большинство пользователей).

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

Имейте в виду, что полная реализация потребует сортировки некоторых довольно неприятных проблем, для каждой из которых потребуется отдельный PR (поскольку наличие PR с более чем 100 комментариями обычно означает, что код не был хорошо проверен). [1]

[1] https://github.com/btc1/bitcoin/pull/11#issuecomment-313843216

Сейчас я закрою этот вопрос — у нас есть предварительная поддержка PEP 518 в пункте 10, который поддерживает только колеса в качестве зависимостей сборки. Я открою новую тему для обсуждения полной поддержки и другую для поддержки PEP 517 (цитируя отсюда, если это уместно).

Спасибо @ncoghlan @rgommers @cjerdonek за ваши идеи и помощь. Спасибо @takluyver за первоначальную реализацию PEP 518. Спасибо @xoviat (теперь @ghost ) за всю помощь в реализации этих изменений. Спасибо @benoit-pierre за помощь в улучшении текущей поддержки.

P.S.: сотый комментарий! :тада:

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