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

71–80 of 86 posts

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

#71

Post by hcarvalhoalves »

turtle4 wrote: post #41
arnarbi wrote: post #18

Earlier quoted context omitted.

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?

> How do I make sure the right python version gets captured if I don't check in the /env/ folder?

Document it in setup.py:

    if sys.version_info
You're using setup.py, right? ;)

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

#72

Post by elithrar »

HeyImAlex wrote: post #16

Want to make life even easier? Check out virtualenvwrapper. http://virtualenvwrapper.readthedocs.org/en/latest/ Lots of benefits, but trading 'cd path/to/my/project && source env/bin/activate' for 'workon project_env' (with autocomplete) is alone easily worth the five seconds it takes to check it out.

> Lots of benefits, but trading 'cd path/to/my/project && source env/bin/activate' for 'workon project_env' (with autocomplete) is alone easily worth the five seconds it takes to check it out.

And/or use the virtualenvwrapper plug-in for oh-my-zsh. Automatically activates virtualenv when you cd to the working directory.

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

#73

Post by e12e »

Daiz wrote: post #61
tomku wrote: post #60

Earlier quoted context omitted.

npm's default for -g is to install to Node's prefix, which is usually /usr or /usr/local. If you want it to install to your home directory, you can set the prefix to somewhere appropriate in your ~/.npmrc, which gives roughly the same behavior as pip's --user flag. Edit: perhaps you changed your .npmrc or set the option via npm and forgot about it? I just checked on a fresh user, and 'npm install -g' definitely tries…

I use Windows as my main OS, and by default npm -g installs packages to %AppData%, which is user-specific. I guess it's different on *nix, then.

That sounds broken to me. Then it's no longer -g for global. You do run your app under a different account than your user-account, right? Something like "nodeuser"?

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

#74

Post by grosskur »

turtle4 wrote: post #41
arnarbi wrote: post #18

Earlier quoted context omitted.

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?

Heroku allows specifying the Python version in a file called runtime.txt, which is analogous to requirements.txt:

   https://devcenter.heroku.com/articles/python-runtimes
I think this works well as a convention even if you're not deploying to Heroku. I also like the suggestion to put a guard in setup.py that checks sys.version_info.

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

#76

Post by randuser »

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)

setuptools/distribute didn't implement `python setup.py uninstall`.

Unix fragmentation of where the bin and lib directories should reside, i.e. /bin, /usr/bin, /usr/local/bin, ~/bin, ...

Windows doesn't have symlinks and the different packaging tools have tried to implement the functionality in various different ways.

Python doesn't add the path of the "main" executed file to the module lookup path. (edit: actually, I think this is wrong. I meant to say "Python module import lookup is complicated.")

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

#77

Post by tootie »

tbatterii wrote: post #28
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.

you aren't implying that dependency hell is a problem unique to python/pip are you? dealing with dependencies is always step 2 for me when learning a new language and dependency hell seems like a universal problem. I could be wrong though.

Honestly, Maven is way easier, more powerful and works identically on Win, Linux or Mac. The key is that Java let's you set classpath as a command line arg and pythonpath is an environment variable.

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

#78

Post by tbatterii »

tootie wrote: post #77
tbatterii wrote: post #28

Earlier quoted context omitted.

you aren't implying that dependency hell is a problem unique to python/pip are you? dealing with dependencies is always step 2 for me when learning a new language and dependency hell seems like a universal problem. I could be wrong though.

Honestly, Maven is way easier, more powerful and works identically on Win, Linux or Mac. The key is that Java let's you set classpath as a command line arg and pythonpath is an environment variable.

IMO, buildout is more like maven for python. but again the tools solve this problem of "dependency hell" which to me is a problem all languages have, not just python

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

#79

Post by yew »

Speaking as someone relatively new to Python (coming from an embedded development background, mostly with C/C++): What's the standard way of distributing client-side programs/libraries? If you only have one script you can just put it in /usr/local/bin/ but otherwise you have to mess with the system site-packages or modify sys.path before importing, right? I've seen a surprisingly large number of distros that didn't check /usr/ and /usr/local/ for packages.

Do you just hand the user an automatic virtualenv script? (Outside of using one of the binary builders out there, obviously.)

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

#80

Post by pirer »

jyap wrote: post #55
pirer wrote: post #49

Earlier quoted context omitted.

How would you someone who has used pip with sudo undo the mess that has created in his computer? Uninstall everything and start over?

Yeah. You can use 'pip uninstall'.

I ended doing the following for those who are in the same situation:

    pip freeze > pip_list_with_sudo.txt
    sudo pip uninstall -r pip_list_with_sudo.txt
So now let's start doing things right with virtualenv...
Post reply on HN