If you’re doing any development in Python, odds are you’re using virtualenv. And if you’re using virtualenv, odds are you’re using virtualenvwrapper. I came up with a few tricks to make my life easier, and I thought I ought to share them. And as a disclaimer: although I am obsessed with discovering best practices, these are definitely not. So I’m adding a new category called “Meh Practices”.<\/p>\n
$IPYTHONDIR<\/code> environment variable.<\/h2>\nAccording to the IPython documentation<\/a>, IPython stores settings in a profile, and it looks for that profile in $IPYTHONDIR<\/code>. So in my global virtualenv postactivate, I have:<\/p>\nexport IPYTHONDIR=$VIRTUAL_ENV\/.ipython\n<\/code><\/pre>\nNow why would anyone want a separate profile for every virtualenv? I do this so every virtual’s IPython gets its own history database. I also used to run IPython 0.10.X and 0.11.X side by side, and the two had incompatible profile formats. All my tools support the new IPython so this isn’t an issue for me anymore, but I still do it for the separate history.<\/p>\n
Maintain the same IPython configuration for every profile<\/h2>\n
Because now I’m running around with N IPython profiles with N configurations when I really only want 1 configuration, I symlink all the profile configurations from a master one I keep in source control. The gist of it looks like:<\/p>\n
DST=$IPYTHONDIR\/profile_default\nSRC=$HOME\/.dotfiles\/.ipython\/ipython_config.py\nmkdir -p $DST\ncd $DST\nln -s -f $SRC\n<\/code><\/pre>\nBut my actual one currently looks like this<\/a> and I run it in my global postmkvirtualenv, which now looks like:<\/p>\nIPYTHONDIR=$VIRTUAL_ENV\/.ipython\nmkipythonconfig\n<\/code><\/pre>\nWhere mkipythonconfig<\/code> is the snippet above.<\/p>\nAdd an alias to maintain your environment variables<\/h2>\n
I got really sick of cdvirtualenv<\/code> then vi bin\/postactivate<\/code>, so in my postactivate, I have this line:<\/p>\nalias vivirtualenv=\"$VISUAL $VIRTUAL_ENV\/bin\/postactivate\"\n<\/code><\/pre>\nin my virtualenv’s postactivate. Now when I need to edit my postactivate, it’s a few tab complete-able keystrokes away. I stole the naming convention from visudo<\/code>, and I tried naming it vipostactivate<\/code>, but I think vivirtualenv<\/code> is just so catchy. Now if your immediately reaction is to make a comment telling me I should just use autoenv<\/a>; too bad, I already thought about that. Right now, issue#28<\/a> is preventing me from adopting autoenv. I also can’t go around adding .env<\/code> to the .gitignore of collaborated projects. And there’s one project I know of where the Procfile for foreman is not in the project root. #everythingisterrible<\/p>\nUse setvirtualenvproject<\/h2>\n
I don’t take advantage of virtualenvwrapper’s mkproject<\/code>, nor do I really know what to do with them, but there is one thing I do use from that… setvirtualenvproject<\/code><\/a>. I never use mkproject<\/code> because I rarely name my projects and virtualenvs the same, and I haven’t bothered to set up any project templates. But I am lazy, and I like how if you tell virtualenv that your current working directory is the project root using setvirtualenvproject<\/code>, every time you workon<\/code> it, you’ll automatically cd into it. But what if you don’t want that to happen? You can jump back to the directory you were just in with cd -<\/code>. For me, the extra time it takes to go back is more than made up by all the time saved not having to cd in.<\/p>\nSo putting everything together, I have a makefile<\/a> for bootstrapping a new install so virtualenvwrapper and IPython are set up the way I like. It may seem like I have to do a lot of work to get up and running, but I’ve got it down to one make<\/code> now.<\/p>\n","protected":false},"excerpt":{"rendered":"If you’re doing any development in Python, odds are you’re using virtualenv. And if you’re using virtualenv, odds are you’re using virtualenvwrapper. I came up with a few tricks to make my life easier, and I thought I ought to share them. And as a disclaimer: although I am obsessed with discovering best practices, these…<\/p>\n Read More<\/span> A few virtualenv tips<\/span><\/a>","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"Layout":"","footnotes":""},"categories":[47,4],"tags":[48,49],"class_list":["entry","author-showmewhatyougot","post-223","post","type-post","status-publish","format-standard","category-meh-practices","category-technical","tag-python","tag-virtualenv"],"_links":{"self":[{"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/posts\/223","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/comments?post=223"}],"version-history":[{"count":11,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/posts\/223\/revisions"}],"predecessor-version":[{"id":757,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/posts\/223\/revisions\/757"}],"wp:attachment":[{"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/media?parent=223"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/categories?post=223"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/tags?post=223"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}