Hacker News Reader

Comment by foobarandgrill | Hacker News Reader

>Why? pipenv handles dependency- and virtual-environment-management in a way that’s very intuitive (to me), and fits perfectly with my desired workflow.

Why specifically do you use it instead of virtualenv (+virtualenvwrapper)?

View on HN

Pipenv combines package management and virtualenv managment in one tool. You can create a new project as simple as this:

    $ mkdir myproj
    $ cd myproj
    $ pipenv --python 3.6         # This creates a virtualenv with Python 3.6 for you project.
    $ pipenv install flask        # This installs flask in your virtualenv.
    $ pipenv run flask            # This runs flask in your virtualenv.
    $ pipenv run python           # This runs a REPL with the interpreter of your venv.
    $ pipenv shell                # This opens a shell in your venv.

Pipenv replaces requirements.txt with Pipfile and Pipfile.lock. (Similar to what you get from npm or yarn in the JS world, and cargo in Rust)

If you use pipenv for a project, you no longer need to care about pip, requirements.txt or virtualenv.

Pipenv/Pipfile is the new standard recommended by Python.org/PyPA:

https://packaging.python.org/tutorials/managing-dependencies...

https://github.com/pypa/pipenv

https://github.com/pypa/pipfile

let me add, that if you do a virtualenv-based workflow, you will end up having some kind of a requirements list (requirements.txt), then you will realize that you want to also version the configuration of that virtualenv with all dependencies resolved (think `pip freeze`). You'll start to sort development dependencies like pytest from production requirements like `six`, by this time you will have written a few scripts to deal with this stuff.

This is where pipenv delivers. It is a destillation of best practices for virtualenv-configuration.

In your overview, I'd just add an example for a dev installation

    pipenv install --dev pytest

I was recently explaining this here — you still end up with a virtualenv so it's not a difference in capabilities but rather ease of use:

1. It transparently creates the virtualenv for you

2. The pipfile format handles dependencies and version locking (including hashes of packages), including updates. That means that the versions won't change without your knowledge but upgrading to the latest versions of everything is simply running "pipenv update" to have the virtualenv completely rebuilt (i.e. you'll never forget to add a dependency to a requirements file) and the lock file updated so the next time you push your code the same versions you tested are certain to be used.

3. It'll automatically load the .env file for every command – i.e. your project can have "DJANGO_SETTINGS_MODULE=myproject.site_settings" in that file and you will never need to spend time talking about it in the future.

4. It separates regular and developer dependencies so you don't install as much on servers

5. "pipenv check" will let you know whether any of the versions of any of the packages installed have known security vulnerabilities

6. Pipfile also includes the version of the Python interpreter so e.g. your Python 2 project will seamlessly stay on 2.7 until you upgrade even if your system default python becomes 3.

None of this is something you couldn't do before but it's just easier. Every time a Python point release happens you have to rebuild a virtualenv and now it takes 5 seconds and no thought.

To further elaborate on 2, it solves the problem of maintaining loose version ranges in your requirements.txt file, but keeping the versions pinned when you deploy. For example if you put `foo>=2` in your requirements.txt, this is dangerous without some way of pinning e.g. `foo==2.18.2` and running your tests against that before you deploy. But you obviously don't want to manually edit requirements.txt with minor version numbers every time you update. In the past I've maintained a separate file with loose versions and then updated packages with

  pip install -r requirements-to-freeze.txt --upgrade && pip freeze -l -r requirements-to-freeze.txt > requirements.txt

Pipenv makes this much nicer.

Don't forget that usually you'll start to sort your requirements into dev requirements and production requirements which makes these packaging scripts much more complicated.

https://github.com/jazzband/pip-tools would be what I used before pipenv came to be.

Two features I miss from pip-tools:

1. `pip-sync`, An easy way to ensure my local environment actually matches my defined requirements. I guess the pipenv version of this would be `pipenv uninstall --all && pipenv install` which isn't quite as elegant, but perhaps good enough.

2. The ability to create more than two requirement sets. For my projects it's often handy to three sets of requirements:

• Normal production requirements end users will need to run the app

• CI requirements needed for testing, but not running the app in production (Selenium, Flake8, etc)

• Local debugging tools (ipython, ipdb)

I could include my local debugging tools in the `--dev` requirements, but then I'm unnecessarily making my CI builds slower by adding requirements for packages that should never actually be referenced in committed code. Alternatively, I could leave them out of my dependencies entirely, but then I have to remember to reinstall them every time I sync my local env to ensure it matches the piplock file.

  pip-compile --upgrade
  pip-compile --upgrade-package

are also necessary features to quickly track your dependencies (and transitive deps).

pipenv uses pip-tools, but they haven't exposed these features as far as I can tell.

pipenv is basically a wrapper around virtualenv (similar to virtualenvwrapper), but also provide other features (like deterministic builds). It has replaced pip, virtualenv and dealing with requirements.txt files in my workflow. More information is in their docs: https://docs.pipenv.org/.

It was easier for me to setup and maintain multiple virtualenvs. It automatically checks for security vulnerabilities. The docs at http://pipenv.readthedocs.io/en/latest/ are worth a read. It might be a bit more opinionated than some folks are used to.

pipenv combine pip and venv. It's not just about activating. If you install, it will create the virtualenv if it's missing.

It also, like pew, opens the virtualenv in a new shell instead of activating the current shell. A much saner approach.

The UI is also more user friendly: one entry point for everything, pretty colors and icons, auto-correct of package name, and so on.

Using Pipfiles, instead of requirements, are generally a better experience than requirements.txt since it contains dev and prod dependancies and allow separated dependancy pinning, with file hash.

Does it install and manages different python versions? Pyenv does

If you have pyenv installed it can use it to install the correct python version defined in the Pipfile.

pipenv has Pipfile support, which is nice because you don’t need multiple requirements.txt floating around, and pinning is way nicer. Apart from that, it isn’t unlike virtualenvwrapper, but it’s way less hacky. Works on non-bash compatible shells and Windows, it loads .env files automatically, and it’s generally a pleasure to use. Highly recommended.

Reply on news.ycombinator.com