Patterns: bootstrapping Python/SublimeText projects

I consider myself really lazy. So here’s my basic workflow of home-grown commands I go through whenever I work on a Python project.

Some notes before I dive in:

  • replace  $PROJECT with the name of your project. I keep a consistent name between projects so I can use the directory name for other things.
  • some tedious things I alias, some I don’t
# everything has to live somewhere
# equivalent to: mdkdir $PROJECT && cd $PROJECT
# my alias: md () { mkdir -p "$@" && cd "$@"; }

# Using virtualenvwrapper, make a virtualenv the same name as the project
mkvirtualenv $PROJECT

# These next steps happen automatically in my global postactivate
# Give this virtualenv its own ipython configuration so it has its own ipython history
# change my tab title to the name of this virtualenv so I can tell my tabs apart
echo -e "\033];$(basename $VIRTUAL_ENV)\007"
# my alias: tit() { echo -e "\033];$@\007" }

# This makes it so when I `workon $PROJECT`, I automatically cd to it.
# Sometimes, this is undesirable, but `cd -` will take you back.
# likewise I have a function named `work` that activates or creates the virtualenv:
function work {
  # assumes `mkvirtualenv` exists
  local env_name=$(basename $PWD)
  workon $env_name
  if [ $? -ne 0 ]; then
    echo "Shall I create $env_name it for you? [Yn]"
    read -n 1 sure
    if [ -z "$sure" ] || [ "$sure" = 'y' ] || [ "$sure" = 'Y' ]; then
      mkvirtualenv $env_name

# create a sublime text 2 project with a SublimeJEDI configuration
mksublconfig > ~/Documents/$PROJECT.sublime-project
# source:

# Create an .env file to store configuration like DJANGO_SETTINGS_MODULE
# Works in conjunction with autoenv.
touch .env

# If I'm creating a new project, I create an empty initial commit so I can
# squash and rebase things from the beginning.
git init
git initempty
#  initempty = !git init && git commit -m 'initial commit (empty)' --allow-empty

Leave a Reply

Your email address will not be published. Required fields are marked *