Pipenv: Как синхронизировать setup.py install_requires и Pipfile

Есть ли у pipenv API Python, который можно использовать? Я вручную обновляю список, когда работаю над проектом, но может быть неплохо следующее:

from setuptools import setup
from pipenv import find_install_requires

setup(
    # ...
    install_requires=find_install_requires()
    # ...
)

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

Pipfile , реализация, поддерживающая синтаксический анализ Pipfile Pipenv, может помочь в этом:

import pipfile
pf = pipfile.load('LOCATION_OF_PIPFILE')
print(pf.data['default'])

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

Золотым решением было бы написать инструмент, похожий на bumpversion , который автоматически синхронизирует текстовый файл на основе Pipfile. Распространите этот файл вместе со своим пакетом и прочитайте его в setup.py. Затем используйте CI или обработчик коммитов, чтобы убедиться, что файлы всегда синхронизированы.

Да, хорошо, игнорируй меня.
Возможно, «pipenv install» может выполнить синхронизацию?

В понедельник, 8 января 2018 г., в 17:04, Цзы-пинг Чанг, [email protected]
написал:

Pipfile https://github.com/pypa/pipfile , реализация, поддерживающая
разбор, может помочь с этим:

импортировать pip-файл
pf = pipfile.load('LOCATION_OF_PIPFILE')
печать (pf.data ['по умолчанию'])

Но я бы не рекомендовал это или зависеть от Pipenv в setup.py.
Импорт pipenv (или pipfile) означает, что пользователю необходимо фактически установить
что перед попыткой установки вашего пакета и такими инструментами, как Pipenv, пытающимися
заглянуть в него без установки (setup.py egg_info) не получится. То
setup.py должен зависеть только от Setuptools.

Золотым решением было бы написать инструмент, похожий на bumpversion.
https://github.com/peritus/bumpversion , который автоматически синхронизирует текст
файл на основе Pipfile. Распространите этот файл вместе с вашим пакетом и прочитайте его.
в setup.py. Затем используйте CI или обработчик коммитов, чтобы убедиться, что файлы всегда
в синхронизации.

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

@uranusjr просто проверяет мои предположения здесь, но нельзя ли добавить pipenv в setup_requires setup.py и отложить импорт pipenv в команду setuptools? Или это считается плохой практикой?

@Korijn Это может быть не само по себе, но, учитывая, что в настоящее время рекомендуется использовать отдельные виртуальные среды для каждого проекта Python, для этого пользователю потребуется установить копию Pipenv для каждого проекта, что не очень интуитивно понятно. Pipenv должен быть установлен только один раз (обычно глобально) и используется вне virtualenv проекта для управления им, а не внутри virtualenv проекта.

Так какое решение привело к закрытию вопроса? Нет ли способа отслеживать зависимости как в Pipfile , так и в setup.py ? Есть ли наилучшая практика, позволяющая обойти эту проблему?

Для приложений, которые развертываются или распространяются в установщиках, я просто использую Pipfile.

Для приложений, которые распространяются в виде пакетов с setup.py, я помещаю все свои зависимости в install_requires.

Затем я заставляю свой Pipfile зависеть от setup.py, запустив pipenv install '-e .' .

[Обновление 2019-08-23] В настоящее время я храню пакеты разработки в Pipfile, только зависимости времени выполнения сохраняются в setup.py.

Я думаю, что подход @Korijn - лучшая практика здесь. Pipfile (и requirements.txt) предназначен для приложений; setup.py для пакетов. Они служат разным целям. Если вам нужно синхронизировать их, вы делаете это неправильно (IMO).

@uranusjr Не согласно документации.

Pipenv — это инструмент, цель которого — привнести лучшее из мира пакетов (bundler, composer, npm, Cargo, yarn и т. д.) в мир Python. Windows — первоклассный гражданин в нашем мире.

Он автоматически создает и управляет virtualenv для ваших проектов, а также добавляет/удаляет пакеты из вашего Pipfile при установке/удалении пакетов. Он также генерирует очень важный Pipfile.lock, который используется для создания детерминированных сборок.

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

Насколько я понял, pipenv — это полная система управления зависимостями, похожая на композитор для PHP, но я начинаю понимать, что это не так. Тем более, что pipenv не будет устанавливать зависимости зависимости, у которой есть Pipfile и Pipfile.lock, но нет install_requirements в setup.py.

@vascowhite вопрос, который вы задаете, касается не pipenv, а фундаментального разделения между инструментами упаковки Python. В рабочем процессе Python файлы setup.py используются для объявления зависимостей установки распространяемого пакета. Итак, если у меня есть такой пакет, как requests , и это зависит от людей, у которых установлен пакет cffi , я бы объявил это в моем пакете setup.py , чтобы когда люди запускали пакет pip install requests он также выполнит эту установку, если это необходимо.

Пип-файлы, как и файлы требований, не предназначены для рекурсивного обхода. Вместо этого существует один pip-файл, который управляет всеми зависимостями для проекта, который вы, возможно, разрабатываете. Суть в том, что старый рабочий процесс генерировал сглаженный список закрепленных требований, в то время как Pipfiles содержат требования верхнего уровня и предпочитают не закрепленные, где это возможно. Когда вы устанавливаете пакет, требования из его setup.py рекурсивно разрешаются до наилучшего соответствия, которое также соответствует вашим другим требованиям.

Итак, если вы хотите знать, почему Pipfiles не разрешаются рекурсивно, это потому, что они просто не используются в python. Для запуска pipenv install конечном итоге требуется цель, которую может установить setuptools , что означает, что требования к ее установке будут определены в ее установочном файле.

@techalchemy Я был на полпути к похожему ответу, прежде чем появился ваш 😂 (удалить все)

Я также хотел бы отметить, что @vascowhite то, о чем вы спрашиваете, на самом деле не является диковинным. При наличии Pipfile и файла блокировки можно согласовать два разных рабочих процесса. В идеальном мире Pipfile заменяет файл setup.py install_requires и используется для указания виртуальных зависимостей, в то время как файл блокировки используется для создания на его основе конкретного набора зависимостей, заменяя файл requirements.txt.

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

Однако надежда не потеряна (по крайней мере, не моя). Было предложено и реализовано много PEP для решения этой проблемы, и я чувствую, что дела идут в правильном направлении, когда setup.py и requirements.txt движутся к жесткому, декларативному формату. С такой большой экосистемой все должно двигаться медленно (или посмотрите Python 3.0), но действительно движется.

@techalchemy @uranusjr
Спасибо вам обоим за ваши четкие ответы, они кое-что проясняют в моей голове. Мне кажется, что в документации слишком много информации о том, на что способен Pipenv, и это отчасти является причиной моего замешательства. Хотя большая часть моей путаницы зависит от меня :)

Придя из PHP, я был сбит с толку упаковкой в ​​python, Composer по сравнению с ним проще простого. Я считаю, что Python намного проще в разработке, и мне нравится его использовать. Будем надеяться, что ситуация улучшится, я уверен, что она будет достигнута благодаря усилиям таких людей, как вы и Кеннет Рейц.

Если вы будете следовать моему совету, упомянутому выше, вы сможете идеально согласовать и setup.py, и pipenv. Не нужно все заморачиваться. :)

похоже не я один запутался #1398

Сделано намного лучше, чем я мог бы, хотя :)

Пришел сюда за информацией об использовании pipenv с setup.py ; добавление моих 0,2 цента к обсуждению.

