Pipenv: [вопрос] Как интегрироваться с setup.py?

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

from pipenv.project import Project
from pipenv.utils import convert_deps_to_pip

pfile = Project(chdir=False).parsed_pipfile
requirements = convert_deps_to_pip(pfile['packages'], r=False)
test_requirements = convert_deps_to_pip(pfile['dev-packages'], r=False)

Дайте нам знать, если у вас есть дополнительные вопросы :)

Вышеизложенное очень полезно. У меня возникли проблемы с setup.py в зависимости от того, что Pipenv был установлен в virtualenv до того, как setup.py install (или что-то еще) можно будет запустить. Единственные решения этой проблемы, которые я могу придумать, — это либо включение Pipenv в проект, что кажется далеко не идеальным, либо даже какой-то взлом setup.py для установки Pipenv перед попыткой запустить импорт from pipenv... , что кажется неправильно. У кого-нибудь есть идеи или лучшие решения, чем это?

Должны ли мы ~ беспокоить ~ предлагать другим членам сообщества Python (PyPA и т. д.) просто благословить Pipenv как официально включенный инструмент в будущих выпусках Python? 😄

Поможет ли добавление pipenv в setup_requires ? Похоже, что также может быть необходимо добавить его в install_requires , что кажется неудачным.

Не делайте этого.

@kennethreitz , что вы подразумеваете под «этим»? Вы имеете в виду интеграцию с setup.py, решение @nateprewitt или последние два предложения?

Итак, как пользователи должны знать, что им нужно установить pipenv?

Поскольку pipenv — это инструмент, используемый для установки вещей, а не наоборот, нет причин требовать его в вашем setup.py. Кеннет предостерегает от импорта pipenv в setup.py, поскольку это приложение cli и может вызвать проблемы.

17 октября 2017 г., в 9:37, Иддан Ахаронсон ( [email protected] ) написал:

Итак, как пользователи должны знать, что им нужно установить pipenv?

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

так как я могу использовать код @nateprewitt - в setup.py?

@iddan : я попытался решить проблему начальной загрузки Pipenv, просто внедрив версию Pipenv в скелет моего проекта (https://github.com/elgertam/cookiecutter-pypackage/blob/master/%7B%7Bcookiecutter.project_slug%7D %7D/setup.py). До сих пор у меня не было никаких проблем, хотя я не могу сказать, что у меня было много возможностей проверить это в ситуации, когда я устанавливаю пакет, используя setup.py .

Я могу понять, почему мы беспокоимся о том, чтобы не запускать CLI при загрузке setup.py, но, насколько я могу судить, код, который я использую (скопировано из поста @nateprewitt здесь), довольно безопасен.

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

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

Pipenv предназначен для управления средой и инструмента развертывания, а не для распространения, как setup.py. Мы настоятельно рекомендуем документировать, что вы используете Pipfile, и, возможно, ссылаться на pipenv.org для получения инструкций по установке. Относитесь к этому так же, как вы относитесь к pip, от пользователя не ожидается, что он будет устанавливать pip каждый раз, когда он устанавливает новый пакет Python.

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

@nateprewitt , если мы хотим распространять пакет (обычными средствами, используя pip ), должны ли мы поддерживать копию списка зависимостей в setup.py или requirements.txt ? Я надеялся использовать свой Pipfile как единственный источник правды.

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

Если я не ошибаюсь, код в https://github.com/kennethreitz/pipenv/issues/209#issuecomment -278185133 безопасен для использования, если вы создаете колесо (=binary dist), но не если вы создаете sdist (=исходный dist).

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

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

О, да. @tuukkamustonen , мой конкретный вариант использования - sdist. Поскольку я не хочу требовать, чтобы пользователь пакета устанавливал pipenv перед выполнением pip install , я предполагаю, что застрял в получении install_requires за пределами setup.py (т.е. вручную или в составе сборки)?

Если я правильно понимаю, Кеннет и другие сопровождающие не хотят, чтобы мы относились к Pipenv как к зависимости проекта, как мы могли бы относиться к pytest или даже к обычной зависимости пакета. В идеале мы должны установить и обновить Pipenv таким же образом, как и сам pip , т.е. pip устанавливается при установке Python или при установке virtualenv создается. Именно это имел в виду Кеннет, когда сказал: «Не делай этого».

Тем не менее, @isobit поддержал мои мысли о том, что Pipfile должен быть единственным источником правды. Я вижу два убедительных варианта использования Pipfile (и есть и другие): во-первых, конвейер CI/CD, который зависит от Pipfile для настройки среды сборки, гораздо надежнее, чем конвейер, зависящий от requirements.txt; и, во-вторых, участник может вслепую попытаться установить проект на основе Pipfile и может быть разочарован, если python setup.py install не работает так, как он ожидает. Учитывая, что ни Pipenv, ни pip с поддержкой Pipfile пока не являются стандартными инструментами Python, а Pipenv действительно является эталонной реализацией для Pipfile, у нас есть несколько вариантов решения проблемы:

1) Укажите в документации вашего проекта, что ваш проект зависит от Pipenv . Вы по-прежнему можете полагаться на Pipenv в вашем setup.py , и это сломается, если Pipenv не установлен в вашей среде Python. Конкретно, участник вашего кода должен вручную установить Pipenv на свой virtualenv , чтобы установить проект с setup.py .
2) По-прежнему setup.py зависит от requirements.txt , который вы периодически генерируете на основе ваших Pipfile . Это остается полностью совместимым с pip и setuptools , но требует, чтобы любой сопровождающий генерировал requirements.txt всякий раз, когда проект собирается и развертывается. Возможным вариантом этого может быть обновление конвейером CI/CD requirements.txt во время сборки.
3) Добавьте версию Pipenv в проект и вызовите ее, используя from _vendor.pipenv.project import Project... внутри setup.py . Один из вариантов этого может заключаться в том, чтобы импортировать только из вендоризированной версии, когда глобальный импорт терпит неудачу.
4) Какой-то другой вариант, который здесь не представлен и до которого я не додумался.

Я лично использую (3) (см. https://github.com/kennethreitz/pipenv/issues/209#issuecomment-300550425), пока Pipfile не станет более распространенным стандартом, после чего у меня не будет ни одного из моих проектов. зависят от кода Pipenv напрямую, поскольку Pipenv явно предназначен для управления virtualenv на основе Pipfile, а не обязательно самой библиотеки Pipfile.

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

У меня такое ощущение, что проблема здесь возникает из-за изначального неправильного использования (IMO) requirements.txt с самого начала. Это не относится к использованию pipenv .

Я укажу на эту замечательную статью от Дональда Стаффта, setup.py vs requirements.txt:
https://caremad.io/posts/2013/07/setup-vs-requirement/

TL; DR (но вам действительно следует прочитать): setup.py 's install_requires предназначен для детализации требований (зависимостей) пакета. requirements.txt (которое здесь будет заменено комбинацией Pipfile / Pipfile.lock ) следует использовать для указания того, какие именно пакеты будут использоваться для удовлетворения требований, исходя из метаданные из setup.py , чтобы создать воспроизводимую среду.
Заполнение install_requires из requirements.txt похоже на возвращение назад.

setup.py 's install_requires =/= requirements.txt (или Pipfile / Pipfile.lock ).
Pipfile (или, скорее, Pipfile.lock ) должен быть единственным источником достоверности пакетов для установки в среде приложения.
setup.py install_requires предоставляет метаданные, используемые для создания действительного Pipfile.lock .

Я думаю, отсюда и трение. Я надеюсь, что это имеет смысл.

Мне очень нравится этот ответ, Винсент, и я абсолютно согласен с тем, что Pipfile.lock является полной (и лучшей) заменой requirements.txt .

Однако, используя Pipenv в течение нескольких месяцев, мое использование Pipfile заставляет меня думать, что install_requires действительно почти идентично тому, что происходит в Pipfile . Если мне нужно numpy , я pipenv install numpy и новая запись попадает в группу [packages] моего Pipfile: numpy = "*" . Другими словами, мое использование полностью отличается от requirements.txt , которое я просто генерировал перед фиксацией с помощью pip freeze > requirements.txt .

Возможно, это просто своеобразный способ, которым я использую Pipenv, и я иду против течения (я также устанавливаю свой virtualenv в .venv/ внутри каталога проекта, так что я мошенник Pythonista), в котором случае я могу легко следовать соглашению сообщества Python о наличии разделительной стены между setup.py и Pipfile | Pipfile.lock | requirements.txt .

Что мне здесь не хватает, @vphilippon?

Спасибо за информацию, @vphilippon. Возможно, мы собираемся сделать это в обратном направлении, похоже, что на самом деле мы хотим обратного — использовать абстрактные зависимости от install_requires в нашем Pipfile, как Дональд упоминает в отношении -e . в requirements.txt . Похоже, об этом уже была проблема (# 339), но, похоже, она никуда не делась.

Это уже включено в синтаксис Pipfile? Я только что заметил, что библиотека запросов Pipfile использует "e1839a8" = {path = ".", editable = true, extras=["socks"]} в разделе пакетов. Что-то похожее видно в примерах Pipfile , но другой документации я не вижу.

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

Теперь давайте перейдем к этому.

Я начну с этого утверждения @elgertam :

[...] мое использование Pipfile заставляет меня думать, что install_requires действительно почти идентичен тому, что происходит в Pipfile. Если мне нужен numpy, я pipenv устанавливаю numpy, и новая запись попадает в группу [packages] моего Pipfile [...]

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

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

Удивительно, но ваше использование не так уж отличается, если подумать:

• Ваш предыдущий рабочий процесс: pip install stuff -> pip freeze > requirements.txt -> фид install_requires из requirements.txt
• Ваш новый (попытка) рабочий процесс: pipenv install stuff -> Pipfile автоматически обновляется -> попытка накормить install_requires с помощью Pipfile .
• Какова предполагаемая идея: добавить материал в install_requires -> pipenv install -> Environment и обновить Pipfile.lock .

И для этого предполагаемого способа работы вам нужен Pipfile , в котором говорится, что вы хотите установить свое приложение.
Что-то вроде requests Pipfile , связанных @isobit.

Или, пример:

[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true

[dev-packages]
pytest = ">=2.8.0"
tox = "*"

[packages]
"-e ." = "*"

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

Это может выглядеть немного «бесполезно», так как сейчас все управляется одним пакетом, но, скажем, вы хотите установить свое приложение, но с requests[security] , но это не строгая зависимость от вашего приложения, вы do pipenv install requests[security] , а затем:

[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true

[dev-packages]
pytest = ">=2.8.0"
tox = "*"

[packages]
"-e ." = "*"
requests = { extras = ['security'] }

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

Что мне здесь не хватает, @vphilippon? Почему [пакеты] Pipfile слишком ограничены для использования в install_requires или test_require?

Если я объяснил это достаточно хорошо, вы можете видеть, что все должно быть наоборот.
Вы помещаете свои зависимости в install_requires , вы помещаете свой пакет в Pipfile , а затем получаете среду с Pipfile.lock для воспроизводимости (поскольку она будет разрешать и уважать ваши зависимости пакетов).

За test_require я признаю, что не уверен, что это подходит ко всему этому. IIRC, это особенность setuptools . Мы могли бы возразить, что это набор абстрактных зависимостей для тестирования, и ожидать, что pipenv разрешит и установит те, которые затем делают pipenv install --dev для всех пакетов, но мне кажется, что это не совсем правильно. У меня нет четкого представления или мнения по этому поводу и обоснованию этого, извините.

Я надеюсь, что все это как-то имеет смысл.

@vphilippon Вы довольно хорошо объяснили, и я думаю, вы меня убедили.

TL;DR: укажите абстрактные, абсолютно необходимые зависимости в setup.py , затем добавьте контекст (и, следовательно, конкретизацию) в Pipfile и Pipfile.lock , включая фантастическую "-e ." = "*" запись.

Проблема с https://github.com/kennethreitz/pipenv/issues/209#issuecomment -337409290 заключается в том, что когда мы хотим развернуть наше приложение на сервере, мы не получаем воспроизводимую среду.

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

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

В этом случае мы должны полагаться на файл блокировки в стиле requirements.txt (в котором указываются точные версии даже для транзитивных зависимостей). Однако не похоже, что pipenv позволяет исключить требования к разработке в pipenv lock -r (например, pipenv lock --no-dev -r ), чтобы мы действительно могли создать такие requirements.txt (которые затем могут быть читать в install_requires )?

Я процитирую статью Дональда Стаффта:

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

Другими словами: приложение — это не пакет. Приложение — это среда с установленным набором конкретных зависимостей. Зависимости приложения должны быть представлены requirements.txt (или Pipfile / Pipfile.lock ), а не одним пакетом install_requires .

Лично я бы сказал, что полный набор закрепленных зависимостей (включая транзитивную) должен находиться в requirements.txt для приложения, а не в setup.py пакета. Это подчеркивает идею о том, что развертывание приложения выполняется не с pip install myapp==1.0.0 , а с pip install -r requirements.txt (или pipenv install с Pipfile.lock ), где requirements.txt включает myapp==1.0.0 , а также все другие закрепленные зависимости и транзитивные зависимости.
Может показаться, что я зашел слишком далеко, но я работал в контексте, когда развернутое «приложение» управляется набором пакетов. Не существует ни одного пакета, представляющего само приложение, поэтому идея о том, что «пакет — это не приложение», была брошена мне в лицо довольно рано 😄 .

У меня есть сильное ощущение, что Pipenv/Pipfile/Pipfile.lock следует этой идее.
Вот почему кажется, что существует разрыв для перехода от Pipfile.lock к setup.py 's install_requires : в любом случае это действительно не должно быть сделано таким образом.

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

@vphilippon Я думаю, что существуют разные точки зрения и терминология. Но в конечном итоге нам нужен список закрепленных зависимостей для установки. Таким образом, requirements.txt с закрепленными версиями (или пакет с такими объявленными зависимостями, не имеет большого значения). Вопрос в том, как собственно скрафтить такой файл?

С помощью pip-compile (из pip-tools ) я могу скомпилировать такой requirements.txt из requirements.in , и он будет содержать только те зависимости, которые нужны моему приложению, не являющиеся разработчиками. Я не уверен, правильно ли я интерпретирую ваш ответ - вы действительно имеете в виду, что мы должны поддерживать закрепленные зависимости requirements.txt вручную (также слегка дублируя то, что уже находится в setup.py ), также для транзитивные зависимости? Это не может быть решением...

Если бы было pipenv lock --no-dev -r , я думаю, это решило бы эту проблему.

@tuukkamustonen Извините за путаницу, я действительно только обращался к идее install_requires против requirements.txt / Pipfile / Pipfile.lock .

Таким образом, требования.txt с закрепленными версиями (или пакет с такими объявленными зависимостями, не имеет большого значения).

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

Однако не похоже, что pipenv позволяет исключить требования разработки в pipenv lock -r

Но в конечном итоге нам нужен список закрепленных зависимостей для установки. [...] Вопрос в том, как на самом деле создать такой файл? [...] С помощью pip-compile (из pip-tools) я могу скомпилировать такие требования.txt из требований.in, и он будет содержать только те зависимости, которые не относятся к разработчикам, которые нужны моему приложению.

Ах, я сначала пропустил эту часть, извините. И, кажется, вы правы: я не могу найти способ сказать pipenv install --not-dev-stuff (хотя я был почти уверен, что он есть, странно) и создать среду без разработки. Какой смысл тогда иметь 2 отдельных раздела? Тогда я мог бы что-то упустить, и это не связано с использованием с setup.py . Возможно, это стоит обсудить в новом выпуске.

РЕДАКТИРОВАТЬ:
Я сделал ошибку здесь. Я действительно не нашел способа сгенерировать Pipfile.lock без пакетов разработки, но в новой среде с существующими Pipfile / Pipfile.lock делаю pipenv install не устанавливает пакеты dev. Это не решает проблему @tuukkamustonen , но я ошибался, когда говорил, что невозможно установить «среду prod», моя ошибка.

Уф, это было много, чтобы наверстать упущенное.

Если я не ошибаюсь, код в #209 (комментарий) можно безопасно использовать, если вы создаете колесо (=binary dist), но не при сборке sdist (=исходный dist).

@tuukkamustonen предназначен только для использования в автономном сценарии для развертывания, не включайте его в свой setup.py. Это полухакерский обходной путь, который использовался до появления pipenv lock -r много месяцев назад. Однако этот подход будет работать для вашего варианта использования разделения packages и dev-packages .

Я лично использую (3) (см. # 209 (комментарий)) до тех пор, пока Pipfile не станет более распространенным стандартом, после чего у меня не будет ни одного из моих проектов, напрямую зависящих от кода Pipenv, поскольку Pipenv явно предназначен для инструмент для управления virtualenv на основе Pipfile, а не обязательно самой библиотеки Pipfile.

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

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

Я думаю, вы вполне соответствуете нашему видению продолжительности проекта. Спасибо, что собрали все это и так хорошо сформулировали @vphilippon!

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

Я написал конкретное предложение в https://github.com/pypa/pipfile/issues/98 , которое, я считаю, дает нам что-то действенное и прагматичное, что могло бы улучшить DX для обслуживания библиотек Python.

Мысли?

import json, jmespath

install_requires = []
with open('Pipfile.lock') as f:
    context = json.loads(f.read())
    install_requires.extend(map(
        lambda n, v : n + v,
        jmespath.search('default | keys(@)', context),
        jmespath.search('default.*.version', context),
    ))

setup(
    name='foobar',
    packages=find_packages(),
    setup_requires=['jmespath'],
    install_requires=install_requires,
)

@cornfeedhobo Насколько я понимаю, setup_requires плохо работает с pip. Не могли бы вы рассказать немного о том, как бы вы предложили использовать этот образец?

Пример не будет работать, если вы сначала не установите jmespath, потому что setup.py оценивается как обычный код Python. Аргумент setup_requires на самом деле ничего не дает: если программа зайдет так далеко, jmespath гарантированно будет установлен.

Я упомянул об этом в другом выпуске, но не могу найти его (в трекере так много дублирующихся обсуждений, что уже невозможно ничего найти), поэтому я повторю еще раз: Пожалуйста, не кладите ничего, что не встроено. внутри setup.py, если вы не предоставите надлежащий запасной вариант или у вас нет веских причин. Пакет, содержащий указанный выше setup.py , даже не будет работать с Pipenv с jmespath, установленным в virtualenv; Pipenv вызывает setup.py egg_info в чистой среде и не сможет выполнить импорт jmespath. Это плохая практика. Пожалуйста, избегайте этого.

@epot Я не знал об этом

@uranusjr Спасибо за продуманный ответ с подробностями. Я просто изучаю весь этот вопрос, так что я мог бы вернуться для большего смущения. Я также отслеживаю pypa/pipfile#98.

Что, если нам не требуется jmespath ?

import json


install_requires = []
tests_require = []

with open('Pipfile.lock') as fd:
    lock_data = json.load(fd)
    install_requires = [
        package_name + package_data['version']
        for package_name, package_data in lock_data['default'].items()
    ]
    tests_require = [
        package_name + package_data['version']
        for package_name, package_data in lock_data['develop'].items()
    ]

@mschwager Вы не хотите закреплять версию, иначе у пользователей возникнут трудности. #1921 — это пример библиотеки, использующей == , что приводит к поломке пользовательской сборки.

Приношу свои извинения, но в чем разница между использованием setup.py для использования его в качестве пакета или requirements.txt / Pipfile для управления зависимостями указанного пакета? Требуемые библиотеки ДОЛЖНЫ быть идентичными между setup.py и requirements.txt / Pipfile , верно? Поэтому нет причин не интегрировать Pipfile . setup.py уже анализирует requirements.txt . Почему он не должен анализировать Pipfile ?

Было бы здорово избавиться от requirements.txt и просто использовать Pipfile

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

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

Как вы сказали, нет причин не разрешать setup.py анализировать Pipfile. Я с нетерпением жду, когда вы это сделаете :)

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

Однако было бы интересно посмотреть, какова долгосрочная дорожная карта pipenv. Было бы здорово, если бы он стал основным инструментом в Python. например, каким-то образом заменяет setup.py или генерирует соответствующий setup.py для пользователя, в любом случае pipenv, являющийся де-факто менеджером пакетов, потрясающий. Просто интересно, есть ли возможность расширить область действия, включив в нее setup.py?

Если pipenv похож на npm и т. д., то их package.json позволяет удаленную установку, и нет никаких причин, по которым pipenv не может взаимодействовать или заменять setup.py, что делает его областью действия. Я имею смысл или это звучит так, будто я принимаю сумасшедшие таблетки?

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