Pipenv: Como manter setup.py install_requires e Pipfile em sincronia

O pipenv tem uma API python que pode ser usada? Eu atualizo manualmente a lista enquanto trabalho em um projeto, mas o seguinte pode ser bom:

from setuptools import setup
from pipenv import find_install_requires

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

a função só precisa retornar uma lista das chaves na seção pipfiles [packages]. Imagino que você possa obter essa funcionalidade já usando uma função auxiliar, mas seria bom se fosse parte do pipenv, para que não precisemos implementá-la.

Pipfile , a implementação que suporta a análise Pipfile do Pipenv, pode ajudar com isso:

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

Mas eu não recomendaria isso, ou dependendo do Pipenv em setup.py. Importar pipenv (ou pipfile ) significa que o usuário precisa realmente instalá-lo antes de tentar instalar seu pacote, e ferramentas como Pipenv tentando espiar sem instalar ( setup.py egg_info ) ganharam não funciona. O setup.py deve depender apenas de Setuptools.

Uma solução intermediária seria escrever uma ferramenta semelhante ao bumpversion que sincroniza automaticamente um arquivo de texto baseado no Pipfile. Distribua este arquivo com seu pacote e leia-o em setup.py. Em seguida, use CI ou um gancho de confirmação para garantir que os arquivos estejam sempre sincronizados.

Sim bom ponto me ignore.
Talvez “pipenv install” possa fazer a sincronização?

Em segunda-feira, 8 de janeiro de 2018 às 17h04, Tzu-ping Chung [email protected]
escreveu:

Pipfile https://github.com/pypa/pipfile , a implementação que suporta o
parsing, pode ajudar com isso:

importar arquivo pip
pf = pipfile.load('LOCATION_OF_PIPFILE')
print(pf.data['default'])

Mas eu não recomendaria isso, ou dependendo do Pipenv em setup.py.
Importar pipenv (ou pipfile) significa que o usuário precisa realmente instalar
que antes de tentar instalar seu pacote, e ferramentas como Pipenv tentando
espiar nele sem instalar (setup.py egg_info) não funcionará. O
setup.py deve depender apenas de Setuptools.

Uma solução intermediária seria escrever uma ferramenta semelhante ao bumpversion
https://github.com/peritus/bumpversion que sincroniza automaticamente um texto
arquivo baseado em Pipfile. Distribua este arquivo com seu pacote e leia-o
em setup.py. Em seguida, use CI ou um gancho de confirmação para garantir que os arquivos estejam sempre
em sincronia.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/pypa/pipenv/issues/1263#issuecomment-355889369 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ALMBlmmV52kdIL9D4zlMJoQh2JpaGdDbks5tIa_jgaJpZM4RRu3v
.

@uranusjr apenas testando minhas suposições aqui, mas não seria possível adicionar pipenv ao setup_requires do setup.py e atrasar a importação do pipenv para um comando setuptools? Ou isso é considerado má prática?

@Korijn Pode não ser por si só, mas dada a prática recomendada atual é usar virtualenvs separados para cada projeto Python, isso exigiria que o usuário instalasse uma cópia do Pipenv para cada projeto, o que não é muito intuitivo. O Pipenv deve ser instalado apenas uma vez (geralmente globalmente) e é usado fora do virtualenv do projeto para gerenciá-lo, não dentro do virtualenv do projeto.

Então, qual é a resolução para isso que levou ao encerramento da questão? Não há meios de acompanhar as dependências em Pipfile e em setup.py ? Existe uma prática recomendada que contorna o problema?

Para aplicativos que são implantados ou distribuídos em instaladores, apenas uso Pipfile.

Para aplicativos que são distribuídos como pacotes com setup.py, coloco todas as minhas dependências em install_requires.

Então eu faço meu Pipfile depender de setup.py executando pipenv install '-e .' .

[Atualização 2019-08-23] Eu mantenho os pacotes dev no Pipfile hoje em dia, apenas as dependências de tempo de execução ficam em setup.py.

Acho que a abordagem de @Korijn é a melhor prática aqui. Pipfile (e requirements.txt) é para aplicativos; setup.py é para pacotes. Eles servem a propósitos diferentes. Se você precisar sincronizá-los, você está fazendo errado (IMO).

@uranusjr Não de acordo com a documentação.

Pipenv é uma ferramenta que visa trazer o melhor de todos os mundos de empacotamento (bundler, composer, npm, cargo, yarn, etc.) O Windows é um cidadão de primeira classe em nosso mundo.

Ele cria e gerencia automaticamente um virtualenv para seus projetos, bem como adiciona/remove pacotes do seu Pipfile conforme você instala/desinstala pacotes. Ele também gera o sempre importante Pipfile.lock, que é usado para produzir compilações determinísticas.

Talvez eu não esteja entendendo. Poderia detalhar sua declaração, por favor?

A maneira como eu entendi é que pipenv é um sistema completo de gerenciamento de dependências semelhante ao composer para PHP, mas estou começando a perceber que não é. Especialmente porque pipenv não instalará as dependências de uma dependência que tenha um Pipfile e Pipfile.lock, mas nenhum install_requirements em setup.py.

@vascowhite a pergunta que você está fazendo não é sobre pipenv, mas sim sobre uma separação fundamental entre ferramentas de empacotamento python. No fluxo de trabalho python, os arquivos setup.py são usados ​​para declarar dependências de instalação de um pacote distribuível. Então, se eu tenho um pacote como requests , e depende de pessoas com cffi instalado, eu declararia isso no meu setup.py para que quando as pessoas executassem pip install requests ele também fará essa instalação, se necessário.

Pipfiles, como arquivos de requisitos, não devem ser percorridos recursivamente. Em vez disso, há um único pipfile que governa todas as dependências de um projeto que você possa estar desenvolvendo. O ponto disso é que o antigo fluxo de trabalho gerou uma lista achatada de requisitos fixados, enquanto os Pipfiles contêm requisitos de nível superior e preferem desafixados sempre que possível. Quando você instala um pacote, os requisitos de setup.py são resolvidos recursivamente para a melhor correspondência que também atenda aos seus outros requisitos.

Portanto, se você quiser saber por que os Pipfiles não são resolvidos recursivamente, é porque não é assim que eles são usados ​​em python. A execução pipenv install requer, em última análise, um destino instalável por setuptools , o que significa que terá seus requisitos de instalação definidos em seu arquivo de instalação.

@techalchemy Eu estava no meio de uma resposta semelhante antes da sua aparecer 😂 (apagar tudo)

Também gostaria de observar que @vascowhite o que você está perguntando não é de fato estranho. Com o Pipfile e o arquivo de bloqueio disponíveis, é possível reconciliar os dois fluxos de trabalho distintos. Em um mundo ideal, o Pipfile substitui o install_requires do setup.py e é usado para especificar dependências virtuais, enquanto o arquivo de bloqueio é usado para produzir um conjunto de dependências concreto baseado nele, substituindo o requirements.txt.

O sistema de empacotamento do Python, no entanto, está longe de ser o ideal no momento e exigiria muita limpeza antes que isso pudesse acontecer. Caramba, o Pipenv já está tendo dificuldades em lidar com dependências agora (ps não é culpa de ninguém), provavelmente mal funcionaria, a menos que para o mais simples dos projetos, se usado assim.

A esperança não está perdida (pelo menos não a minha). Tem havido muito PEP sendo proposto e implementado em torno deste problema, e eu sinto que as coisas estão no caminho certo com setup.py e requirements.txt ambos se movendo em direção a um formato rígido e declarativo. Com um ecossistema tão grande, as coisas precisam se mover lentamente (ou veja o Python 3.0), mas de fato estão se movendo.

