Pipenv: ¿Cómo conoce pipenv el virtualenv del proyecto actual?

El nombre de virtualenv es el nombre del directorio raíz del proyecto, más el hash de la ruta completa a la raíz del proyecto. Esto garantiza que el nombre sea único y predecible siempre que no mueva el proyecto. (AFAICT, esta lógica de generación de nombres es un detalle de implementación en el que no se debe confiar).

Para instalar una versión específica de un paquete, use la misma sintaxis que usaría con pip y requirements.txt, por ejemplo, pipenv install django==1.11.0 .

@uranusjr Esto significa que si cambio el nombre del directorio, se perderá el virtualenv de mi proyecto. Eso es malo. Puede ser un caso de uso común cambiar el nombre de un directorio y los usuarios pueden caer en esto y preguntarse cómo dejó de funcionar su entorno.

Sugeriría arreglarlo y hacer una entrada en Pipfile si eso es posible. O cree otro archivo .pipenv para almacenar dichos metadatos en cada directorio del proyecto.

Que sugieres ?

¡Gracias por responder ambas preguntas!

Hola @ sachinjain024 , hemos tenido algunas discusiones sobre el archivo de metadatos local, pero el consenso del mantenedor ha sido que pipenv no lo admitirá en este momento.

La ruta del directorio que identifica un proyecto fue algo que se implementó desde el principio porque los proyectos con el mismo nombre, o varias copias del mismo proyecto, estaban causando la sobrescritura accidental del estado del entorno.

En la práctica, hemos descubierto que muchas menos personas han tenido problemas con la ubicación como parte del entorno que la sobrescritura silenciosa de su trabajo. Después de todo, Pipenv es una herramienta de administración de implementación, por lo que mover el directorio debería ser una solución de un solo comando.

Gracias @nateprewitt. Tiene sentido pasar rápidamente a una implementación sencilla. Supongamos que cambio el nombre de un proyecto en una etapa posterior, entonces significa que mi entorno no existe.

Entonces, ¿qué debo hacer en esta situación?

1. Restablezca el entorno porque ya tengo Pipfile que tiene la información de los paquetes, por lo que será fácil restablecer el entorno.
2. De alguna manera también cambie el nombre del directorio virtualenv
3. ???

¿Qué sugieres en este caso? Solo curiosidad por si me encuentro en esta situación en el futuro.

Puede usar pew cp para copiar fácilmente el virtualenv existente, pero creo que 1. sería la forma más "canónica" de hacerlo.

@ sachinjain024 , siempre que necesite mover el directorio de su proyecto, solo debe ejecutar pipenv install para volver al estado de trabajo. Esto creará un entorno para usted con el nuevo hash y reinstalará todo, desde el archivo de bloqueo de forma idéntica a la instalación anterior con la que fue creado.

Si se encuentra haciendo esto con frecuencia, es posible que desee usar pew rm old_project-a3de90 para limpiar.

No recomendaría usar pew cp menos que esté modificando el entorno virtual fuera de pipenv. En ese caso, creo que tendríamos que considerarlo como un escenario de "garantía anulada", porque hay todo tipo de cambios que no podemos explicar de manera confiable.

Gracias @nateprewitt @uranusjr. Cerrando este ticket.

Esta es una de las peores ideas que surgieron de pipenv hasta ahora. Este es el por qué:

Trabajo en una empresa, donde Python se usa para la automatización de pruebas de muchos proyectos internos. Un probador suele funcionar con una docena de ellos. Por convención, todo el código de prueba de un proyecto vive en un directorio llamado tests . Esto significa que cada evaluador ahora tiene un montón de entornos virtuales, todos llamados algo así como ~/.local/share/virtualenvs/tests-hKjFddnZ - ¡increíble! Es una naturaleza humana olvidarse de cambiar el entorno virtual, por lo tanto, cada pocos días me llaman a una estación de trabajo diferente porque la persona en esa estación de trabajo cree que instaló el paquete que necesita, ejecutó pipenv install , pero las importaciones en el código no funcionan. No solo eso, los entornos virtuales huérfanos se acumulan con el tiempo, sino que, dado que todos tienen nombres anodinos, no hay forma de saber si estoy eliminando el entorno que no está en uso o el que realmente se ha utilizado. Esto significa que en CI creamos docenas, si no cientos, de entornos virtuales a diario. No hay forma de que alguien pueda realizar un seguimiento de los entornos que tienen nombres esencialmente aleatorios, y hay demasiados de ellos, por lo que tenemos que eliminarlos todos al menos una vez al día. Pagamos un gran peaje en los tiempos de espera solo por esta decisión súper inteligente tomada por pipenv y alguien en nuestra empresa, que decidió usarlo ...

Establezca export PIPENV_VENV_IN_PROJECT=1 en su configuración bashrc / shell.
(O cambie sus scripts de shell para crear un venv en $ PROJECT / .venv y luego
pipenv tendrá eso)
El lunes 19 de marzo de 2018 a las 6:28 a.m. wvxvw [email protected] escribió:

Esta es una de las peores ideas que surgió de pipenv hasta ahora. Este es el por qué:

Trabajo en una empresa, donde Python se usa para la automatización de pruebas de muchos
proyectos internos. Un probador suele funcionar con una docena de ellos. Por
convención, todo el código de prueba para un proyecto vive en un directorio llamado tests.
Esto significa que cada evaluador ahora tiene un montón de entornos virtuales, todos
llamado algo como ~ / .local / share / virtualenvs / tests-hKjFddnZ -
¡increíble! Es una naturaleza humana olvidarse de cambiar el entorno virtual, por lo que,
cada pocos días me llaman a una estación de trabajo diferente porque la persona
en esa estación de trabajo piensa que instalaron el paquete que necesitan,
ejecutó pipenv install, pero las importaciones en el código no funcionan. No solo
que, los entornos virtuales huérfanos se acumulan con el tiempo, pero como todos
de ellos tienen nombres anodinos, no hay forma de saber si estoy borrando
entorno que no está en uso, o el que realmente se ha utilizado. Esta
significa que en CI, creamos docenas, si no cientos, de entornos virtuales
a diario. Nadie puede realizar un seguimiento de los entornos que tienen
esencialmente nombres aleatorios, y hay demasiados de ellos, por lo que tenemos que
bórrelos todos al menos una vez al día. Pagamos un peaje enorme en los tiempos de espera
solo por esta decisión súper inteligente tomada por pipenv y alguien en
nuestra empresa, que decidió utilizarlo ...

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/pypa/pipenv/issues/796#issuecomment-374211264 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ABhjqyABdDHCB8WMm-hJwdkNptVlh8fuks5tf7KBgaJpZM4Pp3kf
.

@jtratner Entonces, ¿por qué necesito pipenv si voy a crear un entorno virtual a mano?

El entorno virtual es un trabajo en sí mismo. Es poco convincente en todas partes y está roto en Windows (se supone que en MS Windows, de todos los lugares, el directorio de inicio predeterminado se llama "~"). Tenía la esperanza de que si alguien fuera a rehacer PIP y el entorno virtual, arreglarían los errores obvios de sus predecesores ... en cambio, hay este lío multiplicado por una capa de incompatibilidad.

Estás haciendo suposiciones incorrectas. Pipenv no rehace virtualenv ni pip. Se basa en ellos.

@uranusjr eso es un problema de comprensión de lectura. Sé muy bien lo que hace pipenv , ya que paso mucho más tiempo depurando su código del que me gustaría. Rehacer el entorno virtual y PIP es el objetivo declarado del proyecto. Que, en lugar de arreglarlos, decidió usarlos "tal cual" es otro gran error por parte de pipenv , seguido de usar la biblioteca click , y la lista continúa.

Rehacer el entorno virtual y PIP es el objetivo declarado del proyecto.

¿Dónde dijo alguien esto?

También encontré que este comportamiento era extraño, esperaba que pipenv eligiera un nombre estándar para un directorio virtualenv y pusiera el directorio en el directorio actual, simalar a la forma en que npm usa node_modules .

@Flimm export PIPENV_VENV_IN_PROJECT=1 . Lea la documentación.

@uranusjr Leí todos https://docs.pipenv.org y https://docs.pipenv.org/basics/ , y a menos que me lo perdiera, nunca menciona dónde están instalados los directorios virtualenv , tampoco advierte a nadie que cambiar el nombre o mover el directorio del proyecto hará que el directorio virtualenv tenga que ser recreado.

PIPENV_VENV_IN_PROJECT tiene un nombre confuso, ya que pipenv no usa venv enviado en la biblioteca estándar, usa virtualenv , que es un proyecto diferente.

Solo estoy tratando de proporcionar comentarios sobre las cosas con las que tropecé mientras me familiarizo con este proyecto.

@Flimm el punto es abstraer esta información. Si sabe cómo funcionan otras herramientas que administran virtualenvs, ya debería saber que mover la carpeta de virtualenvs las hace imposibles de encontrar. Si no está familiarizado, probablemente no buscará esto en primer lugar.

En cuanto a la biblioteca de backend que usamos para generar virtualenvs y el nombre de las variables de entorno, la primera no es tan importante y la segunda es una abreviatura ampliamente aceptada. Si bien los detalles son importantes, este no parece que esté causando problemas a nadie, y su objeción principal parece basarse en que no está seguro de qué backend usamos para colocar un ejecutable de Python en una carpeta. Si encuentra errores, infórmelos. Realmente no vamos a cambiar las variables de entorno, sólo porque sí.

La variable de entorno está disponible en los documentos: http://pipenv.readthedocs.io/en/latest/advanced/#configuration -with-environment-variables por lo que probablemente no los leyó todos si no vio eso

@techalchemy Por otras herramientas, supongo que te refieres a algo como virtualenvwrapper . Pasé años sin usar virtualenvwrapper . Supongo que la cantidad de desarrolladores de Python que están familiarizados con el patrón node_modules de Node / NPM es mayor que la cantidad de desarrolladores de Python que están familiarizados con virtualenvwrapper o pipenv patrón de ocultar el directorio del entorno. Pero es una suposición. Para aquellos que no están familiarizados con ninguna de estas herramientas, creo que sería confuso no saber dónde terminan los archivos instalados. Señala que esto solo se explica en la sección avanzada de los documentos en la subsección de variables de entorno, creo que debería explicarse en los documentos mucho antes. Quizás envíe una solicitud de extracción.

He comentado sobre la referencia confusa a venv lugar de virtualenv en el nombre de PIPENV_VENV_IN_PROJECT en otro número # 1919. Basta decir que no ocupo el puesto que creo que creo que tengo.

En cualquier caso, se responde a la pregunta del número original. No quiero prolongar esta discusión, siéntase libre de tener la última palabra si lo desea.

Entiendo que esta es la audiencia incorrecta, pero dado que esta discusión continúa ... bueno, no creo que node_modules hayan sido una inspiración para pipenv , y no para virtualenv tampoco. Mi suposición puede ser históricamente incorrecta, pero al tener que trabajar con rbenv y virtualenv , puedo decirles que virtualenv siente como una mala copia sin comprensión, o tal vez un prototipo temprano, que fue mejorado en rbenv . En cualquier caso, virtualenv es un hazmerreír en comparación con rbenv , y este es el motivo:

Copia paquetes para cada entorno. Esto es estúpido, lento y confuso. Es solo una mala decisión de diseño, pero lo más probable es que solo sea una falta de decisión: simplemente sucedió así porque alguien escribió un código para colocar estos paquetes en un directorio arbitrario. Además de eso, realmente no funciona en Windows. Hasta el punto de que nunca se probó realmente en Windows ... Una cosa ridícula de esto es que prueba el sistema operativo, y una vez que descubre que se ejecuta en Windows, establece el directorio de inicio en ~ , este valor predeterminado Más tarde, algunas variables de entorno pueden anularlo, pero si realmente está intentando ejecutar su automatización en un entorno supervisado y limpio ... virtualenv simplemente nunca instalará los paquetes en el mismo directorio.

Entonces ... pipenv alega ser una herramienta para los seres humanos, algo así como requests ... ¿supongo? Entonces, debería mejorar los esfuerzos inmaduros hechos por sus predecesores ... bueno, parece que ese sería el camino a seguir, si quieres hacer un programa que haga lo mismo que los anteriores, pero mejor, ¿no? ? Y, sin embargo, en lugar de tirar la basura de virtualenv , lo usa como está. El contenedor solo es diferente del programa empaquetado en que no permite / hace que sea más difícil usar algunas de las funciones del programa empaquetado ...

