Pipenv: Cómo mantener sincronizados setup.py install_requires y Pipfile

¿Pipenv tiene una API de python que podría usarse? Actualizo manualmente la lista mientras trabajo en un proyecto, pero lo siguiente podría ser bueno:

from setuptools import setup
from pipenv import find_install_requires

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

la función solo necesita devolver una lista de las claves en la sección pipfiles [paquetes]. Me imagino que podría lograr esta funcionalidad usando una función de ayuda, pero sería bueno si fuera parte de pipenv para que no todos tengamos que implementarla.

Pipfile , la implementación que respalda el análisis de Pipfile de Pipenv, puede ayudar con esto:

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

Pero no recomendaría esto, o dependiendo de Pipenv en setup.py. Importar pipenv (o pipfile ) significa que el usuario necesita instalar eso antes de intentar instalar su paquete, y herramientas como Pipenv que intentan echar un vistazo sin instalarlo ( setup.py egg_info ) ganaron no funciona setup.py solo debe depender de Setuptools.

Una solución intermedia sería escribir una herramienta similar a bumpversion que sincronice automáticamente un archivo de texto basado en Pipfile. Distribuya este archivo con su paquete y léalo en setup.py. Luego use CI o un gancho de confirmación para asegurarse de que los archivos estén siempre sincronizados.

Sí, buen punto, ignórame.
¿Quizás "pipenv install" podría hacer la sincronización?

El lunes 8 de enero de 2018 a las 17:04, Tzu-ping Chung [email protected]
escribió:

Pipfile https://github.com/pypa/pipfile , la implementación que respalda el
análisis, puede ayudar con esto:

importar archivo pip
pf = pipfile.load('LOCATION_OF_PIPFILE')
imprimir(pf.datos['predeterminado'])

Pero no recomendaría esto, o dependiendo de Pipenv en setup.py.
Importar pipenv (o pipfile) significa que el usuario necesita instalar
eso antes de intentar instalar su paquete, y herramientas como Pipenv tratando de
mirarlo sin instalar (setup.py egg_info) no funcionará. El
setup.py solo debe depender de Setuptools.

Una solución intermedia sería escribir una herramienta similar a bumpversion
https://github.com/peritus/bumpversion que sincroniza automáticamente un texto
archivo basado en Pipfile. Distribuya este archivo con su paquete y léalo.
en configuración.py. Luego use CI o un gancho de confirmación para asegurarse de que los archivos estén siempre
en sintonía.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/pypa/pipenv/issues/1263#issuecomment-355889369 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ALMBlmmV52kdIL9D4zlMJoQh2JpaGdDbks5tIa_jgaJpZM4RRu3v
.

@uranusjr solo probando mis suposiciones aquí, pero ¿no sería posible agregar pipenv a setup_requires de setup.py y retrasar la importación de pipenv a un comando de herramientas de configuración? ¿O eso se considera una mala práctica?

@Korijn Puede que no sea per se, pero dada la mejor práctica actual es usar virtualenvs separados para cada proyecto de Python, esto requeriría que el usuario instale una copia de Pipenv para cada proyecto, lo cual no es muy intuitivo. Pipenv solo debe instalarse una vez (generalmente globalmente) y se usa fuera del virtualenv del proyecto para administrarlo, no dentro del virtualenv del proyecto.

Entonces, ¿cuál es la resolución de esto que llevó al cierre del problema? ¿No hay forma de realizar un seguimiento de las dependencias en Pipfile y en setup.py ? ¿Existe alguna práctica recomendada que evite el problema?

Para aplicaciones que se implementan o distribuyen en instaladores, solo uso Pipfile.

Para las aplicaciones que se distribuyen como paquetes con setup.py, pongo todas mis dependencias en install_requires.

Luego hago que mi Pipfile dependa de setup.py ejecutando pipenv install '-e .' .

[Actualización 2019-08-23] Actualmente mantengo los paquetes de desarrollo en Pipfile, solo las dependencias de tiempo de ejecución viven en setup.py.

Creo que el enfoque de @Korijn es la mejor práctica aquí. Pipfile (y requirements.txt) es para aplicaciones; setup.py es para paquetes. Sirven para diferentes propósitos. Si necesita sincronizarlos, lo está haciendo mal (IMO).

@uranusjr No según la documentación.

Pipenv es una herramienta que tiene como objetivo traer lo mejor de todos los mundos de empaquetado (bundler, composer, npm, cargo, yarn, etc.) al mundo de Python. Windows es un ciudadano de primera clase en nuestro mundo.

Crea y administra automáticamente un entorno virtual para sus proyectos, así como también agrega/elimina paquetes de su Pipfile a medida que instala/desinstala paquetes. También genera el siempre importante Pipfile.lock, que se utiliza para producir compilaciones deterministas.

Tal vez simplemente no lo estoy entendiendo. ¿Podría dar más detalles sobre su declaración, por favor?

La forma en que lo entendí es que pipenv es un sistema completo de gestión de dependencias similar al compositor para PHP, pero estoy empezando a darme cuenta de que no lo es. Especialmente porque pipenv no instalará las dependencias de una dependencia que tenga Pipfile y Pipfile.lock, pero no install_requirements en setup.py.

@vascowhite , la pregunta que está haciendo no se trata de pipenv, sino de una separación fundamental entre las herramientas de empaquetado de python. En el flujo de trabajo de Python, los archivos setup.py se utilizan para declarar las dependencias de instalación de un paquete distribuible. Entonces, si tengo un paquete como requests , y depende de que la gente tenga cffi instalado, lo declararía en mi setup.py para que cuando la gente ejecute pip install requests también realizará esa instalación si es necesario.

Los pipfiles, como los archivos de requisitos, no están destinados a ser recorridos recursivamente. En su lugar, hay un solo archivo pip que gobierna todas las dependencias de un proyecto que podría estar desarrollando. El punto de esto es que el antiguo flujo de trabajo generaba una lista aplanada de requisitos anclados, mientras que los Pipfiles contienen requisitos de nivel superior y prefieren no anclados cuando sea posible. Cuando instala un paquete, los requisitos de su setup.py se resuelven recursivamente para encontrar la mejor coincidencia que también se ajuste a sus otros requisitos.

Entonces, si quiere saber por qué los Pipfiles no se resuelven recursivamente, es porque no es así como se usan en Python. Ejecutar pipenv install última instancia requiere un destino que sea instalable por setuptools , lo que significa que tendrá sus requisitos de instalación definidos en su archivo de instalación.

@techalchemy Estaba a la mitad de una respuesta similar antes de que apareciera la tuya 😂 (borra todo)

También me gustaría señalar que @vascowhite lo que está preguntando no es de hecho extravagante. Con Pipfile y el archivo de bloqueo disponibles, es posible reconciliar los dos flujos de trabajo distintos. En un mundo ideal, Pipfile reemplaza el install_requires de setup.py y se usa para especificar dependencias virtuales, mientras que el archivo de bloqueo se usa para producir un conjunto de dependencias concretas basado en él, reemplazando requirements.txt.

El sistema de empaquetado de Python, sin embargo, está lejos de ser ideal en la actualidad, y requeriría mucha limpieza antes de que esto pueda suceder. Diablos, Pipenv ya está teniendo dificultades para manejar las dependencias en este momento (ps, no es culpa de nadie), probablemente apenas funcionaría a menos que sea para los proyectos más simples si se usa así.

Sin embargo, la esperanza no está perdida (al menos no la mía). Se ha propuesto e implementado una gran cantidad de PEP en torno a este problema, y ​​creo que las cosas están en el camino correcto con setup.py y requirements.txt moviéndose hacia un formato rígido y declarativo. Con un ecosistema tan grande, las cosas deben moverse lentamente (o ver Python 3.0), pero de hecho se están moviendo.