@techalchemy @uranusjr
Obrigado a ambos por suas respostas claras, elas endireitam algumas coisas em minha mente. Parece-me que a documentação acabou afirmando o que o Pipenv é capaz de fazer e isso é em parte a causa da minha confusão. A maioria da minha confusão é para mim embora :)

Tendo vindo do PHP, fiquei confuso com o empacotamento em python, o Composer é uma brisa em comparação. Eu acho python muito mais fácil de desenvolver e adoro usá-lo. Vamos torcer para que as coisas melhorem, tenho certeza que eles vão dar os esforços de pessoas como vocês e Kenneth Reitz.

Se você seguir meu conselho mencionado acima, poderá harmonizar perfeitamente setup.py e pipenv. Não há necessidade de ficar todo exigente. :)

parece que não sou o único que está confuso #1398

Coloque muito melhor do que eu poderia embora :)

Vim aqui para obter informações sobre como usar pipenv com um setup.py ; adicionando meus 0,2 centavos à discussão.

Eu tenho um pacote python que setup.py se parece com:

 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'
        ]
    }

Como você pode ver, eu uso click no ponto de entrada do script para tarefas como construção e implantação.

Quando executo $ my-pkg-name-cmdline build não encontro click instalado, pois pipenv install --dev instala pacotes no pipenv virtualenv. Eu preciso mexer com pipenv shell/exit para fazê-lo funcionar. Parece que ainda há algumas arestas sobre isso.

Portanto, +1 por não usar pipenv para pacotes.

Eu acho que você deve pagar pipenv run my-pkg-name-cmdline build nesse cenário.

@Korijn Ainda não tenho certeza sobre o fluxo de trabalho correto (ainda estou experimentando um pouco com o pipenv).

Até o momento, o fluxo de trabalho que parece estar funcionando para mim é:

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

Agora posso executar meu script de compilação de pacote click a partir da linha de comando.

se eu entrar no virtualenv (etapa 4) antes de instalar o aplicativo localmente (etapa 3), não funciona.

Talvez eu tenha que reconectar meu cérebro para lembrar que os pacotes devem ser instalados antes pipenv shell (enquanto usar virtualenv requer que você instale pacotes com o virtualenv ativado).

@apiraino acho que você não está entendendo bem aqui. Se você quiser usar (importar) clique em seu pacote, você deve colocá-lo em install_requires , para que as pessoas (incluindo você) instalando seu pacote também possam ter o clique instalado. Colocá-lo em extras_require['dev'] significa que é uma dependência opcional, ou seja, seu pacote pode funcionar sem ele, mas instalar esses extras pode fornecer certos recursos extras.

Essa discussão realmente não tem mais nada a ver com o Pipenv. Sugiro que você traga esse problema para um fórum mais adequado, como StackOverflow ou listas de discussão relacionadas ao Python.

@Korijn pipenv install '-e .' produz um Pipfile que não reflete os módulos listados em install_requires em setup.py

Este ainda é o caso do pipenv 9.0.3.

Como posso gerar Pipfile partir do install_requires do meu setup.py ?

não use aspas

Parei de usar aspas. No entanto, não recebo um Pipfile criado que inclua as dependências da seção install_requires de setup.py .

@benjaminweb Fiquei confuso com a mesma coisa hoje. No entanto, estou começando a pensar que o comportamento atual pode corrigir.

@techalchemy mencionou acima que

Os Pipfiles contêm requisitos de nível superior e preferem desafixados sempre que possível. Quando você instala um pacote, os requisitos de seu setup.py são resolvidos recursivamente para a melhor correspondência que também atenda aos seus outros requisitos.

Se você usar o fluxo de trabalho mencionado em https://github.com/pypa/pipenv/issues/1263#issuecomment -362600555, ao executar pipenv install '-e .' em um projeto sem um Pipfile existente, o pipenv gerará um novo Pipfile com a seguir:

[packages]

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

Nesse caso, o único pacote que você solicitou explicitamente para ser instalado no virtualenv é o próprio pacote (ou seja, "."), então faz sentido que apenas "." é adicionado ao ( [packages] ) no Pipfile. Da mesma forma, se você pipenv install requests , nenhuma das dependências install_requires do arquivo setup.py das solicitações também será adicionada ao Pipfile do seu projeto.

No entanto, quando a etapa de instalação do pacote acontecer em seguida, as dependências install_requires serão instaladas como parte da resolução de dependência para o pacote .

Observe que, diferentemente do Pipfile, o Pipfile.lock registra todas as dependências exatas para todo o virtualenv, que deve incluir as dependências install_requires bloqueadas para versões específicas. Se você olhar para o Pipfile.lock gerado, você verá as dependências install_requires listadas.

É possível que eu esteja entendendo mal como isso deve funcionar. Talvez @techalchemy ou @uranusjr possam confirmar se esta é a maneira correta de pensar sobre isso?

Sua linha de pensamento combina com a minha. Também mencionarei que, com o recente avanço do Setuptools e ferramentas como o Flit, você ainda pode especificar as dependências do seu pacote em um bom formato TOML (em vez de strings de requisitos em setup.py, o que reconhecidamente não é muito bonito). Você acabou de especificá-los em pyproject.toml em vez de Pipfile.

@uranusjr parece que o que você está dizendo é que o Pipfile só precisa listar explicitamente as dependências do projeto se elas ainda não estiverem sendo capturadas por uma ferramenta de empacotamento como Setuptools ou Flit (via setup.py ou pyproject.toml)

Por exemplo, se setup.py se parece com:

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

Então o Pipfile só precisa do seguinte:

[[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}

A execução pipenv install instalaria a dependência A para produção e pipenv install --dev instalaria as dependências A e B para desenvolvimento.

Se alguém já estiver usando Setuptools ou Flit, existe alguma razão pela qual as dependências devem ser adicionadas ao Pipfile em [packages] ou [dev-packages] ? Olhando para Requests como um exemplo, não é óbvio para mim por que as dependências de desenvolvimento estão listadas explicitamente no Pipfile em [dev-packages] , mas as dependências install_requires e test_requirements são todas capturadas na configuração .py.

Parece que a única razão pela qual você precisaria adicionar dependências explicitamente ao Pipfile é se você não estiver usando Setuptools ou Flit. Isso está correto? Existem razões pelas quais isso não é verdade?

Acho que é apenas preferência pessoal. Listar dependências dev em extras_require[dev] é meramente uma convenção; dev-packages OTHO é uma chave bem definida. extras_require[dev] também permitiria a qualquer usuário pip install package[dev] , o que os mantenedores podem não gostar. Eu posso entender as pessoas preferindo um do outro.

Quanto a packages , não, realmente não há um cenário que faça mais sentido do que install_requires IMO. Tenho certeza de que as pessoas vão inventar usos criativos.

Por que esta questão está encerrada?

@JulienPalard está fechado por alguns motivos:

1. Os arquivos Pipfiles e setup.py não são realmente feitos para serem mantidos em sincronia, por si só, acho que houve vários artigos vinculados discutindo os detalhes, mas tl; dr Pipfile é aproximadamente equivalente a um nível superior requirements.txt
2. Se você quiser que seu projeto (digamos que seja o diretório atual) tenha seu setup.py resolvido no virtualenv gerenciado, o fluxo de trabalho seria apenas pipenv install -e . -- isso coloca uma única entrada em seu Pipfile (a raiz de nível superior) e o gráfico de dependência resolvido em seu Pipfile.lock incluindo o install_requires resolvido. Se você deseja atualizar o virtualenv com o conteúdo mais recente devido a uma alteração install_requires , você precisa executar pipenv update que é o mesmo que pipenv lock && pipenv sync na versão mais recente.

Espero que isso seja útil!

Na verdade, eles são mais semelhantes que Pipfile é semelhante a requirements.txt : requirements.txt especifica todos os pacotes de maneira plana enquanto Pipfile & setup.py requer apenas as dependências de nível de entrada. Pipfile.lock e requirements.txt contêm informações semelhantes.

Eu criei um script de sincronização POC que pode ser implementado, mas atualmente cobre nosso caso de uso:
https://gist.github.com/iddan/f190c3c7d54f4fc4655da95fb185e641

@iddan é essencialmente o que eu tenho dito, cada uma dessas coisas representa uma listagem de nível superior de suas dependências, mas uma é destinada a _instalar um aplicativo_ ( setup.py ) e a outra é destinada a _desenvolvê-la_ ( Pipfile ).

No caso anterior de usar setup.py , você tem as mesmas opções para declarar dependências abertas ou totalmente fixadas como faria com requirements.txt , mas a maioria das pessoas usa a fixação de dependência aberta aqui. Em um Pipfile você também pode especificar pinos estritos ou soltos, mas da mesma forma é encorajado manter isso como uma listagem _unflattened_ do seu gráfico de dependência. Mais uma vez, quero enfatizar que essas duas coisas também são completamente válidas em arquivos requirements.txt , e é por isso que estou enfatizando continuamente a separação de responsabilidades entre aplicativos e bibliotecas. Você ouvirá isso enfatizado em todas as palestras e tutoriais e em todas as mensagens divulgadas pelo PyPA.

Pipfile.lock e requirements.txt não são a mesma coisa. Você pode gerar um requirements.txt válido a partir de um Pipfile.lock , mas não pode gerar diretamente um arquivo de bloqueio de um arquivo de requisitos sem usar um intermediário Pipfile . Isso porque um Pipfile.lock representa um fechamento transitivo e sempre exigirá um intermediário Pipfile para realizar a resolução de dependência.

Quanto à pergunta original, não há motivo para manter um arquivo setup.py em sincronia com um Pipfile além de simplesmente incluir o diretório em questão como um caminho editável. Quando você executa pipenv lock , as dependências no arquivo setup.py serão resolvidas automaticamente. Não tenho certeza sobre seu caso de uso específico, @iddan , ou por que você precisa ter um analisador especial para escrever coisas de volta no arquivo de instalação, mas suspeito que você queira ler o artigo de Donald Stufft sobre setup.py vs requirements. txt ou para fazer referência a este comentário de um de nossos mantenedores sobre a distinção e como ela se aplica especificamente ao Pipenv.

Meu caso de uso é que na K Health temos um repositório com nossos pacotes internos que são serviços autônomos e também podem ser consumidos como pacotes. Portanto, gostaríamos de compartilhar nossas dependências de nível superior entre os consumidores do pacote e a configuração dev/deployment do serviço. Como estamos usando o Pipenv para gerenciar nossas dependências, será bom obter uma saída do Pipfile como setup.py

Parece uma variante de #2148 (substituindo requirements.txt por Pipfile).

Mas isso é sobre setup.py

Isto. Emitir. Deve. Não. Ser. Fechado.

Este problema está encerrado porque

1. Pipenv não é uma ferramenta de empacotamento .
2. Foi tomada a decisão de não incluir funcionalidades de empacotamento no Pipenv.
3. Foi esclarecido como você pode usar o Pipenv para gerenciar dependências de desenvolvimento durante o desenvolvimento de um pacote.
4. Pipfile é um padrão aberto. É fácil construir uma ferramenta de empacotamento baseada no formato Pipfile. O fato de a Pipenv decidir não fazê-lo não significa excluir você de fazê-lo.

Se você realmente se importa tanto assim, por favor, faça você mesmo uma ferramenta. Com tanta expectativa nesta questão, acredito que não seria difícil ganhar força se você postar sua solução aqui. E com tração, o PyPA pode recomendá-lo no guia de embalagens, assim como o Pipenv. Mas primeiro você precisa realmente construir a ferramenta.

Além disso, aprenda a abordar os mantenedores do projeto com respeito. Consulte o código de conduta para referência. Estamos felizes em ter discussões produtivas, mas somos voluntários e não estamos aqui para simplesmente obedecer a desejos individuais. Se você não pode gerenciar isso, não se preocupe em postar.

Eu recomendaria bloquear este problema para evitar mais discussões. Acho que o ponto ficou claro.

Faça uma coisa e faça bem!

Olá a todos,

@Korijn eu li aquela parte onde você estava explicando como você usa extra_requires para sincronizar setup.py com Pipfile.

Eu estava tentando fazer isso e notei que Pipfile.lock não tem os pacotes extra_require na seção dev, então quando você tem o código fonte em um venv vazio e faz pipenv install --dev , pois Pipfile.lock não tem requisitos extra_require pipenv apenas instala os pacotes em 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"]
)

Pipfile

[[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"
        }
    }
}

não deve ser o comportamento correto que Pipfile.lock rastreou pacotes dev extra_require?

Sim, isso parece um bug/limitação para mim. Você deve registrar um bug/problema separado para isso.

Acho que há um problema aberto no rastreador sobre esse problema, embora não possa localizá-lo no momento. Por favor, pesquise os problemas existentes antes de abrir um. Desde já, obrigado :)

Isso não é um bug, você não pode usar a mesma entrada base várias vezes em um pipfile. Se você especificar uma dependência na seção dev e também na seção padrão, a seção padrão terá precedência, não importa o quê.

Eu faria meu experimento de pensamento normal, mas não tenho tempo agora, então acredite em minha palavra de que isso pode causar conflitos de dependência e surpresas quando você implanta algo e descobre que sua dependência de desenvolvimento estava escondendo um conflito.

@techalchemy então como posso gerenciar minhas dependências de desenvolvimento neste caso? Eu só quero saber como usar o pipenv de uma maneira boa

Eu estive pensando sobre isso para o meu próprio projeto, e meio que percebi que eu realmente não preciso da distinção packages / dev-packages . Que tal listar {editable = true, extras = ["dev"], path = "."} em packages .

confira este pacote de configuração do pipenv

Ele sincroniza pipfile/lockfile para 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

você pode fazer $ pipenv-setup sync --dev para sincronizar dependências de desenvolvimento com requisitos extras. ou $ pipenv-setup sync --pipfile para sincronizar o arquivo pip

e $ pipenv-setup check apenas para fazer cheques

um comando para resolvê-los todos 💯

Existe algum plano para mesclar o pacote pipenv-setup ao pipenv?

@peterdeme

Existe algum plano para mesclar o pacote pipenv-setup ao pipenv?

@uranusjr @techalchemy com base na discussão acima, acho que o pipenv pode ter uma filosofia um pouco diferente. Mas se os mantenedores concordarem, eu gostaria muito de enviar um pull request e tentar integrar pipenv-setup

Você sempre pode analisar o Pipfile.lock com o módulo json embutido. Extraia as dependências non-dev para seu setup.py install_requires .
A chave "default" contém "dicts" aninhados do nome do pacote junto com version números e markers .
Você não precisa depender de nenhuma importação externa.

@ Kilo59 Eu vi pessoas fazendo isso. Uma dica a mencionar é não esquecer de incluir Pipfile.lock como data_file em setup.py (ou incluí-lo em MANIFEST.in). E isso é para lockfile com dependências fixadas. pipfile, por outro lado, não é trivial para analisar, se você quiser versionamento semântico no Pipfile. O mesmo requisito de dependência pode ser exibido em vários formulários.

Obrigado @Madoshakalaka sua ferramenta funciona bem!

Concordo com outros colegas que as dependências do Setup.py são diferentes das dependências do projeto do Pipfile. Mas ainda assim, ter uma maneira programável de sincronizar aqueles sem trabalho manual é um ótimo recurso para economizar tempo. Além disso, evita erros de digitação/erros comuns.

O setup.py escurecido também foi um toque agradável :+1: