Pipenv: One Year Later and a Call for Help
kennethreitz.org
kennethreitz.org
The most useful feature that motivated my switch to it was that it combines the env manager and package manager so users only need to use one tool to specify an environment and a set of packages, and to manipulate those packages. This was extremely useful when getting lots of novice Python programmers to start sharing code/build environments for their projects.
It additionally has a lockfile and hash-based package identification which improves security (if I remember correctly, these things are possible with straight pip/other package managers, but can either be disabled or are disabled by default--but it's been awhile, so I may well be wrong!).
In short, it gives you a slightly more opinionated definition of what a "project" (environment plus packages etc.) is, and in return the tool is much simpler.
For more info: https://docs.pipenv.org/
I've recently started using pipenv, and it has made me very happy. Ruby has very polished tools for managing interpreter versions as well as dependency management, and npm is OK, but before pipenv, Python was a slightly different headache every time that I had to set up a project.
Basic usage of pipenv is like Bundler or npm, so it was very easy to get started. It also has some extra features that Bundler doesn't have, and I haven't yet tried: installing Python interpreters on demand, built-in project code style checking, and security vulnerability checks on dependencies:
One thing that surprised me about pipenv though is the slugified virtualenv name. I work on many virtualenvs a day and keep them all in ~/.virtualenv/, no .env in the project, I use tree, and like code and artifacts to be seperate, and the dev environment to mirror deploy as closely as a I can. spacemacs loads them from there, my deploy mirrors this, and I use systemd units that use the absolute path on the target platform. easy to use, easy to explain.
pipenv does not support this workflow though, something I thought was quite common. Suggestions to allow this to be optional does not seem to be well received https://github.com/pypa/pipenv/issues/589#issuecomment-33071...
Maybe this is due to resourcing and will be fixed in time. For now, I just use pipenv for dependency management, and still use virtualenv like before. I would have liked to just use the one tool, but as it stands pipenv unfortunately is not a one stop shop for me - I really hope one day it will be.
I tried creating a PR for SublimeText's Anaconda plugin, and realised that right now it requires 4(!) separate subprocess calls, each of which starts a Python process to simply get the path of the current project's virtualenv. Until there is a very simple way (a max. 10-20 line function) to calculate this path, including a reference implementation in Python and JS, there is no way widespread editor support can happen.
https://github.com/pypa/pipfile/issues/88 https://github.com/pypa/pipenv/issues/985 https://github.com/DamnWidget/anaconda/issues/717 https://github.com/DamnWidget/anaconda/pull/720
Someone created a very relevant issue, and I would suggest taking the time needed to close this before doing any more publicity. https://github.com/pypa/pipenv/issues/1398
There you go: open source experience done!
As a 3D artist, I have to use Windows a lot and Pipenv doesn’t cooperate well with Windows shell.
From the pipenv site:
"Pipenv is a tool that aims to bring the best of all packaging worlds (bundler, composer, npm, cargo, yarn, etc.) to the Python world. Windows is a first–class citizen, in our world."