Question

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?

Était-ce utile?

La solution

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.

Autres conseils

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.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top