Should I create a directory in my virtualenv and save the source code for that specific project there?
Thanks in advance
You're not required to have them related in any way. As long as your env is activated, it doesn't matter where it is.
But what's usually easiest is:
Create an empty directory for your project.
Create the virtualenv under that project directory.
Put the source in a src directory under that project directory (or, for really simple projects, just drop it in the project directory).
That way you can check the env settings into version control alongside your code, and if you use an auto-venv tool it'll activate the env every time you cd into the project directory, and so on.
As a side note, if you're just learning this stuff today, you might want to consider learning pipenv instead of using raw virtual environments.
You can save your project anywhere. But you should activate the virtual environment before working on that project.
You can activate the virtual environment using the following command.
source path-to-virtualenvironment/bin/activate
After activating the virtual environment move to your project location.
Related
I am using Pycharm Community Edition 2019.2.. I imported a Python project from another computer. I just copied the files and then created a new project the directory. There are multiple modules that are imported in this project that I have not installed on my computer. I want to know what is the best way to automatically manage all the dependencies of this project.
I created a virtual environment(venv) in the original project. Can you export this somehow? Is this even the right path to solve this problem? The virtual is supposed to manage dependencies, though I haven't read anything about exporting settings, it mostly about isolating dependencies and settings. I've been looking at conda and pipenv as well, but I focusing on virtual environment before I try to go laterally in problem solving.
I've just installed virtualenv and virtualenvwrapper on my computer. Now I want to use it to work with Django. When I run mkvirtualenv django, from ~, the interpreter stays there. Does that mean I can create my django files there? Or is the environment not that virtual? Should I create my own folder instead where I work on the project? I thought mkvirtualenv would create one for me automatically and take me there upon running workon, otherwise, what's the point of even using virtualenvwrapper?
EDIT: These few lines from my .bash_profile might help you:
export WORKON_HOME=$HOME/.virtualenvs
export PROJECT_HOME=$HOME/Devel
source /usr/local/bin/virtualenvwrapper.sh
virtualenwrapper will create the virtualenv in your ~$WORKON_HOME/ directory. This is the venv only and is distinct from any associated "project" directory you might (or not...) want to use and which virtualenvwrapper will indeed not create.
IOW, at this point you are exactly in the same directory as when you ran the mkvirtualenv command.
If you want to associate this venv to a project directory, you have to create this directory (if it does not exist yet), and then - with your venv activated - run setvirtualenvproject /path/to/your/projectdir (or cd /path/to/your/projectdir and here run setvirtualenvproject without argument).
Once done with this, next time you activate your venv with workon myenv, you will be automagically cd'ed to your project directory too, and the cdproject command will bring you back there if you cd elsewhere.
As for other reasons to use (or not) virtualenwrapper, you can read the doc and find out by yourself what other features it adds to the raw virtualenv and whether you want those features or not.
FWIW the behaviour you expected (creating both the venv AND the project dir) is given by the mkproject command
The main advantage of virtualenvwrapper is the separation of your environment from a specific working directory. Just activate your environment with:
workon django
The prompt should change to:
(django)
Now you are free to work from any directory you want.
I have a dilemma setting up a local development projet structure. Here is my setup:
Python 2.7
Django 1.9
Mac OSX El Capitan 10.11
MySQL 5.7
I made a "Mistake" of setting my project globally instead of in a virtual environment (using 'pip' to install everything in />). After reading this article I still don't get all the steps. Is this correct:
I install global python ( pip, virtualenv in '/>' )
I then go to a location where my projects will reside, like /users/user/documents/projects/project1 and from within 'project1' I use 'virtualenv' to create a virtual environment for this project (this creates a /virtual env/ folder inside /project1/ folder)
activate this virtual environment and pip install django
then from within newly created /virtual env/ folder I startprojectwhich creates another /project1/ folder within /virtual env/ folder
with virtual environment still activated in the current shell session, I proceed with creating my scripts, site and app files
Ad 2. should the virtualenv folder be INSIDE the main "project1" folder or should it encompass it?
Ad 4. Is this correct or can I do it without activating virtual environment first?
My structure currently looks like this (starts from the root: /users/myUser/documents/projects/):
/project1/
/website1/
/static/
/templates/
__init.py__
settings.py
urls.py
views.py
wsgi.py
Common solution is to keep virtual environments and projects in separate folders, e.g. have /users/myUser/.venvs for virtual environments and /users/myUser/documents/projects/ for projects. In other aspects you got it pretty much right yourself. So:
You need to install global Python and virtualenv.
Create directoriy for virtual environments, e.g. run mkdir /users/myUser/.venvs.
Create the virtual environment for your project, virtualenv /users/myUser/.venvs/project1_venv.
Activate the environment for your current shell session /users/myUser/.venvs/project1_venv/bin/activate.
Install django and anything else in this environment pip install django, or better use requirements.txt file to keep track of all project dependencies.
Deactivate the environment, run deactivate.
Now when you'll want to run your project using created virtual environment, in your console window run /users/myUser/.venvs/project1_venv/bin/activate and then python /users/myUser/documents/projects/project1/manage.py runserver. You can activate the venv from any directory, it's activated for current shell window and any python ... run in that window after activation will use this virtual environment. The activation script modifies environment variables in a way, so that the interpreter and libraries from venv are used instead of global ones. (Though there are options to use global ones too.)
It doesn't really matter where you store your virtual environment. Find a project structure that works for you.
I wouldn't put the virtual env inside the project, because you shouldn't check it into version control (although you could use an ignore). Normally, you just need to check in your requirements file, so that you can recreate the environment.
I wouldn't put the project inside the virtual env, because virtual envs are disposable. You might want to destroy the virtual env without destroying the project. Also, you might want to run the same project under different virtual envs e.g. test your code on Django 1.8 and 1.9 before upgrading.
You might find virtualenvwrapper useful. It has some tools that make it easy to create and switch between virtual environments. It stores all of your virtual environments in one place, so you don't have to worry about where to put them.
Is this correct or can I do it without activating virtual environment first?
You should activate the virtual environment and install django before you create / work on your project.
I'm embracing VirtualEnvWrapper - and like what I see a lot. However as I try to get going I'm not seeing the behaviour I expect when trying to set up project directory association with virtual envs.
I've installed virtualenv and -wrapper. I can create envs and "workon" lists them fine. I can deactivate and rm them happily. So all appears functional. I read the docs regarding project mgmt. (Also a good video tutorial, and the desired proj association behaviour explained at 10:39 )
When I try to associate a work directory with an env, it accepts my cmds fine, but when I "workon" the project, it does not put me into my designated working directory.
e.g. I have a working area ~/Ross_code (and I've set this in my .bashrc as $PROJECT_HOME). In there is an existing project folder ~/Ross_code/superproj
So now I create an env with
mkvirtualenv superp
Then I go to my existing project dir and associate it with the env:
cd ~/Ross_code/superproj
setvirtualenvproject
Setting project for superp to /Users/ross/Ross_code/superproj
Then I exited the virtual env with "deactivate" and reactivated with
workon superp
But the present working dir remains my ~/ folder.
I checked the .project file which seems to have been set properly by the call to setvirtualenvproject:
cdvirtualenv
more .project
/Users/ross/Ross_Code/superproj
but calling "workon" never sticks me into the expected spot. I thought maybe the env and the project directory needed to be of the same name, but that didn't make any difference either.
Any idea why that very attractive project association capability doesn't work for me?
-Ross.
LATER - More info:
I tried to also use the mkproject command, which should create a directory for my code in the $PROJECT_HOME area, and create the virtualenv at the same time and associate them with each other.
Calling
mkproject junkproj
does in fact create the project directory nicely, and sticks me into the virtualenv, and cd's into the junkproj directory. But when I deactivate, and then "workon junkproj" again, I'm still left in my ~/ directory, rather than going into the project directory in $PROJECT_HOME
:(
The problem here is that the newer versions (this hit me upgrading from ubuntu 14.04 to 16.04) of virtualenvwrapper use a slightly different protocol for the setvirtualenvproject parameters:
setvirtualenvproject [virtualenv_path project_path]
In order to make the association you want in any virtual env, be in the project folder and the virtualenv and use:
setvirtualenvproject $VIRTUAL_ENV .
The dot is for the present directory - or you can use the path of the directory you want workon to take you to. Once you do this workon will switch you to the folder you want and cdproject will work as expected.
If you used the old protocol, you'll have a .project file in your project folder - you can move this to the $VIRTUAL_ENV folder rather than invoking the command with the new protocol to make the association. The file just contains the project directory you want to associate with virtualenvwrapper shortcut commands like workon and cdproject.
workon doesn't auto change directory to project or environment directory.
You can do this with the postactivate script - there's a really quick how-to in the second half of the virtualenvwrapper tips and tricks section.
I'm on a mac, and I know that any package I install goes to a specific folder in something like /Library/....
Now when I create a virtual environment, will it create a folder structure to store any libs underneath the virtual environment to isolate things?
e.g.
/home/user/mypythonvirtenv
/home/user/mypythonvirtenv/python2.6/....
Does it re-map the python environmental variables temporarily also?
Yes. Virtualenv will make you a directory tree that looks like:
mypythonvirtualenv/bin
mypythonvirtualenv/include
mypythonvirtualenv/lib
mypythonvirtualenv/lib/python2.6
mypythonvirtualenv/lib/python2.6/site-packages
When you want to use it, you source the activate script:
euclid:~ seth$ which python
/opt/local/bin/python
euclid:~ seth$ source /Users/seth/mypythonvirtualenv/bin/activate
(mypythonvirtualenv)euclid:~ seth$ which python
/Users/seth/mypythonvirtualenv/bin/python
Other python related stuff (such as easy_install) will also work the "right" way.