I don’t grok virtualenvs, but got tootstream installed with workon (a virtualenv wrapper), and then modified that script with my own local values and launch the program like that.
But I don’t understand what is happening, I don’t quite know what makes that go in and out of a virtualenv so easily. I need to know!
I mention this because I have suspicions as to why their being used but they make my head hurt when I think about packaging the software more formally. Like I tried seriously hard to get tootstream into pkgsrc on netbsd and gaveup because deploying it without a virtualenv was so undocumented and unsupported at the time. (This may have changed not up to date on tootstream development.)
I have a basic understanding of virtualenvs, in essence a virtualenv is a directory where all the dependencies of your python project go. And by dependencies, we mean things like:
any pip-installed packages
any C headers or source files those packages depend on
documentation for those packages
the pip executable itself
the python executable itself
other runnable programs or scripts installed packages might create
So virtualenvs let you take all that stuff and stick it in a per-project directory. This lets you not have to deal with the hassle of keeping these dependencies straight between projects had you installed these things globally.
What does activate do then?
Basically, it monkeys around with your $PATH and sets up some aliases to make using the virtualenv easier and save you some typing. Rather than saying /path/to/virtualenv/bin/pip install django you can just pip install django, and so on.
What does deactivate do?
The opposite of activate! Sets your path back to the oringal values, unsets those aliases, etc. etc.
What does virtualenvwrapper do?
virtualenv is a complex tool with many flags and modes of operation. virtualenvwrapper wraps it up so that the defaults most people want are available with just a simple invocation of mkvirtualenv <name of env>.
It also places all these virtualenvs in one directory (usually either ~/virtualenvs or ~/.virtualenvs) and provides another script workon that lets you activate a virtualenv by name, rather than with source /path/to/virtualenv/bin/activate.
It surprises me how difficult this was! Many projects that develop using virtualenv tend to deploy with virtualenv as well (we do at Dark Horse), but as long as you have the correct version of python installed, it should work just fine if you pip install -r requirements.txt so that the packages are installed globally.
I say that with all the hubris of never having attempted to do so with tootstream of course
Well that goes most of the way to answer this. I meant to make a checklist/guide explaining this to myself when I infrequently use it.
Also, would be nice to have a brief explanation for all the different scripts, as they all live in different places and no one explains that well enough for a beginner.
These are my notes for producing the document that completes this quest.
Do you have examples of the scripts you’d like descriptions of? There’s certainly a number involved in the operation of virtualenvwrapper, but I was wondering if there were others you were thinking of?