У меня есть пакет python, который выглядит как setup.py :

 setup(                                                                                                     
    name='my-pkg-name',                                                                             
    packages=find_packages(),                                                                              
    install_requires=[...],
    extras_require={
        'develop': ['click']
    },
    entry_points={
        'console_scripts': [
            'my-pkg-name-cmdline = my-pkg-name.cli:tool'
        ]
    }

Как видите, я использую click в точке входа скрипта для таких задач, как сборка и развертывание.

Когда я запускаю $ my-pkg-name-cmdline build , я не нахожу click установленным, потому что pipenv install --dev устанавливает пакеты в файле pipenv virtualenv. Мне нужно возиться с pipenv shell/exit , чтобы заставить его работать. Похоже, в этом все еще есть некоторые шероховатости.

Поэтому +1 за неиспользование pipenv для пакетов.

Я думаю, что в этом сценарии вы должны позвонить pipenv run my-pkg-name-cmdline build .

@Korijn Я все еще не уверен в правильности рабочего процесса (все еще немного экспериментирую с pipenv).

На данный момент рабочий процесс, который, кажется, работает для меня, таков:

(starting from scratch)
1- pipenv --three
2- pipenv install [--dev]
3- pipenv install -e . (install application locally)
4- pipenv shell (to enter the virtualenv)

Теперь я могу запустить скрипт сборки пакета click из командной строки.

если я вхожу в virtualenv (шаг 4) перед установкой приложения локально (шаг 3), то не работает.

Возможно, мне просто нужно перепрограммировать свой мозг, чтобы помнить, что пакеты должны быть установлены до pipenv shell (в то время как использование virtualenv требует установки пакетов с активированным virtualenv).

@apiraino Я думаю, что ты не понимаешь здесь. Если вы хотите использовать (импортировать) click в своем пакете, вы должны вместо этого поместить его в install_requires , чтобы люди (включая вас), устанавливающие ваш пакет, также могли установить click. Помещение его в extras_require['dev'] означает, что это необязательная зависимость, т. е. ваш пакет может работать без нее, но установка этих дополнений может предоставить определенные дополнительные функции.

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

@Korijn pipenv install '-e .' дает Pipfile , не отражающий модули, перечисленные в install_requires в setup.py

Это все еще относится к pipenv 9.0.3.

Как я могу сгенерировать Pipfile из моих setup.py install_requires?

не используйте кавычки

Я перестал использовать кавычки. Однако я не получаю созданный Pipfile , который включает в себя раздел deps from install_requires setup.py .

@benjaminweb Сегодня меня смутило то же самое. Однако я начинаю думать, что текущее поведение может исправиться.

@techalchemy упоминал выше, что

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

Если вы используете рабочий процесс, упомянутый в https://github.com/pypa/pipenv/issues/1263#issuecomment -362600555, когда вы запускаете pipenv install '-e .' в проекте без существующего Pipfile, pipenv создает новый Pipfile с следующее:

[packages]

"e1839a8" = {path = ".", editable = true}

В этом случае единственным пакетом, который вы явно запросили для установки в virtualenv, является сам пакет (то есть «.»), поэтому имеет смысл, что только «.» добавляется к ( [packages] ) в Pipfile. Точно так же, если вы pipenv install requests , ни одна из зависимостей install_requires из запроса setup.py также не будет добавлена ​​в Pipfile вашего проекта.

Однако на следующем этапе установки пакета зависимости install_requires будут установлены как часть разрешения зависимостей для пакета .

Обратите внимание, что в отличие от Pipfile, Pipfile.lock записывает все точные зависимости для всего виртуального окружения, которое должно включать зависимости install_requires , заблокированные для определенных версий. Если вы посмотрите на сгенерированный Pipfile.lock, вы увидите перечисленные зависимости install_requires .

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

Ваш ход мыслей совпадает с моим. Я также упомяну, что с недавним усовершенствованием Setuptools и такими инструментами, как Flit , вы по-прежнему можете указывать зависимости вашего пакета в удобной форме TOML (вместо строк требований в setup.py, что, по общему признанию, не очень красиво). Вы просто указываете их в pyproject.toml вместо Pipfile.

@uranusjr похоже, что вы говорите, что Pipfile нужно только явно перечислить зависимости проекта, если они еще не перехвачены инструментом упаковки, таким как Setuptools или Flit (через setup.py или pyproject.toml)

Например, если setup.py выглядит так:

install_requires=['A'],
extras_require={
    'dev': ['B'],
},

Тогда Pipfile нужно только следующее:

[[source]]

url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"


[packages]

"e1839a8" = {path = ".", editable = true}


[dev-packages]

"e1839a8" = {path = ".", extras = ["dev"], editable = true}

Запуск pipenv install установит зависимость A для производства, а pipenv install --dev установит зависимости A и B для разработки.

Если кто-то уже использует Setuptools или Flit, есть ли какая-либо причина, по которой зависимости должны быть добавлены в Pipfile под [packages] или [dev-packages] ? Глядя на Запросы в качестве примера, для меня не очевидно, почему зависимости разработки явно перечислены в Pipfile под [dev-packages] , но все зависимости install_requires и test_requirements фиксируются в настройке. .py.

Похоже, единственная причина, по которой вам нужно явно добавлять зависимости в Pipfile, заключается в том, что вы не используете Setuptools или Flit. Это правильно? Есть ли причины, почему это не так?

Думаю, это просто личные предпочтения. Перечисление зависимостей разработчика в extras_require[dev] — это просто соглашение; dev-packages OTHO — это четко определенный ключ. extras_require[dev] также позволит любому пользователю pip install package[dev] , что может не понравиться сопровождающим. Я могу понять людей, предпочитающих одно другому.

Что касается packages , нет, на самом деле нет сценария, который имел бы больше смысла, чем install_requires IMO. Я уверен, что люди придумают творческие способы использования.

Почему этот вопрос закрыт?

@JulienPalard закрыт по нескольким причинам:

1. Пип-файлы и файлы setup.py на самом деле не предназначены для синхронизации, как таковые, я думаю, что есть куча статей, связанных с обсуждением деталей, но tl; dr Pipfile примерно эквивалентен верхний уровень requirements.txt
2. Если вы хотите, чтобы ваш проект (скажем, текущий каталог) разрешил свои setup.py в управляемую виртуальную среду, рабочий процесс будет просто pipenv install -e . — это помещает одну запись в ваш Pipfile (корень верхнего уровня) и разрешенный граф зависимостей в ваш Pipfile.lock , включая разрешенный install_requires . Если вы хотите обновить virtualenv последним содержимым из-за измененного install_requires , вам нужно будет запустить pipenv update , который совпадает с pipenv lock && pipenv sync в последней версии.

Надеюсь, это полезно!

На самом деле они более похожи, чем Pipfile похожи на requirements.txt : requirements.txt указывает все пакеты в простой форме, а Pipfile и setup.py требует только зависимостей начального уровня. Pipfile.lock и requirements.txt содержат аналогичную информацию.

Я создал сценарий синхронизации POC, который можно реализовать в дальнейшем, но в настоящее время он охватывает наш вариант использования:
https://gist.github.com/iddan/f190c3c7d54f4fc4655da95fb185e641

@iddan , по сути, это то, о чем я говорил, каждая из этих вещей представляет собой список ваших зависимостей верхнего уровня, но одна предназначена для _установки приложения_ ( setup.py ), а другая предназначена для _разработки его_ ( Pipfile ).

В первом случае использования setup.py у вас есть те же возможности для объявления открытых или полностью закрепленных зависимостей, что и в случае с requirements.txt , но большинство людей используют здесь открытое закрепление зависимостей. В Pipfile вы также можете указать строгие или свободные контакты, но также рекомендуется сохранить это как _unflattened_ список вашего графа зависимостей. Опять же, я хочу подчеркнуть, что обе эти вещи также полностью действительны в файлах requirements.txt , поэтому я постоянно подчеркиваю разделение обязанностей между приложениями и библиотеками. Вы услышите это в каждом выступлении, в каждом уроке и во всех сообщениях, рассылаемых PyPA.

Pipfile.lock и requirements.txt — это не одно и то же. Вы можете сгенерировать действительный requirements.txt из Pipfile.lock , но вы не можете напрямую сгенерировать файл блокировки из файла требований без использования посредника Pipfile . Это связано с тем, что Pipfile.lock представляет собой транзитивное замыкание и всегда требует посредника Pipfile для выполнения разрешения зависимостей.

Что касается первоначального вопроса, нет причин синхронизировать файл setup.py с файлом Pipfile , кроме как путем простого включения рассматриваемого каталога в качестве редактируемого пути. При запуске pipenv lock зависимости в файле setup.py будут автоматически разрешены. Я не уверен в вашем конкретном случае использования @iddan или в том, почему вам нужен специальный парсер для записи данных обратно в установочный файл, но я подозреваю, что вы можете прочитать статью Дональда Стаффта о setup.py и требованиях. txt или сослаться на этот комментарий одного из наших сопровождающих о различии и о том, как оно относится конкретно к Pipenv.

Мой вариант использования заключается в том, что в K Health у нас есть репозитории с нашими внутренними пакетами, которые являются автономными услугами, а также могут использоваться как пакеты. Поэтому мы хотели бы поделиться нашими зависимостями верхнего уровня между потребителями пакетов и конфигурацией разработки/развертывания службы. Поскольку мы используем Pipenv для управления нашими зависимостями, было бы неплохо получить вывод Pipfile как setup.py

Звучит как вариант #2148 (замена требований.txt на Pipfile).

Но это касается setup.py

Этот. Проблема. Должен. Нет. Быть. Закрыто.

Этот вопрос закрыт, потому что

1. Pipenv не является инструментом упаковки .
2. Было принято решение не включать функции упаковки в Pipenv.
3. Было разъяснено, как вы можете использовать Pipenv для управления зависимостями разработки во время разработки пакета.
4. Pipfile — это открытый стандарт. На основе формата Pipfile легко создать инструмент для упаковки. Тот факт, что Pipenv решил не делать этого, не означает, что вы не должны этого делать.

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

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

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

Делай одно дело и делай это хорошо!

Всем привет,

@Korijn Я прочитал ту часть, где вы объясняли, как использовать extra_requires для синхронизации setup.py с Pipfile.

Я пытался это сделать и заметил, что Pipfile.lock не имеет пакетов extra_require в разделе dev, поэтому, когда у вас есть исходный код в пустом venv и вы делаете pipenv install --dev , поскольку Pipfile.lock не имеет требований extra_require pipenv только устанавливает пакеты на install_require .

setup.py

import os  # noqa: D100
from setuptools import setup, find_packages


def read(fname):
    """Read a file and return its content."""
    with open(os.path.join(os.path.dirname(__file__), fname)) as f:
        return f.read()


setup(
    name='auditor_client',
    version='0.0.0',
    description='Auditor client package',
    long_description=read('README.md'),
    packages=find_packages(exclude=['tests']),
    install_requires=['requests==2.9.1'],
    extras_require={'dev': ['flake8', 'flake8-docstrings', 'pytest', 'coverage', 'tox']},
    setup_requires=["pytest-runner"],
    tests_require=["pytest"]
)

Пипфайл

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

[packages]
"e1839a8" = {editable = true, path = "."}

[requires]
python_version = "3.6"

[dev-packages]
"e1839a8" = {editable = true, extras = ["dev"], path = "."}

Pipfile.lock

{
    "_meta": {
        "hash": {
            "sha256": "e58b833e497814c83a2f0b93ad21d33a2af8b72721b20e9607a6c9135978422d"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.6"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "e1839a8": {
            "editable": true,
            "path": "."
        },
        "requests": {
            "hashes": [
                "sha256:113fbba5531a9e34945b7d36b33a084e8ba5d0664b703c81a7c572d91919a5b8",
                "sha256:c577815dd00f1394203fc44eb979724b098f88264a9ef898ee45b8e5e9cf587f"
            ],
            "version": "==2.9.1"
        }
    },
    "develop": {
        "e1839a8": {
            "editable": true,
            "path": "."
        },
        "requests": {
            "hashes": [
                "sha256:113fbba5531a9e34945b7d36b33a084e8ba5d0664b703c81a7c572d91919a5b8",
                "sha256:c577815dd00f1394203fc44eb979724b098f88264a9ef898ee45b8e5e9cf587f"
            ],
            "version": "==2.9.1"
        }
    }
}

не должно быть правильным поведением, которое Pipfile.lock отслеживает пакеты разработчика extra_require?

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

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

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

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

@techalchemy , так как я могу управлять своими зависимостями разработчиков в этом случае? Я только хочу знать, как правильно использовать pipenv

Я думал об этом для своего собственного проекта и понял, что мне действительно не нужно различие packages / dev-packages . Как насчет перечисления {editable = true, extras = ["dev"], path = "."} в packages .

проверьте этот пакет pipenv-setup

Он синхронизирует pipfile/lockfile с setup.py.

$ pipenv-setup sync

package e1839a8 is local, omitted in setup.py
setup.py successfully updated
23 packages from Pipfile.lock synced to setup.py

вы можете сделать $ pipenv-setup sync --dev для синхронизации зависимостей разработки с дополнительными требованиями. или $ pipenv-setup sync --pipfile для синхронизации pipfile вместо этого

и $ pipenv-setup check только для проверки

одна команда, чтобы решить их все 💯

Есть ли план объединить пакет pipenv-setup с pipenv?

@peterdeme

Есть ли план объединить пакет pipenv-setup с pipenv?

@uranusjr @techalchemy, основываясь на приведенном выше обсуждении, я думаю, что у pipenv может быть несколько иная философия. Но если сопровождающие согласятся, я бы очень хотел отправить запрос на включение и попытаться интегрировать pipenv-setup

Вы всегда можете разобрать Pipfile.lock с помощью встроенного модуля json . Извлеките зависимости non-dev для вашего setup.py install_requires .
Ключ "default" содержит вложенные «слова» имени пакета, а также числа version и markers .
Вам не нужно полагаться на какой-либо внешний импорт.

@ Kilo59 Я видел, как люди это делают. Совет: не забудьте включить Pipfile.lock как data_file в setup.py (или включить его в MANIFEST.in). И это для файла блокировки с закрепленными зависимостями. pipfile, с другой стороны, нетривиально анализировать, если вы хотите семантическое управление версиями в Pipfile. Одно и то же требование зависимости может отображаться в нескольких формах.

Спасибо, @Madoshakalaka , ваш инструмент отлично работает!

Я согласен с другими коллегами в том, что зависимости Setup.py отличаются от зависимостей проекта Pipfile. Но тем не менее, наличие программируемого способа синхронизации без ручного труда — отличная функция для экономии времени. Кроме того, позволяет избежать опечаток / распространенных ошибок.

Почерневший setup.py тоже был приятным штрихом :+1: