Hacker News Reader

Comment by kissgyorgy | Hacker News Reader

Still missing from the picture: pipenv, virtualenv, virtualenvwrapper, pyenv

I think the comic should be more aptly be titled "Life before pipenv".

Pipenv is the first (popular) sane tool to make Python accessible to programmers coming from other languages. Sure you can also just use bare virtualenv, but then you have to figure out how it works together with everything displayed in the picture.

Pipenv has been my solution as well. It handles venvs for all my projects, dev/prod configuration files, and auto-generation of requirements files.

> Sure you can also just use bare virtualenv, but then you have to figure out how it works together with everything displayed in the picture.

How so? I use virtualenv and don't have any issues. Seems pretty straight forward to me. I haven't moved to pipenv because it forces a folder structure on you, which I hate. The great thing about virtualenv is that you can be anywhere on your system, it doesn't matter, as long as you see the project name in paren's next to your prompt you know you are good.

I don't know the specific problems anymore, but I've set up virtualenv on ~5 separate occasions for my machines. Every time it was a long painful session of trial end error, that ended with a setup that was mostly stable (but also sometimes fell apart when I updated the system/homebrew ?) and also seemed to never be completely shielded off from othe dependencies I had installed globally. The workflow with Pipenv was the first stable, no hassle solution I experienced with Python.

> The great thing about virtualenv is that you can be anywhere on your system

That sounds like an anti-pattern to me. Each project (= directory) should bring its own environment with it and should be completely decoupled from the environment of other projects.

Well, my experience has been drastically different than yours. Virutalenv has been flawless for me.

>That sounds like an anti-pattern to me. Each project (= directory) should bring its own environment with it and should be completely decoupled from the environment of other projects.

Yes they should be decoupled, but why would I want in the same folder? If am building a Django app I don't want the entire instance of python inside my project folder for a few reasons. 1) It clutters it up. 2) The web service (user/group) needs to access the Django folder, why would I put python in a folder that the web service has control over? I much rather have my web application in /svr/www/webapp and my python virtualenv in /opt/python-virtual/webappname

Regarding '1)': It doesn't have to bin _in_ the directory, and AFAIK it isn't with pipenv. Regarding '2)': That sounds like a deployment issue? Certainly nothing I've experienced on my development machine. With pipenv your still free to generate a requirements.txt and deploy your app with whatever webserver setup you want.

>With pipenv your still free to generate a requirements.txt and deploy your app with whatever webserver setup you want

yeah but then I can't be in the Django web application folder and just type "python manage.py makemigrations", for example. I would have to be the pipenv folder then "python /srv/www/webapp/manage.py makemigrations".

Unless I am missing something, which could be the case.

You would be in the Django web application folder (which has a Pipfile) and run "pipenv run python manage.py makemigrations" or run "pipenv shell" and then "python manage.py makemigrations". There is no "pipenv folder" you need to think about. There is a virtualenv folder somewhere on the system, but activation of that etc. is all managed by the pipenv command and tied to a project.

Let’s say I want Anaconda. Is pipenv the right way to go? Do they play nicely?

Not to be glib, but your comment ironically reminds me of this: https://xkcd.com/927/

No amount of adding things to the Python comic is going to simplify it.

I think the intent here is to convince adherents of other tools to switch to pipenv. Having used most of the solutions in this thread, pipenv has been the simplest and the one that "just works" most often.

Yeah, that one also popped into my mind when I wrote the comment.

> No amount of adding things to the Python comic is going to simplify it.

It doesn't simplify it, but it puts you in a whole new canvas where you don't have to worry about whats in the messed up one.

they also forgot the part, where every package manager has his own way of installing python packages

All of which work fine, the real problem is installing Python with homebrew. If you just install Python from the binary on the website then any of those solutions will work with minimal drama.

Why is this? What's the difference between Homebrew Python and website Python?

https://github.com/Homebrew/homebrew-core/blob/master/Formul...

Homebrew pulls it directly from the Python.org, but it's also slightly opinionated in what else it installs. I would suggest just reading through the formula to see what it does (it's straighforward).

Likewise, you can quickly see what any Homebrew package is doing with `brew info <package>` and looking at the "From:" link.

Don’t forget the shell specific stuff that wraps virtualenv. Thinking of the OhMyZSh plugins that do cool things on top of virtualenvwrapper...

And `pyenv-virtualenv`!

Reply on news.ycombinator.com