@techalchemy @uranusjr
Gracias a ambos por sus claras respuestas, aclaran algunas cosas en mi mente. Me parece que la documentación ya no indica lo que Pipenv puede hacer y esa es en parte la causa de mi confusión. Sin embargo, la mayor parte de mi confusión se debe a mí :)

Habiendo venido de PHP, me confundió el empaquetado en python, Composer es muy fácil en comparación. Encuentro Python mucho más fácil de desarrollar y me encanta usarlo. Esperemos que las cosas mejoren, estoy seguro de que lo harán gracias al esfuerzo de personas como ustedes y Kenneth Reitz.

Si sigue mi consejo mencionado anteriormente, puede armonizar perfectamente tanto setup.py como pipenv. No hay necesidad de ponerse todo quisquilloso. :)

parece que no soy el único que está confundido #1398

Aunque lo puse mucho mejor de lo que pude :)

Vine aquí para obtener información sobre el uso de pipenv con un setup.py ; agregando mis .2 centavos a la discusión.

Tengo un paquete de python que setup.py se parece a:

 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 puede ver, uso click en el punto de entrada del script para tareas como la creación y la implementación.

Cuando ejecuto $ my-pkg-name-cmdline build no encuentro click instalado, porque pipenv install --dev instala paquetes en pipenv virtualenv. Necesito jugar con pipenv shell/exit para que funcione. Parece que todavía hay algunas asperezas en esto.

Por lo tanto, +1 por no usar pipenv para paquetes.

Creo que se espera que llames a pipenv run my-pkg-name-cmdline build en ese escenario.

@Korijn Todavía no estoy seguro del flujo de trabajo correcto (todavía estoy experimentando un poco con pipenv).

Hasta el momento, el flujo de trabajo que parece estar funcionando para mí es:

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

Ahora puedo ejecutar el script click de compilación de mi paquete desde la línea de comandos.

si ingreso al virtualenv (paso 4) antes de instalar la aplicación localmente (paso 3), no funciona.

Tal vez solo tenga que volver a conectar mi cerebro para recordar que los paquetes deben instalarse antes pipenv shell (mientras que usar virtualenv requiere que instale paquetes con virtualenv activado).

@apiraino Creo que no lo estás entendiendo bien aquí. Si desea usar (importar) hacer clic en su paquete, debe ponerlo en install_requires en su lugar, para que las personas (incluyéndose usted) que instalen su paquete también puedan tener clic instalado. Ponerlo en extras_require['dev'] significa que es una dependencia opcional, es decir, su paquete puede funcionar sin él, pero instalar esos extras puede proporcionar ciertas características adicionales.

Esta discusión realmente ya no tiene nada que ver con Pipenv. Le sugiero que lleve este problema a un foro más adecuado, como StackOverflow o listas de correo relacionadas con Python.

@Korijn pipenv install '-e .' produce un Pipfile que no refleja los módulos enumerados en install_requires en setup.py

Este sigue siendo el caso de pipenv 9.0.3.

¿Cómo puedo generar Pipfile a partir de los install_requires de mi setup.py ?

no uses comillas

Dejé de usar comillas. Sin embargo, no se crea un Pipfile que incluya las dependencias de la sección install_requires de setup.py .

@benjaminweb Estaba confundido por lo mismo hoy. Sin embargo, estoy empezando a pensar que el comportamiento actual puede corregirse.

@techalchemy mencionó anteriormente que

Los pipfiles contienen requisitos de alto nivel y prefieren no estar anclados cuando sea posible. Cuando instala un paquete, los requisitos de su setup.py se resuelven recursivamente para encontrar la mejor coincidencia que también se ajuste a sus otros requisitos.

Si usa el flujo de trabajo mencionado en https://github.com/pypa/pipenv/issues/1263#issuecomment -362600555, cuando ejecuta pipenv install '-e .' en un proyecto sin un Pipfile existente, pipenv genera un nuevo Pipfile con la siguiente:

[packages]

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

En este caso, el único paquete que solicitó explícitamente que se instalara en virtualenv es el paquete en sí (es decir, "."), por lo que tiene sentido que solo "." se agrega a ( [packages] ) en el Pipfile. Del mismo modo, si pipenv install requests , ninguna de las dependencias de install_requires del setup.py de las solicitudes se agrega al Pipfile de su proyecto tampoco.

Sin embargo, cuando el paso de instalación del paquete ocurra a continuación, las dependencias install_requires se instalarán como parte de la resolución de dependencias para el paquete .

Tenga en cuenta que, a diferencia de Pipfile, Pipfile.lock registra todas las dependencias exactas para todo el virtualenv, que debe incluir las dependencias install_requires bloqueadas para versiones específicas. Si observa el Pipfile.lock que se genera, verá las dependencias install_requires la lista.

Es posible que no entienda bien cómo se espera que funcione. ¿Tal vez @techalchemy o @uranusjr puedan confirmar si esta es la forma correcta de pensar sobre esto?

Tu línea de pensamiento coincide con la mía. También mencionaré que con el avance reciente de Setuptools y herramientas como Flit , aún puede especificar las dependencias de su paquete en un buen formato TOML (en lugar de cadenas de requisitos en setup.py, que ciertamente no es muy bonito). Simplemente los especifica en pyproject.toml en lugar de Pipfile.

@uranusjr parece que lo que estás diciendo es que Pipfile solo necesita enumerar explícitamente las dependencias del proyecto si aún no están siendo capturadas por una herramienta de empaquetado como Setuptools o Flit (a través de setup.py o pyproject.toml)

Por ejemplo, si setup.py se ve así:

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

Entonces el Pipfile solo necesita lo siguiente:

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

Ejecutar pipenv install instalaría la dependencia A para producción y pipenv install --dev instalaría las dependencias A y B para desarrollo.

Si alguien ya está usando Setuptools o Flit, ¿hay alguna razón por la que las dependencias deban agregarse al Pipfile en [packages] o [dev-packages] ? Mirando las solicitudes como ejemplo, no me resulta obvio por qué las dependencias de desarrollo se enumeran explícitamente en Pipfile en [dev-packages] , pero las dependencias install_requires y test_requirements se capturan todas en la configuración .py.

Parece que la única razón por la que necesitaría agregar dependencias explícitamente a Pipfile es si no está usando Setuptools o Flit. ¿Es esto correcto? ¿Hay razones por las que esto no es cierto?

Creo que es solo preferencia personal. Enumerar las dependencias de desarrollo en extras_require[dev] es simplemente una convención; dev-packages OTHO es una clave bien definida. extras_require[dev] también permitiría a cualquier usuario pip install package[dev] , lo que puede no gustar a los mantenedores. Puedo entender que la gente prefiera uno u otro.

En cuanto a packages , no, realmente no hay un escenario que tenga más sentido que install_requires IMO. Sin embargo, estoy seguro de que a la gente se le ocurrirán usos creativos.

¿Por qué se cierra este tema?

@JulienPalard está cerrado por varias razones:

1. Los archivos Pipfiles y setup.py no están realmente destinados a mantenerse sincronizados, per se, creo que ha habido un montón de artículos vinculados que discuten los detalles, pero tl; dr Pipfile es aproximadamente equivalente a un nivel superior requirements.txt
2. Si desea que su proyecto (digamos que es el directorio actual) tenga su setup.py resuelto en el virtualenv administrado, el flujo de trabajo sería solo pipenv install -e . , esto coloca una sola entrada en su Pipfile (la raíz de nivel superior) y el gráfico de dependencia resuelto en su Pipfile.lock incluido el install_requires resuelto. Si desea actualizar virtualenv con los últimos contenidos debido a un install_requires modificado, debe ejecutar pipenv update que es lo mismo que pipenv lock && pipenv sync en la última versión.

¡Espero que esto sea útil!

En realidad son más similares que Pipfile es similar a requirements.txt : requirements.txt especifica todos los paquetes de manera plana mientras que Pipfile & setup.py requiere solo las dependencias de nivel de entrada. Pipfile.lock y requirements.txt contienen información similar.

Creé un script de sincronización de POC que se puede implementar aún más, pero actualmente cubre nuestro caso de uso:
https://gist.github.com/iddan/f190c3c7d54f4fc4655da95fb185e641

@iddan , eso es esencialmente lo que he estado diciendo, cada una de estas cosas representa una lista de nivel superior de sus dependencias, pero una está destinada a _instalar una aplicación_ ( setup.py ) y la otra está destinada a _desarrollarla_ ( Pipfile ).

En el primer caso de usar setup.py , tiene las mismas opciones para declarar dependencias abiertas o completamente ancladas que con requirements.txt , pero la mayoría de las personas usan aquí la fijación de dependencias abiertas. En un Pipfile también puede especificar pines estrictos o flexibles, pero se recomienda mantener esto como una lista _sin aplanar_ de su gráfico de dependencia. Nuevamente, quiero enfatizar que ambas cosas también son completamente válidas en archivos requirements.txt , por lo que enfatizo continuamente la separación de responsabilidades entre aplicaciones y bibliotecas. Escuchará esto enfatizado en cada charla y cada tutorial y en todos los mensajes que publique PyPA.

Pipfile.lock y requirements.txt no son lo mismo. Puede generar un requirements.txt válido a partir de un Pipfile.lock , pero no puede generar directamente un archivo de bloqueo a partir de un archivo de requisitos sin utilizar un intermediario Pipfile . Esto se debe a que un Pipfile.lock representa un cierre transitivo y siempre requerirá un Pipfile intermediario para realizar la resolución de dependencia.

En cuanto a la pregunta original, no hay razón para mantener un archivo setup.py sincronizado con un Pipfile que no sea simplemente incluir el directorio en cuestión como una ruta editable. Cuando ejecuta pipenv lock , las dependencias en el archivo setup.py se resolverán automáticamente. No estoy seguro acerca de su caso de uso específico, @iddan , o por qué necesita tener un analizador especial para volver a escribir las cosas en el archivo de configuración, pero sospecho que puede querer leer el artículo de Donald Stufft sobre setup.py vs requisitos. txt o para hacer referencia a este comentario de uno de nuestros mantenedores sobre la distinción y cómo se aplica específicamente a Pipenv.

Mi caso de uso es que en K Health tenemos repositorios con nuestros paquetes internos que son servicios independientes y también se pueden consumir como paquetes. Por lo tanto, nos gustaría compartir nuestras dependencias de nivel superior entre los consumidores del paquete y la configuración de desarrollo/implementación del servicio. Dado que estamos usando Pipenv para administrar nuestras dependencias, será bueno obtener una salida de Pipfile como setup.py

Suena como una variante de #2148 (reemplazando requirements.txt con Pipfile).

Pero esto se trata de setup.py

Esta. Asunto. Deberían. No. Ser. Cerrado.

Este tema está cerrado porque

1. Pipenv no es una herramienta de empaquetado .
2. Se ha tomado la decisión de no incluir funcionalidades de empaquetado en Pipenv.
3. Se ha aclarado cómo puede usar Pipenv para administrar las dependencias de desarrollo durante el desarrollo de un paquete.
4. Pipfile es un estándar abierto. Es fácil crear una herramienta de empaquetado basada en el formato Pipfile. El hecho de que Pipenv decida no hacerlo no implica excluirlo a usted de hacerlo.

Si realmente te importa tanto, haz una herramienta tú mismo. Con tanta anticipación en este problema, creo que no sería difícil ganar terreno si publica su solución aquí. Y con tracción, PyPA puede recomendarlo en la guía de empaque, al igual que Pipenv. Pero primero necesita construir la herramienta.

