I was trying to use virutalenv in windows but there is something odd that I barely understand about the directories structure.
When you create a new virtual environemnt it creates for you the following structure:
C:\Projects\djang_venv\
Include\
Lib\
pip-selfcheck.json
Scripts\
tcl\
If I want to work on my django project where should I put my project, in the django_vent directory ?
C:\Projects\djang_venv\
django_site\
Include\
Lib\
pip-selfcheck.json
Scripts\
tcl\
It's not looking right, like something is messy here.
Where should I put my application when I create a virtual environment ?
Found out that someone already asked the same question
And actually one of answers (Not the accepted one) was a very informative and clear (Will include his answer in my conclusion)
This is what I understood from the research I did on virtual environments world in Python:
First of all, it's a matter of opinion. But it is important to note that the experience of the people should be considered, because it is possible to know which method is more appropriate to choose, since the guys with experience understood which method was not good over time.
If you want to stick with virtualenv, one of the solutions keep your directories structure pretty clean outside, Projects directory will stay organized. Put all the virtual environments into one folder, and name each of them after the project you are working on:
c:\projects\virtualenvs\
django_site\ <-- Virtual environment for Django project
flast_site\ <-- Virtual environment for Flask project
c:\projects\django_site\ <-- Django project
c:\projects\flask_site\ <-- Flask project
But it's a bit messy with the source command:
cd /django_site
source ../virtualenvs/django_site/bin/activate
To get the most organized environment, without any headache about the order of the virtual environments directories, there is a wrapper for virtualenv called (surprisingly) virtualenvwrapper. All the virtual environments are stored away from you in your HOME_USER directory, for me it's c:\users\my_user\.virtualenvs. And you get great shortcuts by the package, like mkvirtualenv which creating for you a virtual environment no matter where are you in the file system, then you can switch between the virtual environments with the shortcut workon, Some examples:
$ mkvirtualenv flask_site
New python executable in c:\users\usr\.virtualenvs\flask_site\Scripts\python.exe
Installing setuptools, pip, wheel...done.
(flask_site)$ workon
flask_site
(flask_site)$ mkvirtualenv django_site
New python executable in C:\Users\Emilman\.virtualenvs\django_site\Scripts\python.exe
Installing setuptools, pip, wheel...
(django_site)$ workon
django_site
flask_site
(django_site)$ workon flask_site
(flask_site)$
Actually after checking all the options, I've chosen the virtualenvwrapper. great solution for virtual environments world in Python.
Related
I created venvs for couple diff projects using python3 -m venv my_project
Also use pyenv local version for managing the python version for each project as needed.
My projects folder looks like this:
my-project-one/
my-project-two/
my_project_one/
my_project_two/
The ones with hypens are the repo while the ones with underscores are the venv I create for them. (maybe stupid naming scheme but works for me).
I activate the venv with source ../my_project_one/bin/activate from within the one I want to work with.
It has been great since I was using VSCode. Now I want to use Pycharm and I can't figure out how to make venv work with Pycharm.
In the project interpreter section I can see the two versions under ~/.pyenv/versions/ but that doesn't detect the project dependent requirements I have installed on the venv.
Many articles mentions about adding the python executable unders Scripts folder in venv but there is no such folder in any of mine. (on MacOS)
What am I missing here? Did I create the venv incorrectly or following the instruction for the wrong implementation of virtual env because I really don't want to mess with a working setup just for Pycharm.
I hope it would at the very least detect the project level libraries and not show unresolved reference for them.
been searching for this with no success, i don't know if i am missing something but i have a virtualenv already but how do i create a project to associate the virtualenv with, thanks
P.S. Am on windows
I could be wrong here, but I do not believe that a virtualenv is something that is by its very nature something that you associate with a project. When you use a virtualenv, you're basically saying, "I'm taking this Python interpreter, installing what I want on it, and setting it aside from the Python interpreter that the entire computer uses by default." Virtualenv does not have a concept of a Python "project"; it is just a custom version of a Python interpreter that you run code through. There are tools in IDEs like PyCharm that enable you to associate a project with a virtualenv, but those are another layer on top of the base software.
In order to use a virtualenv with a project, you will need to "activate" it every time you wish to use it. The documentation for activating a virtualenv on Windows is found here.
EDIT:
Saw that you had virtualenvwrapper tagged in your post, so I did a bit of hunting on that. It would appear that there is the mkproject command, which creates a project folder and then associates it with a virtualenv interpreter. Documentation on it can be found here.
Requirements:
Virtual Env
Pycharm
Go to Virtual env and type which python
Add remote project interpreter (File > Default Settings > Project Interpreter (cog) add remote)
You'll need to set up your file system so that PyCharm can also open the project.
NOTE:
do not turn off your virtual environment without saving your run configurations that will cause pycharm to see your run configurations as corrupt
There's a button on the top right that reads share enable this and your run configs will be saved to a .idea file and you'll have a lot less issues
If you already have your virtualenv installed you just need to start using it.
Create your projects virtual environment using virtualenv env_name on cmd. To associate a specific version of python with your environment use: virtualenv env_name -p pythonx.x;
Activate your environment by navigating into its Scripts folder and executing activate.
Your terminal now is using your virtual environment, that means every python package you install and the python version you run will be the ones you configured inside your env.
I like to create environments with the names similar to my projects, I always use one environment to each project, that helps keeping track of which packages my specific projects need to run.
If you haven't read much about venvs yet, try googling about requirements.txt along with pip freeze command those are pretty useful to keep track of your project's packages.
I like Pipenv: Python Dev Workflow for Humans to manage environments:
Pipenv is a tool that aims to bring the best of all packaging worlds (bundler, composer, npm, cargo, yarn, etc.) to the Python world. Windows is a first-class citizen, in our world.
It automatically creates and manages a virtualenv for your projects, as well as adds/removes packages from your Pipfile as you install/uninstall packages. It also generates the ever-important Pipfile.lock, which is used to produce deterministic builds.
Pipenv is primarily meant to provide users and developers of applications with an easy method to setup a working environment.
Hi I've been reading a lot about virtual environments but I don't seem to get one thing.
So I have my path like this:
../my_app/
../my_app/app.py
..etc
Where should I put the virtual environment?
Inside my_appas /my_app/venv/bin,include,lib?
or at the same level as my_app
/my_app/
/venv/
I don't understand if the location matters or if by using activate it will reference it instead of going to the main environment.
I hope this question makes sense.
Thanks!
I recommend utilizing the root directory which virtualenv creates as the root directory for your source files. Virtual-envirments are designed to be tied to a project, not shared between different projects. Example, lets say I write a lot of code in my ~/school directory. I'd cd to ~/school, do virtualenv ENV. Now I have an ENV directory in which to keep my source files and dependencies for the project. So you can create a ~/school/ENV/source folder in which to keep all your source folders. And all your virtual-environment files are close to your program, easily accessible in the ENV directory.
EDIT:
To address one part of your question: As long as you keep track of your environment, and you source bin/activate before running your python programs and installing dependencies with pip, you can install your virtual environment anywhere.
I don't understand if the location matters or if by using activate it
will reference it instead of going to the main environment.
It doesn't matter, as activate will take care of the paths correctly, but you shouldn't put your virtual environment in your source, as it is not part of your application (and its not portable). Instead, create a file with your requirements and put that under your source control.
You should put it in any directory other than your source code. The activate script will make sure the paths point to the right places.
Here is an example:
$ virtualenv /home/somedir/envs/myenv
... # some output
$ source /home/somedir/envs/myenv/bin/activate
(myenv) $ mkdir /home/somedir/projects
(myenv) $ cd /home/somedir/projects
(myenv) projects $
As you can see, the virtual environment is in the envs directory and is called myenv. Your source is in /home/somedir/projects. Type deactivate to exit your virtual environment.
In other words, what's the difference between the mkvirtualenv and mkproject commands?
I have a workflow that looks like this:
/dev
projectA
appA
appB
projectB
appA
appB
All of the apps share some resources (like South, pep8, etc.), but other resources are specific to each app. Should I be using virtualenvwrapper "projects" to keep these dependencies separated?
From my understanding of the documentation, mkvirtualenv projectenv simply creates a new virtual environment named projectenv in $WORKON_HOME, while mkproject projectenv creates a new virtual environment named projectenv and a new directory named projectenv; after creation, the projectenv directory automatically becomes your current working directory. The virtual environment will exist in $WORKON_HOME and the development directory exists in $PROJECT_HOME.
Note, formkproject to work correctly, you must first set the environment variable PROJECT_HOME to the name of the directory where you would like projects to be created. You can do this in the same place you set your $WORKON_HOME variable or set it up on the fly, e.g.
export PROJECT_HOME=$HOME/src/allprojects
mkproject mynewproject
mynewproject will now be your current virtual environment and a new mynewproject directory will exist in ~/src/allprojects.
mkvirtualenv is command from virtualenvwrapper that makes managing python virtualenvs easier, while mkproject comes from a virtualenvwrapper plugin to manage your projects (that was integrated directly into virtualenvwrapper)
the plugin page mentions the following features:
Manages your development project work directories along with your
virtualenv environments. Defines an API for creating templates to
quickly create new environments consistently. Use workon command from
virtualenvwrapper to switch between projects. User-configurable hooks
for customizing new projects.
You don't have to create or manage your projects using the virtualenvwrapper plugin to use the virtualenv commands. It's just a convenience plugin for stuff like swapping to the project directory when issuing a workon command, or from creating new projects from templates.
virtualenv for itself has no library sharing capability except with the systems site-packages if you use the correct flag. I stumbled once over a project that gave you this ability among other things, but never found it again.
EDIT: virtualenvwrapper now has the functionality to copy virtualenvs, and to add directories to your virtualenv PATH in order to share libraries.
I'm new to pyramid and paster, just reading the docs for now. I use virtualenv and inside the virtualenv dir I want to start a pyramid project. The problem is that I would like for paster to not create a dir with the project name, and instead put all the scaffold files on the current dir (the venv root).
I thought about just not using paster but I still wouldn't know how to point to my app on development.ini "use" option.
I could also have my virtualenv on an entirely different place of my filesystem, but that seems weird to me (maybe virtualenvwrapper could make it easier). Any other way to do this?
It is confusing at first but your code really doesn't need to be in your virtual environment directory at all. Actually it's better not to put your code inside your environment, as you might want to use different environments with the same code, for example to test your code with different versions of Python or different versions of a library.
virtualenvwrapper does put all your environments in a single place. virtualenvwrapper is a convenient tool on top of virtualenv but you don't need it to put your code and your environments in different places. Maybe you should get a bit more comfortable with virtualenv itself before starting to use virtualenvwrapper.
You should let paster create a directory with the project name. This is the directory that you will commit in version control (eg. git, mercurial...). You don't want to commit the directory containing the virtual environment.
This is really just bike shedding because how you create the project and the virtualenv are irrelevant and you can place either of them anywhere, including within each other.
However, if you really want to, you can paster create -t pyramid_starter -o .. <current_directory_name> to create the project within the current directory.
To create a new project:
cd ~/work/my_repo
virtualenv --no-site-packages env
env/bin/pip install pyramid
env/bin/paster create -t pyramid_starter -o .. my_repo
git init
echo 'env' > .gitignore
git add .
I'll usually do this when setting up a new machine:
cd ~/work
git clone /path/to/<my repo>.git
cd my_repo
virtualenv --no-site-packages env
env/bin/pip install -e . # equivalent to env/bin/python setup.py develop
Using the setup I just mentioned, you'd want to add the env directory to your .gitignore file.