<p>pip 19.1 и режим разработки (с pyproject.toml - присутствует build-backend)</p>

Хотя я не пытаюсь распределять вину здесь, следует отметить, что гораздо более простым решением было бы просто удалить pyproject.toml . Причина, по которой это невозможно, по-видимому, заключается в том, что такие проекты, как black решили использовать этот файл для своей общей конфигурации, что, возможно, разрешено PEP 518 (в основном, это зависит от того, как вы определяете «инструмент сборки») но может считаться немного преждевременным, когда предполагаемое использование этого файла (PEP 517 и 518 все еще находились в разработке).

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

@pfmoore, неважно , как мы сюда попали и кто виноват.

Рабочий процесс, который это нарушает, следующий: вы хотите распространять свой код как PEP-517/518. И вы тестируете чистый PEP-517/518 в своем CI / tox. Однако при разработке базы кода полезно установить код в режиме разработчика (чтобы избежать необходимости переустанавливать пакет после каждого изменения кода для запуска тестов). В таком случае вы действительно хотите установить код в редактируемом режиме (но также сохранить pyprojec.toml). В этом случае удаление файла невозможно. Указание отсутствия сборок pep 517 также не работает.

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

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

¹ Возможно, стоит кому-то собрать воедино различные варианты использования, которые мы видим здесь, и задокументировать их в качестве отправной точки для неизбежного обсуждения «как расширить PEP 517 для поддержки редактируемого режима». По крайней мере, вся эта дискуссия проясняет, что необходимость в стандартном редактируемом режиме - это не то, что мы можем откладывать слишком долго.

@pfmoore , все в порядке, редактируемый режим всегда был достаточно близким приближением; нередактируемые тестовые костюмы - это те, которые подтверждают, 100% что код верен. Например, если кто-то загружает ресурсы, они могут вести себя по-другому. Но это уже так. Таким образом, необходимость передавать некоторые флаги - это нормально, однако на данный момент нет возможности сделать это. Можем ли мы исправить? --really-ignore-pep517-for-develop-mode меня устраивает.

У меня не сработало указание pep 517. Для тех, кто ударил это при использовании tox, добавление пользовательской строки install_command в tox.ini - это мой текущий обходной путь (у меня есть только pyproject.toml для установки длины строки для черного).

[testenv]
install_command =
    python -m pip install --no-use-pep517 {opts} {packages}

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

@gaborbernat Можете ли вы сделать что-то вроде простого сценария-оболочки, который вы используете при локальной разработке, который перемещает файл перед установкой в ​​редактируемом режиме? Или копирование файла pyproject.toml на место при работе в CI и т. Д.? Я не уверен, в какой именно ситуации, но похоже, что у вас будет достаточно гибкости при разработке рабочего процесса.

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

Хотя перемещение pyproject.toml назад и вперед могло бы решить проблему (ужасным ужасным образом), это нарушило бы параллельный режим. Представьте, что вы хотите запустить 5 сред tox параллельно, 4 из них используют PEP 517/518, а одна хочет редактируемую установку (например, это единственный способ покрытия кода cython). Мне снова кажется, что это плохое место, теперь нужна некоторая блокировка, чтобы удерживать, зачем изменять дерево работы, просто для того, чтобы получить редактируемую установку. На этом этапе я либо отключаюсь до pip <19.1, либо использую python setup.py develop ... Я бы действительно предпочел истинное отключение PEP-517 / PEP-518 за неясным флагом. Сценарии оболочки на этом этапе могут пройти через это, а не изменять исходный каталог на месте.

Представьте, что вы хотите запустить 5 сред tox параллельно, в 4 из них используется PEP 517/518, а в одном требуется редактируемая установка.

Хорошо, но это другой сценарий, чем вы упомянули выше. Я отвечал на то, что вы написали. Выше вы только что сказали, что хотите установить в режиме разработки при локальной разработке и запустить CI / tox в чистом PEP-517/518.

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

Ну, я никогда не говорил, что делаю install in develop mode when developing locally вручную (я тоже использую tox для этого) или не параллельно с какой-либо другой операцией в том же репо. установки pip на данный момент являются параллельными безопасными, ваше предложение нарушит эту константу, поэтому это не настоящий обходной путь.

Можем ли мы исправить?

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

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

Но да, со временем мы сможем исправить это.

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

Еще один вопрос - это что-то новое в pip 19.1? Поддержка PEP 517 была введена в 19.0 несколько месяцев назад - есть ли что-то в 19.1, что ухудшает ситуацию? Если нет, то почему эта проблема внезапно вспыхнула сейчас? Просто совпадение?

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

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

pip 19.0.0 разрешил режим разработки (без удовлетворения требований раздела) при наличии pyproject.toml. pip 19.1 через https://github.com/pypa/pip/pull/6370 вместо этого решил использовать жесткую ошибку.

Итак, # 6370 говорит использовать --no-use-pep517 . Вы говорите, что PR нарушен, и он не (как указано) «Get pip install -e снова работает для случая PEP 517-is-optional (при условии, что параметр --no-use-pep517 был передан)»?

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

см. https://github.com/pypa/pip/pull/6370#issuecomment -486156720

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

Это не удается:

ERROR: Disabling PEP 517 processing is invalid: project specifies a build backend of setuptools.build_meta in pyproject.toml

Похоже, это означает, что PIP отказывается отказаться от PEP 517, если в build-backend pyproject.toml даже если среда позволяет просто запустить setup.py напрямую.

@pfmoore Эта проблема касается первого из двух PR: https://github.com/pypa/pip/pull/6331, а не второго.

Первый - это случай, когда PEP 517 требует использования стиля pyproject.toml поэтому --no-use-pep517 не допускается.

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

@pfmoore Вот два основных комментария от вас, в которых мы говорили об этом до того, как были реализованы два PR:

• https://github.com/pypa/pip/issues/6314#issuecomment -469176276

• https://github.com/pypa/pip/pull/6331#issuecomment -473231822

@cjerdonek Спасибо. Это все еще кажется правильным - PEP 517 не поддерживает редактируемый режим, поэтому проекты не должны использовать его, если они хотят поддерживать редактируемый режим.

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

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

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

@pfmoore тем временем мы договариваемся о редактируемых установках, планируем ли мы по-прежнему предлагать устаревший редактируемый режим установки (за каким-то странным флагом) или pip 19.0.0 на данный момент отказался от поддержки редактируемой установки и работал только случайно до 19.1?

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

@gaborbernat Задавая эти вопросы, для ясности вы должны различать два случая, присутствует ли "build-backend" в pyproject.toml или нет, потому что в этих двух случаях ответ разный. Если вы не будете различать, это может создать путаницу, потому что люди не будут знать, о каком случае идет речь.

Изменено название проблемы, чтобы отразить ее масштаб.

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

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

Теперь, когда название задачи задает область действия, я еще раз спрошу:

Тем временем мы согласны с редактируемыми установками, планируем ли мы по-прежнему предлагать устаревший редактируемый режим установки (за каким-то странным флагом) или pip 19.0.0 на данный момент отказался от поддержки редактируемой установки и работал только случайно до 19.1?

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

@pfmoore тем временем мы договариваемся о редактируемых установках, планируем ли мы по-прежнему предлагать устаревший редактируемый режим установки (за каким-то странным флагом) или pip 19.0.0 на данный момент отказался от поддержки редактируемой установки и работал только случайно до 19.1?

Хм? Я не уверен, о чем вы здесь спрашиваете. И я не уверен, кто такие «мы» в этом контексте. Но мое личное мнение таково:

1. Редактируемые установки по-прежнему поддерживаются точно так же, как и до версии 19 - для проектов, не относящихся к PEP 517 (тех, у которых нет build-backend в pyproject.toml ). Вам может понадобиться --no-use-pep517 .
2. PEP 517 никогда не поддерживал редактируемые установки, хотя в pip 19.0 были случаи, когда он попадал в режим, который смешивал PEP 517 и устаревшую обработку. В этих случаях были проблемы в 19.0, мы исправили их в соответствии с принципом «PEP 517 не поддерживает редактируемые установки», уточнив, что редактируемый режим не поддерживается PEP 517.

По-видимому (помните, это только мое мнение!) Есть много людей, которые выбрали PEP 517, не слишком беспокоясь о проблеме «не поддерживает редактируемые установки», которые в конечном итоге полагались на поддержку pip. Теперь они борются из-за (2) выше, и было бы хорошо, если бы у pip был ответ для них. Я бы предпочел, чтобы этот ответ был основан на стандартах, но я понимаю, что это не краткосрочное решение. Если кто-то предлагает краткосрочное решение (PR), я рассмотрю его на этом этапе, но мне совсем не нравится какой-либо вариант --make-it-go-away - я бы предпочел все, что делается, лучше подходит для того, что уже есть у pip.

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

PS Один из возможных вариантов ( @cjerdonek - я не знаю, насколько это практично, может, вы можете прокомментировать?) - это изменить места, где мы поднимаем make_editable_error чтобы вместо этого просто сообщить о сообщении как (сильное ) предупреждение, в котором говорится, что использование редактируемого с проектами PEP 517 не определено, и вы используете его на свой страх и риск, но затем продолжайте без повышения. Если это возвращается к старому поведению, пользователь был предупрежден, но мы не останавливаем его сборку. Я ожидаю, что если мы это сделаем, мы не будем предлагать поддержку пользователям, которые испытывают странное поведение, если отображается это сообщение ... (я также не стал бы добавлять тесты для этого поведения или чего-то в этом роде - сделайте его действительно неподдерживаемым ).

Я был бы в порядке, если бы на stderr было написано большое красное предупреждение - PEP-517 detected but editable install requested, this combination is not supported, will fallback to pre PEP-518/7 mode ; @cjerdonek ?

PS. Мы, как и в PyPa, поддерживаем пакеты PyPa.

Обратите внимание, что я не собираюсь «возвращаться к режиму, предшествующему PEP-517/8» - в действительности я думаю, что это скорее «возврат к какому-то странному режиму франкенштейна, который в основном унаследован с некоторым PEP 518» :-) Но Дело в том, что я на самом деле не знаю, что он сделает.

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

@pfmoore , разве он не pyproject.toml , что означает то же состояние, в котором он был до PEP-517 / PEP-518 - вероятно, означает просто вызов python setup.py develop до тех пор, пока мы не получим стандартизированную разработку режим.

Обратите внимание, что я не собираюсь «возвращаться к режиму до PEP-517/8» - в действительности я думаю, что это скорее «возврат к какому-то странному режиму франкенштейна, который в основном унаследован с некоторым PEP 518» :-) Но Дело в том, что я на самом деле не знаю, что он сделает.

Я понимаю, что в прошлый раз у нас было много проблем с получением поведения pip ~=18 PEP 518 после того, как были внесены изменения PEP 517, но я думаю, что идеальной ситуацией было бы вернуться к поведению PEP 518 pip (т.е. изолированную среду сборки), затем вызовите setup.py develop .

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

pipenv 2018.11.26 создать новый virtualenv, в котором (с сегодняшнего дня) по умолчанию установлен pip 19.1 . В корневом каталоге проекта есть файл pyproject.toml со следующим разделом:

[build-system]
requires = [
    "setuptools",
    "wheel",
]

что означает, что существует определенная "сборка-бэкэнд", я полагаю. Пакет устанавливается в режиме редактирования для удобства (тесты и т. Д.). pyproject.toml также содержит настройки для black и tidypy . @pfmoore не может вспомнить, где вы упомянули, что только черный использует pyproject.toml для своих настроек, но, очевидно, также tidypy делает это.

Поскольку я использую pipenv (а не pip напрямую), мне не удалось заставить --no-use-pep517 работать (поскольку версия 2018.11.26 не поддерживает это). Единственный способ вернуть среду к работе - это export PIP_USE_PEP517=false . Если есть лучший способ сделать это (по крайней мере, на время, пожалуйста, не стесняйтесь вмешиваться).

Ранее сегодня утром (до этого isssue был открыт) Я также попытался удалить [build-system] участок от pyproject.toml файла без какого - либо успеха, так что я не уверен , что если различие между с / без "build-backend" это реально или просто я что-то не так понимаю.

В своих проектах я, естественно, указывал PEP517 / 518 , чтобы (а) доказать поведение, (б) согласиться с передовыми практиками и (в) пропагандировать функциональность.

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

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

Варианты, которые рассматривает наша команда разработчиков:

• Блокировать пип 19.1 и новее в индексе пакета
• Прекратите использовать редактируемые проекты и разберитесь с последствиями
• Взломайте tox, чтобы привязать его к старому пипу

Я бы предпочел подход типа --really-ignore-pep517-for-develop-mode который предложил Бернат.

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

@pfmoore , разве он не pyproject.toml , что означает то же состояние, которое было до PEP-517 / PEP-518 - вероятно, означает просто вызов python setup.py develop до тех пор, пока мы не получим стандартизированную разработку режим.

@pfmoore не будет ли он откатиться к тому же самому состоянию, что и без pyproject.toml, что означает то же состояние, в котором он был до PEP-517 / PEP-518 - вероятно, означает просто вызов python setup.py develop до тех пор, пока мы не получим стандартизованный режим разработки.

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

Давайте выясним и создадим решение - вот мое предложение. Можем ли мы согласиться с этим, пока у нас есть редактируемый режим PEP-517, а пока мы делаем:

Я думаю, что идеальной ситуацией было бы вернуться к поведению pip PEP 518 (то есть создать изолированную среду сборки), а затем вызвать setup.py develop.

это правильный способ быть; с большим красным сообщением о том, что это поведение изменится, как только мы сделаем правильный редактируемый режим PEP-517. Если это так, я могу попробовать создать PR, сделав это, и выпустить его как 19.1.1 .

Это позволит людям следовать передовым методам распространения PEP-517/8, но вернуться к чему-то разумному для разработки (что в какой-то момент изменится).

@gaborbernat Я считаю, что @ncoghlan попытался восстановить поведение PEP 518, когда мы впервые пытались решить проблему относительного импорта и в конечном итоге отказались от него. У него могут быть мысли, насколько это возможно.

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

Изменить Чтобы уточнить: я не имею в виду «вернуться к PEP 518» как вариант pip , а просто как путь к коду. Насколько я понимаю, когда была добавлена ​​поддержка PEP 517, она была добавлена вместо поддержки PEP 518, поэтому они неразрывно связаны. Наличие пути кода, который может использовать pip который возвращается к PEP 518 в определенных сценариях, - это то, что нам нужно дважды сейчас, чтобы внедрить исправления «быстрого исправления».

Я бы сам не стал делать PEP-517 отключаемым как таковой. Но вместо этого отключите только в случае редактируемой установки.

_ (это, наверное, тема для отдельного обсуждения, но я изложу ее здесь) _

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

PS Один из возможных вариантов ( @cjerdonek - я не знаю, насколько это практично, может, вы можете прокомментировать?) - это изменить места, где мы поднимаем make_editable_error, чтобы вместо этого просто сообщить о сообщении как (сильное) предупреждение,

Это было бы просто (по сути, просто измените raise на регистрацию предупреждения в соответствующих случаях и обновите тестовые примеры). Соответствующий код начинается здесь:
https://github.com/pypa/pip/blob/9816d17ccaf33dc5450b74ad310b6827915e2fe7/src/pip/_internal/pyproject.py#L136
Кому-то просто нужно решить, каким должно быть поведение. Лично я согласен с тем, что решит подчинюсь ему.

Я думаю, что предложение @pfmoore неплохо для немедленного тушения пожара ...

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

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

@pfmoore Чтобы уточнить, было ли ваше предложение в этом комментарии о том, что если запрашивается редактируемый режим (как для случая «build-backend», так и без- «build-backend»), то он автоматически отключается от обработки PEP 517 с соответствующими предупреждениями? Или в обоих случаях потребуется --no-use-pep517 ? Насколько я понимаю, ваше предложение (независимо от того, требуется ли --no-use-pep517 ) состоит в том, что в обоих случаях должно быть предупреждение о том, что устаревшее поведение может работать иначе, но формулировка будет более сильной в случае, если "build -backend "присутствует (говоря, что поведение в настоящее время не определено в спецификации).

Мне показалось бы странным, если бы мы требовали --no-use-pep517 только тогда, когда "build-backend" отсутствует. Это будет означать, что добавление «build-backend» при использовании редактируемого режима будет иметь тот же эффект, что и передача --no-use-pep517 (будет отличаться только текст предупреждения).

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

Но я совершенно не чувствую, какой вариант здесь был бы "хорошим". Если ситуация достаточно серьезная, может потребоваться восстановление # 6314 и # 6331. Если нет, то кто-то должен решить, как сохранить дух этих двух патчей, исправляя текущую поломку. Но помимо того, что я не был доволен опцией тупого инструмента «выключить PEP 517», у меня вообще не было времени обдумать этот вопрос.

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

Что касается дальнейшего пути, я считаю, что --no-use-pep517 должен быть необходим в обоих случаях или ни в одном из них (с ключом build-backend или без него). Этот выбор приводит к компромиссу, когда дело доходит до будущих изменений в поведении. Если нам не нужен флаг сейчас, люди будут жаловаться, когда PEP 517 добавит поддержку редактируемого и все будет вести себя по-другому, и, возможно, ограничит нас с точки зрения того, какой выбор мы можем сделать при рассмотрении редактируемого для PEP 517. Если нам действительно нужен флаг Теперь проблема в том, что люди могут жаловаться на неудобство использования этой опции и, возможно, она не во всех случаях работает правильно (например, проблема с вложенным файлом требований).

Я согласен с вашим анализом. Я бы предпочел требовать --no-use-pep517 чтобы сделать это явным. Если я понимаю приведенные выше комментарии, это, по сути, заставляет --no-use-pep517 действовать аналогично тому, что люди просили --make-it-just-work flag, поэтому я думаю, что это должно быть приемлемым неудобством.

Я только что опубликовал первоначальный PR (https://github.com/pypa/pip/pull/6442) для обзора, который реализует то, что я и

Всем, кто ищет обходной путь - вы можете подумать:

1. Используя pip 19.0;
2. export PIP_USE_PEP517=false (кредит: @ariciputi );
3. если pyproject.toml существует только из-за black , вы можете переименовать его и использовать black --config black_config.toml . ;
4. не использовать редактируемый режим;

Пополняя список

1. https://github.com/ansible/molecule/pull/2009 / https://github.com/jaraco/skeleton/commit/123b0b2 (кредит: @jaraco);

Спасибо! Теперь нам просто нужен релиз, @dstufft

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

@ariciputi Содержимое pyproject.toml вы указали в своем комментарии здесь , имеет только ключ "требует" в разделе "build-system", а не ключ "build-backend". Когда в сообщении упоминается ключ «build-backend», это означает, что буквальная строка должна быть в файле toml.

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

В конце концов, я почти уверен, что нам понадобятся редактируемые установки или что-то еще, чтобы принять PEP 517, поэтому временная миграция людей с редактируемых установок, пока мы придумываем стандарт, кажется контрпродуктивной. Я думаю, что откат к setup.py develop не должен требовать --no-use-pep517 в любом случае, просто выдайте предупреждение автоматически.

Слишком поздно обсуждать здесь, но большинство моих проектов попадают именно в категорию, которую описывает @gaborbernat - у меня есть -e . в моем requirements-dev.txt , и при настройке для них новой среды разработки Я только что закончил $ pip install -r requirements-dev.txt .

Я не знаю, насколько универсальным является решение python setup.py develop , но в одном проекте, в котором я его пробовал, оно работало нормально. (Я использую конфигурацию src , и мне, в частности, нужно, чтобы рабочий каталог проекта был установлен в среде, чтобы набор тестов мог импортировать пакет.)

Если setup.py develop может быть общим временным решением для большинства этих проблемных случаев (не знаю, будет это или нет), может быть достаточно просто дополнить сообщение об ошибке «редактируемые установки, не поддерживаемые PEP517» чем-то вроде :

.... Until editable install support is defined and implemented for PEP517 setuptools projects, running 'python setup.py develop' may be a suitable workaround.

FWIW, я только что протестировал python setup.py develop в качестве альтернативы -e . в моих файлах требований , и мой набор тестов проходит локально, мой CI прошел нормально , и tox (v3.9, до настоящего времени) был совершенно доволен:

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

Если это поможет, я просто разместил PR # 6447, чтобы исправить # 6438 и разрешить использование --no-use-pep517 (и --use-pep517 ) в файлах требований.

@pganssle IMO, он подчеркивает необходимость того, чтобы мы начали работу над расширением PEP 517 для поддержки редактируемого режима в качестве приоритетного вопроса.

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

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

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

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

Это, вероятно, наивно и, возможно, уже было рассмотрено в предыдущем обсуждении редактируемых установок, но: может ли включение редактируемых установок быть таким же простым ("простым"), как добавление поля editable_install в [build-system] в pyproject.toml ? Он будет удерживать (серию) команд для выполнения для достижения редактируемой установки; и, как и по умолчанию для других полей [build-system] предполагается, что setuptools в качестве серверной части сборки, по умолчанию будет editable_install=python setup.py develop ?

Теоретически система сборки и (редактируемая) система установки должны быть полностью разделены, верно? Если это так, то системе сборки действительно нужно знать, какую команду вызывать в системе установки / an для достижения редактируемой установки, если она для нее указана.

Это, вероятно, потребует сначала изменений в PEP517 / 518, хотя ...?

@bskinn Редактируемые установки - это бэкэнд-функция, поэтому нет смысла требовать от каждого проекта, использующего конкретный бэкэнд, копировать определенное заклинание в свой файл pyproject.toml - вместо этого они должны быть способом для фронтендов запрашивать бэкэнды для создания локальной редактируемой установки.

Мы переместили обсуждение на https://discuss.python.org/t/pip-19-1-and-installing-in-editable-mode-with-pyproject-toml/1553.

Всем привет,

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

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

Как проекты с pyproject.toml (с и / или build-backend разделом) развиваются с использованием виртуальных сред (кроме, конечно, установки PYTHONPATH )?

Лично я просто использовал tox для установки проекта в virtualenv для тестирования. А для специального тестирования я выполняю цикл сборки и установки. Это не так обременительно, и я чувствую себя более комфортно с этим, чем с редактируемыми установками (и применяемым ими взломом путей). Это касается всех проектов, а не только тех, которые используют PEP 517.

Это, конечно, чисто мое личное мнение и рабочий процесс.

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

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