Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A non-magical introduction to pip and virtualenv for Python beginners

dabapps.com

Post reply on HN
Print view View original

41–50 of 86 posts

Re: A non-magical introduction to pip and virtualenv for Python beginners

#41

Post by turtle4 »

arnarbi wrote: post #18
tocomment wrote: post #4

He mentions not checking the env directory into git. Why not? In general what are the best practices for using virtualenv with version control?

I find it best to keep virtual envs completely away from the project (I use http://virtualenvwrapper.readthedocs.org/en/latest/ which puts them by default in ~/.virtualenvs). A virtualenv is completely machine-specific. If your project is a package itself (i.e. it has a setup.py file), then use that file to specify dependencies. On a new machine I check out a copy, create a virtual env and activate it. Then in the lo…

Alright, so after I set up the environment using pip and virtualenv, I see it has python in it, etc. If I use pip freeze > requirements.txt, it lists the packages I have installed using pip, but it doesn't list anything for the python version itself. How do I make sure the right python version gets captured if I don't check in the /env/ folder?

Re: A non-magical introduction to pip and virtualenv for Python beginners

#42

Post by metaphorm »

Pxtl wrote: post #20

VertualEnv seems less like a brilliant tool than it does a workaround for an architectural problem in Python and pip. That said, dependency hell is always tricky, and I've had to deal with some far uglier solutions in other platforms.

it is a brilliant tool in that its an incredibly easy to use and lightweight solution to an otherwise very annoying problem.

you might call it a workaround because its not the most elegant solution possible, but it still just works really well, so why complain?

Re: A non-magical introduction to pip and virtualenv for Python beginners

#43

Post by metaphorm »

mkoryak wrote: post #24

Can someone explain the historical reasons for this problem even existing in the first place? (the problem that virtual env solves)

the problem is that different applications might require different versions of the same packages. if you install packages globally then you can only ever have one version available. this is a VERY BAD THING if you have any expectation of running more than application per machine.

Re: A non-magical introduction to pip and virtualenv for Python beginners

#44

Post by turtle4 »

HeyImAlex wrote: post #9
netcraft wrote: post #3

a good introduction - I would like to hear more about deployment with virtualenv though - is it expected that you just document any packages with requirements.txt and then you would create the virtualenv in the deployment target and set everything up again? Or can you "package" a virtualenv for deployment?

Just generate your requirements file from your env locally (pip freeze > requirements.txt), deploy all of your files (env folder excluded) to your sever however you want and then run 'env/bin/pip install -r requirements.txt' on your server.

If I use pip freeze > requirements.txt, it lists the packages I have installed using pip, but it doesn't list anything for the python version itself. How do I make sure the right python version gets captured if I don't check in the /env/ folder?

Re: A non-magical introduction to pip and virtualenv for Python beginners

#45

Post by mixmastamyk »

JulianWasTaken wrote: post #15

> Python actually has another, more primitive, package manager called easy_install, which is installed automatically when you install Python itself. It's actually not, it's part of setuptools/distribute, though some Python distributions (actually just brew that I know of) include distribute alongside Python. Also, while the quick skim of the rest of this looks mostly good, there's some unnecessary advice which compli…

As I install/develop my python apps into VMs with a fixed python version, I rarely use virtualenv... don't see the need for the extra complexity.

I've eagerly read pieces like this but haven't yet found out the reason this solution is problematic or that I'm doing it wrong. Just that no one else seems to be recommending it. Anyone have an idea?

Btw, one of the best discussions of the various deployment options I've seen is from the Pylons book: http://pylonsbook.com/en/1.1/deployment.html#choosing-or-set...

One other thing I'm not happy about regarding packaging best-practices (and PyPi) is that security updates are not able to be automated leading to vulnerable packages.

Re: A non-magical introduction to pip and virtualenv for Python beginners

#46

Post by denzil_correa » 

    Python actually has another, more primitive, package manager called 
    easy_install, which is installed automatically when you install Python itself. 
    pip is vastly superior to easy_install for lots of reasons, and so should 
    generally be used instead. You can use easy_install to install pip as follows:
I found it quite ironic that the author says pip is "vastly superior" to easy_install and then proceeds to install pip using easy_install.

Re: A non-magical introduction to pip and virtualenv for Python beginners

#47

Post by mixmastamyk »

Daiz wrote: post #37

Man, global system-wide installations that require admin rights by default? That's certainly something! Quite the stark comparison to Node.js and npm, where everything is installed locally into the current directory (under node_modules) by default, and "global" installation is actually a per-user installation. Tricking pip with virtualenv seems to get you pretty close to what you get by default with npm, albeit still…

    pip install --user XXX
should get you what you want. Not default but not a huge burden either.

Re: A non-magical introduction to pip and virtualenv for Python beginners

#48

Post by peterwaller »

tocomment wrote: post #4

He mentions not checking the env directory into git. Why not? In general what are the best practices for using virtualenv with version control?

Re: "Why not?"

Generally you should strongly avoid putting generated artefacts into version control. This leads to complete pain if ever you find yourself trying to diff or merge when they inevitably change. The problem is that you end up with conflicts which are completely unnecessary - you should always be able to just regenerate the virtualenv at any time.

This is especially true for non-relocatable artefacts (as others have mentioned) such as virtualenvs or compiled binaries.

Another thing is that these generated artefacts can be costly in terms of space consumed in the repository - maybe not so much for a virtualenv with one package in it, but for binaries or larger virtualenvs, these things can become quite large. In addition they're often not so friendly for git's delta compression which is better suited for textual data. You can end up unnecessarily increasing the size of your repository significantly, which is another thing best avoided.

Re: A non-magical introduction to pip and virtualenv for Python beginners

#49

Post by pirer »

JulianWasTaken wrote: post #15

> Python actually has another, more primitive, package manager called easy_install, which is installed automatically when you install Python itself. It's actually not, it's part of setuptools/distribute, though some Python distributions (actually just brew that I know of) include distribute alongside Python. Also, while the quick skim of the rest of this looks mostly good, there's some unnecessary advice which compli…

How would you someone who has used pip with sudo undo the mess that has created in his computer?

Uninstall everything and start over?

Re: A non-magical introduction to pip and virtualenv for Python beginners

#50

Post by kenny_r »

denzil_correa wrote: post #46

Python actually has another, more primitive, package manager called easy_install, which is installed automatically when you install Python itself. pip is vastly superior to easy_install for lots of reasons, and so should generally be used instead. You can use easy_install to install pip as follows: I found it quite ironic that the author says pip is "vastly superior" to easy_install and then proceeds to install pip u…

It's similar to using Internet Explorer to download Chrome or Firefox.
Post reply on HN