Explore how launching virtualenvs work

To launch tootstream, I use a bash script based on Craig’s:

#!/bin/bash
source /home/maiki/.virtualenvs/tootstream/bin/activate
python3 /home/maiki/.virtualenvs/tootstream/bin/tootstream $@

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! :slight_smile:

Did you ever grok virtualenvs @maiki ?

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.)

1 Like

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 :slight_smile:

2 Likes

The trick with pkgsrc is not to install the dependencies without pip! Whiel I was not too too familiar with virtualenv or python in the first place.

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. :slight_smile:

1 Like

I would like this.

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?

danr-laptop:tfaw danr$ ls ~/.virtualenvs
get_env_details		postdeactivate		postrmvirtualenv	premkproject
initialize		postmkproject		preactivate		premkvirtualenv
postactivate		postmkvirtualenv	predeactivate		prermvirtualenv

This is a listing that I could go in-depth on that are directly related to virtualenvwrapper, for instance.

I haven’t gone this in-depth before, but I’d certainly like to :slight_smile: