-
-
Notifications
You must be signed in to change notification settings - Fork 400
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Virtualenv instructions in README.md #62
Comments
wat?! We're not supposed to have the virtualenv in the same dir as the cloned code?!? I know that says that in the README but is that really best practice? |
It is, see how virtualenvwrapper works. What virtualenv does is actually not complicated, but many people are confused by it, and imo this confusion leads to non-optimal patterns such as creating the venv alongside the source code. I’ll expand more later : ) |
So I had the realization just now that because of the way that I originally setup virtualenv and wrapper, it sets up the virtualenv elsewhere, in ~/.venv But yeah, you're right that the executables should not be where your git repo is. We don't want to see the bin/ dir in there. If you set up virtualenvwrapper the way that it shows you in the docs (where the actual env is in ~/.venv or some other directory), then it doesn't matter which order you do it (git clone then mkvirtualenv or vis-versa). I was just confused because I always git cloned then mkvirtualenv not even realizing that the actual venv is elsewhere. Don't judge...it's Friday. |
@merwok , I should have been explicit. Here is how I do it: Currently, this is how the 'pyladies' repo looks: This method seems cleaner and keeps my virtualenv packages and dependencies away from my code repo. Feel free to let me know if any steps need to be changed, and if you think its ok, I'm happy to include these steps in the README file. Thanks. |
The steps you describe confuse me a little. First, you don’t need to cd and source activate: mkvirtualenv will work in the defined $WORKON_HOME directory without you needing to cd there. Second, workon merely sources activates and runs post-activate hooks, so if you run it after step 3 it does nothing. Your repository does not have to (and IMO should not) be located in your virtualenv. Venvs are throw-away. I’m busy now but will write more later with links to the venv and venvwrapper docs. |
On Mon, Aug 19, 2013 at 5:00 PM, Éric Araujo notifications@github.com wrote:
While I agree that venv's are throw-away, care to explain why the repo svaksha ॥ स्वक्ष |
@svaksha it's bad to have executables in your git repo. Here's my layout:
Whenever I am about to start a project, I am within my Then I make or turn on the virtual env. The There's actually no physical relation between the $WORKON/env dir and the If I want to map a virtualenv to a project directory, I can, within the desired project dir, do |
If this still remains an issue, please reopen to discuss. |
I wanted to add a link to our Bangalore mailing list to the locations page, and came across this line in the Readme.md file "It is important that when you create your virtualenv, do not create it in the same folder as the code you downloaded."
That line was confusing as I already have a virtualenv where I create a separate directory/folder for each project (depending on 2.x or 3.x) and then clone the repo with git. So, the order gets reversed as: 3.Create a virtualenv called PyLadies, and then, 2.Clone to your machine.
However, the Readme instructions seem to suggest otherwise
The text was updated successfully, but these errors were encountered: