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?
The easy way to remove a virtual environment is to delete the directory. Mingling project files with the virtual environment means you must first disentangle the two. Multiple projects may use the same virtual environment.
In short: Rather than having a venv directory inside or alongside your project directory, virtualenvwrapper keeps all your environments in one place: ~/. virtualenvs by default. It provides commands for creating and activating environments easily, and the activation doesn't rely on locating the right activate script.
A virtual environment is a tool that helps to keep dependencies required by different projects separate by creating isolated python virtual environments for them. This is one of the most important tools that most of the Python developers use.
This is really simple. Start by changing directory into the root of our project directory, and then use the virtualenv command-line tool to create a new environment: $ mkdir myproject $ cd myproject $ virtualenv env New python executable in env/bin/python Installing setuptools, pip, wheel... done.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With