I find it very straightforward and obvious to use virtualenvs, which support everything this project purports to do. What is this, then? Some porcelain and convention around virtualenvs? Why do I need this?
It is exactly porcelain and convention around virtualenvs, and its benefits are, in brief: simplicity, security, and portability (as in operating systems).
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.
As someone constantly hopping between programming languages always found the use of virtualenv to be the opposite of "straightforward and obvious". I'm happy that Pipenv exists and that I can finally use Python with the same ease as Ruby+rbenv.
Pipenv solved the most annoying problem Python had before: inconvenient version isolation. Dependencies were installed globally by default, and virtualenv was too cumbersome to use easily. Pipenv solves all of those headaches.
"Pipenv solved the most annoying problem Python had before: inconvenient version isolation. Dependencies were installed globally by default, and virtualenv was too cumbersome to use easily. Pipenv solves all of those headaches."
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.
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.
One thing in particular Pipenv/pipfile needs to address is a standardised calculation of the hashed virtualenv paths.
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.
I'd love to hear a comparison to features provided by pip-tools. Managing the pyenv is nice, but not at the expense of giving up the ability to auto-update and remove stale dependencies from a requirements.txt file. Is this something pipenv can handle at this point?
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
It's a shame (for myself) that they are asking for previous open source experience. I just started using pipenv a few weeks ago and it's fantastic and would be inclined to help out, as long as someone would mentor me. Tough, I guess that would add more work to them.
It is an open source project though. You can definitely still help them out. Have a look at their issues page: https://github.com/pypa/pipenv/issues, fork the project and submit some PRs.
You could contribute by letting the team what windows issues you are having perhaps?
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."
The problems I’ve had were already documented in open Github issues and someone had found a hacky workaround for one of them, but they don’t appear to have anyone trying to fix them. I could hardly comprehend the problems, as they were well outside of Python. :( I have faith, though!