En mi vida, he visto muchos intentos de hacer la automatización, lo cual apestaba, pero ustedes están apuntando a las estrellas, ponen todas esas valoraciones inmerecidas en su sitio, incluso antes de poner cualquier información útil. Pero no está a la altura de la promesa. En realidad, simplemente manipula la opinión pública, sin hacer ningún trabajo real. Y ahora los programadores que tienen que hacer la automatización deben enfrentarse a otro mal, solo porque alguien quería obtener más "Me gusta" en GitHub ...

@wvxvw De hecho, no es correcto. virtualenv es anterior a rbenv en algo así como cinco (cuatro, ver más abajo) años y, por lo tanto, nunca puede inspirarse en él. También son cosas fundamentalmente diferentes, solo logrando un objetivo similar al final. Lo que está buscando (herramienta de administración de tiempo de ejecución inspirada en rbenv) es pyenv.

También con respecto a que virtualenv no está a la par con otras herramientas, ¿sabe que ha existido durante diez (10) años? Los requisitos de desarrollo de software cambian mucho, y las suposiciones que hizo se han ido quedando obsoletas, y nadie se ha preocupado de dar un paso al frente para reemplazarlo. ¿Te importa lo suficiente como para dar un paso al frente?

Entiendo que todos merecen la oportunidad de hablar, pero unirse a una discusión sin una comprensión mínima del tema y comenzar a señalar con el dedo de inmediato, es una mala educación para los colaboradores de los sistemas de empaquetado Pipenv, virtualenv y Python en su conjunto. Por favor no hagas esto.

Editar: Investigué un poco. La versión inicial de virtualenv, 0.8, se realizó en 2007, mientras que la de rbenv (0.1) fue en 2011, por lo que tienen cuatro años de diferencia, no cinco.

@wvxvw Solo te he visto ofrecer insultos. Este tipo de actitud no es realmente bienvenida aquí. Consulte nuestro código de conducta antes de continuar publicando.

Tuve el mismo problema después de cambiar la ruta del proyecto y perder el mapeo virtualenv original, luego leí este hilo. Primero, agradezco el trabajo del equipo pipenv. Acabo de recibir algunas opiniones que me gustaría compartir sobre esta discusión:

1. De hecho, el documento debería señalar el mecanismo de mapeo entre la ruta del proyecto y env, al menos advertir a los usuarios que changing project path would cause unmapping the original env .

2. ¿Será mejor si puede establecer manualmente la ruta al env en el Pipfile? Quiero decir que las personas pueden tener algunos requisitos especiales para usar manualmente el mismo env.

Solo mis opiniones para compartir con ustedes.

No está completamente claro cómo usar pipenv. ¿Debería tener muchos entornos virtuales para un proyecto? ¿Debo compartir los entornos virtuales entre proyectos? ¿Cómo instalo una versión de Python diferente para un proyecto específico con pipenv, si la versión de Python solo es necesaria para ese proyecto? Todos están tan llenos de sí mismos en este hilo, asumiendo un montón de cosas sobre otras personas, sin nunca tratar de entender de dónde vienen los demás. Cuando leí los elogios de pipenv en la página de inicio, creí que me ayudaría. En cambio, desperdicié 5 días luchando con eso, y ahora creo que vuelvo a pyenv porque eso fue al menos algo determinista.

si desea utilizar varios entornos para un proyecto, utilice tox. Utilice pipenv para su entorno de desarrollo principal y tox para realizar pruebas en varias versiones de Python.

@ashnur , claramente necesitas algo que hacer. En lugar de difundir la negatividad entre un proyecto de código abierto dirigido por voluntarios, ¿por qué no intentas contribuir con algo útil?

@uranusjr
aquí es donde ocurre el hash?

Estoy trabajando en un proyecto y necesito calcular el hash de una ruta.

@devxpy Sí, exactamente.

Creo que deberían poner un tutorial básico sobre cómo configurar un virtualenv con pipenv, algo muy básico porque cuanto más fácil sea para las personas, más personas lo usarán, pero si causa confusión, es posible que más personas no lo usen y busquen otros. lenguajes o métodos para construir sus proyectos

@uranusjr ¿cuál es la razón por la que Pipenv no crea virtualenv de forma predeterminada en el directorio del proyecto? A mi modo de ver, resolvería el problema con los entornos huérfanos cuando el proyecto cambia de nombre, se mueve o se elimina. Además, sería menos confuso para las personas que (con algo de razón) esperan que funcione como npm.

¿Hay algún beneficio en preferir este enfoque además de quizás la tradición?

Simplemente cree el directorio .venv antes del comando pipenv install. Una opción —venv o —dot-venv para instalar pipenv sería bienvenida, de hecho :)

A partir de 2018.10.9, hay otra forma de hacer esto. Puede agregar un archivo .venv que contenga la ruta a su entorno virtual. (¡Nueva característica disimulada!)

@andrewpeterprifer Porque solíamos hacer esto, y necesitábamos cambiarlo porque algunas personas lo rechazaron con mucha fuerza. Necesitamos elegir un enfoque u otro, y tuve que admitir que es mejor por defecto no poner entornos virtuales dentro del directorio del proyecto.

ps ¿Usted (o alguien) estaría interesado en escribir una entrada de preguntas frecuentes sobre esto? Probablemente tomaría algunos párrafos, pero estaría más que feliz de explicar si alguien promete tomarse el tiempo para pulir el texto y enviar un PR.

@uranusjr Tengo

PD: Podría escribir una entrada de preguntas frecuentes si explicas por qué las cosas son como son. ;)

A partir de 2018.10.9, hay otra forma de hacer esto. Puede agregar un .venv _file_ que contenga la ruta a su entorno virtual. (¡Nueva característica disimulada!)

@andrewpeterprifer Porque solíamos hacer esto, y necesitábamos cambiarlo porque algunas personas lo rechazaron con mucha fuerza. Necesitamos elegir un enfoque u otro, y tuve que admitir que es mejor por defecto no poner entornos virtuales dentro del directorio del proyecto.

ps ¿Usted (o alguien) estaría interesado en escribir una entrada de preguntas frecuentes sobre esto? Probablemente tomaría algunos párrafos, pero estaría más que feliz de explicar si alguien promete tomarse el tiempo para pulir el texto y enviar un PR.

Lamento chocar ... Tengo la misma necesidad de mover carpetas de proyectos que tienen un entorno virtual creado con pipenv.

Actualmente hago lo siguiente y no tengo ningún problema:

• Muevo la carpeta del proyecto a donde quiera
• en C: \ Users \ user \ .virtualenvs elimino la carpeta del venv asociado al proyecto que acabo de mover
• Navego a la ubicación de la carpeta del nuevo proyecto a través de cmd y ejecuto pipenv install (o pipenv shell y luego pipenv sync)

Todo funciona bien. ¿Es esta una mala práctica?

Con respecto al comentario de
Si ese es el caso, ¿no sería mejor si dicho archivo se creara automáticamente en la carpeta del proyecto cuando se crea inicialmente el entorno virtual?

PD: también estoy dispuesto a escribir preguntas frecuentes

En realidad, creo que la idea de @ gioxc88 es buena, un virtualenv recién creado puede generar automáticamente el archivo .env en la raíz del proyecto y contiene configuraciones de env como PATH . Hará que el entorno sea más transparente para los desarrolladores y una forma más conveniente de reconfigurar.

Intentaré responder a sus preguntas juntos. El enfoque no es malo (en mi opinión, yo también uso la misma configuración). Sin embargo, es más fácil para un usuario inconsciente tropezar.

Una forma de pensarlo sería considerar poner un proyecto en control de versiones (por ejemplo, Git). Si el entorno se crea en la raíz del proyecto, naturalmente estaría en la raíz del repositorio. Las personas como usted y yo, que estamos acostumbrados a esta configuración, obviamente saben que debemos agregar una regla en .gitignore (o la configuración global de ignorar) para evitar que se registre el directorio .venv , pero un usuario desprevenido no lo haría, y podría comprobar fácilmente el entorno por accidente. Esto no solo es malo para la gestión de proyectos, sino que (lo que es más importante) proporciona un vector de posibles ataques al exponer información local. Por lo tanto, es una regla general para las herramientas de gestión de proyectos evitar colocar archivos generados dentro del directorio del proyecto . Podría estar bien (todavía no es óptimo en mi opinión) hacerlo si está diseñando un ecosistema desde cero (por ejemplo, node_modules NPM), pero definitivamente no es una buena idea para herramientas creadas para un ecosistema con prácticas comunes establecidas, como el caso de Pipenv.

Si un entorno se genera fuera de la raíz del proyecto de forma predeterminada, hay una cosa menos posible de la que preocuparse cuando publique su proyecto (por ejemplo, envíelo a GitHub). Hace que nuestras vidas (que prefieren los entornos dentro del proyecto) sean un poco más difíciles, pero desde una perspectiva de riesgo, lo peor que puede suceder es mover accidentalmente el proyecto y romper el entorno, u olvidarse de eliminar un entorno cuando se elimina un proyecto. . Cualquiera de los dos es mucho, mucho más fácil de recuperar que enviar accidentalmente la información de su entorno potencialmente sensible a GitHub.

La función de archivo .venv todavía es bastante nueva (lanzada hace solo unos días), y todavía estamos explorando formas de utilizarla mejor. Todavía tiene el mismo problema de un directorio .venv , pero con suerte no tan malo. Realmente me gusta la función y definitivamente espero que podamos usarla para mejorar la experiencia del usuario, pero todavía hay mucho que considerar aquí.

Hola. Para mí, el directorio .venv (función anterior) y el archivo .venv (función nueva) están bien, pero estaría muy agradecido de tener una opción en el comando pipenv install.

Algo como:

pipenv install

Se instalaría en ~/.local/

pipenv install --venv

Se instalaría en el directorio $PWD/.venv

pipenv install --venv-dir /my/custom-path

Se instalaría en /my/custom-path .

Si desea una nueva característica, propóngala correctamente haciendo una propuesta de mejora a ~/.peeps . No haga propuestas de mejora dispersas al azar en torno a varios problemas, no es rastreable.

@uranusjr ¡ gracias por la respuesta detallada! Solo para satisfacer mi curiosidad, ¿qué tipo de información local (potencialmente sensible) podría ser expuesta por un venv de Python verificado? Estoy de acuerdo en que es molesto si node_modules se registra, pero normalmente eso no contendría ninguna información local.

Los entornos virtuales de Python contienen varios scripts de shell (por ejemplo, activate ). Mucha gente los modifica para agregar variables de entorno para especificar las contraseñas de la base de datos, la ruta a otro archivo de configuración, etc. -experiencia personal).

Además, tiene razón, node_modules probablemente no contenga información confidencial. Ese es otro beneficio cuando construye un ecosistema desde cero. Desafortunadamente, los entornos virtuales de Python se inventaron mucho antes de que esto fuera un problema común (en ese entonces ya eres un gurú si usas VCS).

Llegué aquí mientras intentaba entender cómo pipenv conoce el virtualenv correcto :)

Gracias chicos por esa discusión. Probablemente, podría ser una buena idea especificar en la página principal (por ejemplo, aquí ) que cambiar el nombre de la ruta del proyecto rompe el mecanismo predeterminado de vinculación virtualenv.

Todas las páginas de documentación están abiertas para contribuciones. No pidas cosas, hazlo :)

¡Voy a!

@uranusjr Esto significa que si cambio el nombre del directorio, se perderá el virtualenv de mi proyecto. Eso es malo. Puede ser un caso de uso común cambiar el nombre de un directorio y los usuarios pueden caer en esto y preguntarse cómo dejó de funcionar su entorno.

Sugeriría arreglarlo y hacer una entrada en Pipfile si eso es posible. O cree otro archivo .pipenv para almacenar dichos metadatos en cada directorio del proyecto.

Que sugieres ?

¡Gracias por responder ambas preguntas!

gracias por hacer tanto la pregunta. también me encuentro con el mismo problema,

Si inicializó pipenv en un directorio incorrecto y tiene que utilizar el directorio virtualenv del directorio correcto, puede obtener la ruta virtualenv haciendo pipenv --venv y mover PIpfile y Pipfile.lock al directorio correcto.

echo ${PATH_OBTAINED_FROM_PREVIOUS_COMMAND} > .venv en el directorio correcto y debería funcionar correctamente.

Hoy noté que si hay un pipfile en el directorio principal, pipenv ignora la variable ambiental export PIPENV_VENV_IN_PROJECT=1 e instala un venv en el directorio principal. Esto está en el lanzamiento 2018.11.26 . Si elimina el archivo pipfile del directorio principal, pipenv funciona como se documenta.