Además, aprenda a dirigirse a los mantenedores del proyecto con respeto. Consulte el código de conducta como referencia. Estamos felices de tener discusiones productivas, pero somos voluntarios y no estamos aquí simplemente para obedecer deseos individuales. Si no puede manejar eso, no se moleste en publicar.

Recomendaría bloquear este problema para evitar más discusiones. Creo que el punto se ha dejado claro.

¡Haz una cosa y hazla bien!

Hola a todos,

@Korijn leí esa parte en la que explicabas cómo usas extra_requires para sincronizar setup.py con Pipfile.

Estaba tratando de hacer eso y noté que Pipfile.lock no tiene los paquetes extra_require en la sección de desarrollo, así que cuando tienes el código fuente en un venv vacío y haces pipenv install --dev , ya que Pipfile.lock no tiene requisitos extra_require pipenv solo instala los paquetes en install_require .

configuración.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"]
)

archivo pip

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

¿No debería ser el comportamiento correcto que Pipfile.lock haya rastreado los paquetes de desarrollo extra_require?

Sí, esto me parece un error/limitación. Debe presentar un error/problema por separado para esto.

Creo que hay un problema abierto en el rastreador sobre este problema, aunque ahora mismo no puedo localizarlo. Busque problemas existentes antes de abrir uno. Gracias por adelantado :)

Esto no es un error, no puede usar la misma entrada base varias veces en un archivo pip. Si especifica una dependencia en la sección dev y también en la sección predeterminada, la sección predeterminada tiene prioridad sin importar qué.

Recorrería mi experimento mental normal, pero no tengo tiempo en este momento, así que confíe en mi palabra de que podría causar conflictos de dependencia y sorpresas cuando implementa algo y descubre que su dependencia de desarrollo oculta un conflicto.

@techalchemy , entonces, ¿cómo puedo administrar mis dependencias de desarrollo en este caso? Solo quiero saber cómo usar pipenv de una buena manera.

He estado pensando en esto para mi propio proyecto y me di cuenta de que realmente no necesito la distinción packages / dev-packages . ¿Qué tal incluir {editable = true, extras = ["dev"], path = "."} en packages .

echa un vistazo a este paquete de instalación de pipenv

Sincroniza pipfile/lockfile con 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

puede hacer $ pipenv-setup sync --dev para sincronizar las dependencias de desarrollo con requisitos adicionales. o $ pipenv-setup sync --pipfile para sincronizar pipfile en su lugar

y $ pipenv-setup check solo para hacer cheques

un comando para resolverlos todos 💯

¿Hay algún plan para fusionar el paquete pipenv-setup con pipenv?

@peterdeme

¿Hay algún plan para fusionar el paquete pipenv-setup con pipenv?

@uranusjr @techalchemy basado en la discusión anterior, creo que pipenv podría tener una filosofía algo diferente. Pero si los mantenedores están de acuerdo, me gustaría enviar una solicitud de extracción e intentar integrar pipenv-setup

Siempre puede analizar el Pipfile.lock con el módulo incorporado json . Extraiga las dependencias non-dev para su setup.py install_requires .
La clave "default" contiene "dicts" anidados del nombre del paquete junto con version números y markers .
No necesita depender de ninguna importación externa.

@ Kilo59 He visto gente haciendo esto. Un consejo para mencionar es que no olvide incluir Pipfile.lock como archivo_datos en setup.py (o incluirlo en MANIFEST.in). Y eso es para lockfile con dependencias ancladas. pipfile, por otro lado, no es trivial de analizar, si desea una versión semántica en Pipfile. El mismo requisito de dependencia puede mostrarse de múltiples formas.

¡Gracias @Madoshakalaka , tu herramienta funciona muy bien!

Estoy de acuerdo con otros pares en que las dependencias de Setup.py son diferentes de las dependencias del proyecto de Pipfile. Pero aún así, tener una forma programable de sincronizar aquellos sin trabajo manual es una excelente función para ahorrar tiempo. Además, evita errores tipográficos/errores comunes.

El setup.py ennegrecido también fue un buen toque :+1: