econchick / new-coder

New Coder tutorials
zlib License
597 stars 394 forks source link

Setting up your computer: virtualenvwrapper LInux All #162

Open awong5 opened 9 years ago

awong5 commented 9 years ago

During the set up, it states to save both:

  1. 'export WORKON_HOME=~/Envs' >> ~/.bash_profile
  2. 'source /usr/local/bin/virtualenvwrapper.sh' >> ~/.bash_profile

to the bash_profile file at virtualenv & virtualenvwrapper stage but it did not work for me on Linux.

I found that by saving them to bashrc file worked for me.

merwok commented 9 years ago

Hello, thanks for reporting this problem.

Instead of changing from bash_profile to bashrc, I think it would be best to improve the doc to explain that bash_profile is sourced at startup, which explains why venvwrapper won’t work even in a new terminal right after changing your bash_profile. If you don’t want to restart your X session right now, you can just source ~/.bash_profile and go ahead.

econchick commented 9 years ago

:+1: thanks @merwok good suggestion

katieirenec commented 9 years ago

Hi @merwok, I helped a lot of students go through the installation steps last week, and this was a common issue for those running Ubuntu. To get some more clarification, based on what you're saying, should students be able to successfully install virtualenvwrapper after following the steps as currently listed, including sourcing ~/.bash_profile?

$ sudo pip install virtualenvwrapper
$ export WORKON_HOME=~/Envs
$ echo 'export WORKON_HOME=~/Envs' >> ~/.bash_profile
$ echo 'source /usr/local/bin/virtualenvwrapper.sh' >> ~/.bash_profile
$ mkdir -p $WORKON_HOME
$ source ~/.bash_profile

From my experience, these steps were not successful. However, using the ~/.bashrc led to success.

As a side note, on the Ubuntu versions I saw, /etc/bash_completion.d/virtualenvwrapper was not the path where pip installed virtualenvwrapper. It was in the same path as indicated for Fedora: /usr/local/bin/virtualenvwrapper.sh

merwok commented 9 years ago

Yes, the steps you listed are what I suggested (except for “sudo pip”, which I would not recommend, but that’s another matter :). I’m baffled that adding envvars to a file and sourcing it would work if it’s bashrc and not bash_profile; they’re both shell scripts that are sourced, only their name and default usage are different.

About your side note, the virtualenvwrapper file is installed under /etc/bash_completion.d when virtualenvwrapper is installed with the system package manager (APT), whereas pip puts it in /usr/local/bin.

awong5 commented 9 years ago

I believe that both 'export WORKON_HOME=~/Envs' and 'source /usr/local/bin/virtualenvwrapper.sh' should be written to bashrc and not bash_profile because when a terminal is opened from the desktop, it reads the bashrc file and not the bash_profile.

By putting both 'export WORKON_HOME=~/Envs' and 'source /usr/local/bin/virtualenvwrapper.sh' in bashrc, I do not have to source bash_profile every time I open a new terminal. i assume this is the desired set up you want.

merwok commented 9 years ago

In my previous messages, when I talked about sourcing bash_profile I meant it as a temporary measure until you restart your X session or computer. After that, bash_profile is loaded automatically.

That said, the doc for virtualenvwrapper do mention bashrc, and looking at my own config I see that it’s what I use :‑) I put generally useful environment variables in bash_profile (e.g. PAGER, BROWSER), so that all programs can see them, but the virtualenvwrapper features only work in an interactive shell, so .bashrc is the good place to put them, and the PR should be accepted.

@katieirenec do you think the PR should be edited to mention the two possible locations of virtualenvwrapper.sh? (although the paragraph about Debian/Ubuntu setup also uses pip, but shows the file as installed under /etc/bash_completion.d, which I think only happens when installing with APT)

katieirenec commented 9 years ago

Hi @merwok, apologies for late response, I was at a conference.

In my opinion, since the tutorial only mentions pip, we should go with that file path for both (or rather, for all versions of Linux). Whether you want to do that in this PR or as a separate PR I'll leave to you.

merwok commented 9 years ago

I think the same.