metacon 0.0.1

data/.attic/old/sync

@@ -0,0 +1,44 @@
+#!/bin/bash
+# Just a fancy way to run rake against exactly the right Rakefile, with a
+# default WORKER_ENV always of development, and more easily pass in
+# command-line parameters to the task, etc. Meant to be symlinked to.
+#
+# ex:
+# $  do-something production blah
+# (becomes, more or less)
+# $  WORKER_ENV=production rake do-something[blah]
+
+set -e # Exit on error
+#------------------------------------------------------------------------------
+# Make sure we know exactly where the real script is so we can run from
+# anywhere. (follows sym-links etc.)
+SCRIPT_PATH="${BASH_SOURCE[0]}";
+if [ -h "${SCRIPT_PATH}" ]; then
+  while([ -h "${SCRIPT_PATH}" ]) do
+    if [[ `uname -s` == 'Darwin' ]]; then
+      SCRIPT_PATH=`readlink "${SCRIPT_PATH}"`
+    else
+      SCRIPT_PATH=`readlink -f "${SCRIPT_PATH}"`
+    fi
+  done
+fi
+pushd . > /dev/null
+cd `dirname ${SCRIPT_PATH}` > /dev/null
+SCRIPT_PATH=`pwd`;
+popd  > /dev/null
+#------------------------------------------------------------------------------
+
+RAKEFILE="${SCRIPT_PATH}/Rakefile" # Explicit to this Rakefile
+
+pushd . > /dev/null   # Save cwd & go to that rakefile's directory
+cd "${SCRIPT_PATH}"
+
+task=`basename ${BASH_SOURCE[0]}`
+if [[ "$#" > 0 ]]; then
+  worker_env=$1
+  shift
+else
+  worker_env=development
+fi
+WORKER_ENV=$worker_env rake --nosearch -f "${RAKEFILE}" ${task}[$@]
+popd > /dev/null    # Restore old cwd

data/.attic/old/test

@@ -0,0 +1,44 @@
+#!/bin/bash
+# Just a fancy way to run rake against exactly the right Rakefile, with a
+# default WORKER_ENV always of development, and more easily pass in
+# command-line parameters to the task, etc. Meant to be symlinked to.
+#
+# ex:
+# $  do-something production blah
+# (becomes, more or less)
+# $  WORKER_ENV=production rake do-something[blah]
+
+set -e # Exit on error
+#------------------------------------------------------------------------------
+# Make sure we know exactly where the real script is so we can run from
+# anywhere. (follows sym-links etc.)
+SCRIPT_PATH="${BASH_SOURCE[0]}";
+if [ -h "${SCRIPT_PATH}" ]; then
+  while([ -h "${SCRIPT_PATH}" ]) do
+    if [[ `uname -s` == 'Darwin' ]]; then
+      SCRIPT_PATH=`readlink "${SCRIPT_PATH}"`
+    else
+      SCRIPT_PATH=`readlink -f "${SCRIPT_PATH}"`
+    fi
+  done
+fi
+pushd . > /dev/null
+cd `dirname ${SCRIPT_PATH}` > /dev/null
+SCRIPT_PATH=`pwd`;
+popd  > /dev/null
+#------------------------------------------------------------------------------
+
+RAKEFILE="${SCRIPT_PATH}/Rakefile" # Explicit to this Rakefile
+
+pushd . > /dev/null   # Save cwd & go to that rakefile's directory
+cd "${SCRIPT_PATH}"
+
+task=`basename ${BASH_SOURCE[0]}`
+if [[ "$#" > 0 ]]; then
+  worker_env=$1
+  shift
+else
+  worker_env=development
+fi
+WORKER_ENV=$worker_env rake --nosearch -f "${RAKEFILE}" ${task}[$@]
+popd > /dev/null    # Restore old cwd

data/.attic/old/update_submodules

@@ -0,0 +1,44 @@
+#!/bin/bash
+# Just a fancy way to run rake against exactly the right Rakefile, with a
+# default WORKER_ENV always of development, and more easily pass in
+# command-line parameters to the task, etc. Meant to be symlinked to.
+#
+# ex:
+# $  do-something production blah
+# (becomes, more or less)
+# $  WORKER_ENV=production rake do-something[blah]
+
+set -e # Exit on error
+#------------------------------------------------------------------------------
+# Make sure we know exactly where the real script is so we can run from
+# anywhere. (follows sym-links etc.)
+SCRIPT_PATH="${BASH_SOURCE[0]}";
+if [ -h "${SCRIPT_PATH}" ]; then
+  while([ -h "${SCRIPT_PATH}" ]) do
+    if [[ `uname -s` == 'Darwin' ]]; then
+      SCRIPT_PATH=`readlink "${SCRIPT_PATH}"`
+    else
+      SCRIPT_PATH=`readlink -f "${SCRIPT_PATH}"`
+    fi
+  done
+fi
+pushd . > /dev/null
+cd `dirname ${SCRIPT_PATH}` > /dev/null
+SCRIPT_PATH=`pwd`;
+popd  > /dev/null
+#------------------------------------------------------------------------------
+
+RAKEFILE="${SCRIPT_PATH}/Rakefile" # Explicit to this Rakefile
+
+pushd . > /dev/null   # Save cwd & go to that rakefile's directory
+cd "${SCRIPT_PATH}"
+
+task=`basename ${BASH_SOURCE[0]}`
+if [[ "$#" > 0 ]]; then
+  worker_env=$1
+  shift
+else
+  worker_env=development
+fi
+WORKER_ENV=$worker_env rake --nosearch -f "${RAKEFILE}" ${task}[$@]
+popd > /dev/null    # Restore old cwd

data/.attic/old/workers_help.sh

@@ -0,0 +1,22 @@
+#/usr/bin/env bash
+
+# TODO:
+#  - cd()
+#  - adjust prompt
+#  - autocomplete
+
+export VIRTUAL_ENV_DISABLE_PROMPT=true
+
+
+function __worker_ps1() {
+  rnd=`od -N1 -A n -b /dev/random`
+  worker_type="gamer_transcode"${rnd/ /}
+  worker_env="d"
+  status="c"
+  printf "${1:-(%s/%s/%s)}" "$worker_type" "$worker_env" "$status"
+}
+
+
+
+__WORKER_PS1='$(__worker_ps1)'"$PS1"
+PS1=$__WORKER_PS1

data/.document

@@ -0,0 +1,5 @@
+lib/**/*.rb
+bin/*
+- 
+features/**/*.feature
+LICENSE.txt

data/Gemfile

@@ -0,0 +1,12 @@
+source "http://rubygems.org"
+gem "god", "~> 0.11.0"
+
+# Development dependencies
+# Including everything needed to run rake, tests, features, etc.
+group :development do
+  gem "minitest", ">= 0"
+  gem "yard", "~> 0.6.0"
+  gem "bundler", "~> 1.0.0"
+  gem "jeweler", "~> 1.6.4"
+  gem "rcov", ">= 0"
+end

data/Gemfile.lock

@@ -0,0 +1,24 @@
+GEM
+  remote: http://rubygems.org/
+  specs:
+    git (1.2.5)
+    god (0.11.0)
+    jeweler (1.6.4)
+      bundler (~> 1.0)
+      git (>= 1.2.5)
+      rake
+    minitest (2.5.1)
+    rake (0.9.2)
+    rcov (0.9.10)
+    yard (0.6.8)
+
+PLATFORMS
+  ruby
+
+DEPENDENCIES
+  bundler (~> 1.0.0)
+  god (~> 0.11.0)
+  jeweler (~> 1.6.4)
+  minitest
+  rcov
+  yard (~> 0.6.0)

data/LICENSE.txt

@@ -0,0 +1,20 @@
+Copyright (c) 2011 Joseph Wecker
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/README.rdoc

@@ -0,0 +1,166 @@
+= metacon
+=== (i.e., metacontroller)
+At the moment a very specialized ruby gem for some justin.tv / twitch.tv
+development work but might be more generalizable later. For controlling a
+complex project repository. (Where controlling = developing, deploying,
+running/supervising, branching, aggregating, etc.)
+
+== Description
+=== Context: A random walk through changing your project environment
+(while iterating/working on a single project, using mostly ruby and python as
+examples)
+
+==== -    rails, etc.
+Rails (etc.) has the concept of environments - set by the RAILS_ENV environment
+variable. When you set it to development or production etc. it starts up
+servers and consoles differently - different configuration variables and
+initialization scripts etc.
+
+==== -    rvm, pythonbrew, etc.
+Often one adds a .rvmrc to the root directory to control the ruby version and
+keep the local gem repository pristine (which helps it avoid any conflicts with
+other rails projects etc.). Tools like pythonbrew allow for the same thing with
+python - using environment variables and some easy commands you can have easy
+control over virtualenv for installed python modules and even custom
+non-conflicting versions of python.
+
+==== -    bundler, pip-requirements, etc.
+A quick way to specify gems / python-modules including specific versions that
+this project depends on. Especially useful when combined with rvm/pythonbrew,
+etc. Usually before you're allowed to run anything like test servers it'll
+check to make sure the environment has the dependencies and tell you to install
+them if not.
+
+
+==== -    git branches and submodules
+Obviously changing your scm branch very quickly and automatically changes the
+files in your project. Thus you can quickly switch between "topical" branches,
+bug-fix branches, authoritative branches, etc.
+
+Submodules offer an aggregation method for more complex projects that depend on
+separate git repositories. These allow you to:
+1. Modify the submodule's code at the same time you're iterating on the project that uses it - so especially useful if you want greater modularization of code that you're working on.
+2. Have your repository/branch "pointing" to a specific commit of the submodule. This gives you a kind of very fine-grained dependency control.  You could have a feature branch pointing to a newer commit of a submodule (which could be a local clone of any git repository whether you have "push" access or not) - and thus just by switching branches you're also changing the version of the submodules you're depending on.
+
+==== -    development vs. server-env:  deployment
+(i.e., capistrano, fabric, etc. etc.)
+
+Deployment is essentially a slightly more complex way of adjusting the project
+for a (sometimes very) different environment... Sometimes very different, yet
+often the most important- the one you're targeting in the first place...
+
+Included here are continuous deployment tools (we use Brigade internally at
+Justin tv, written by Emmett Shear [and modified by several employees]. It
+rocks. One day it will be opensourced) and things as simple as scripts that
+do a git-push to servers and issue a SIGHUP.
+
+==== -    puppet
+Then there's good ol' puppet. In big systems it's often used to declaratively
+say what software is required on what machines (and it figures out how to get
+them installed in the most appropriate manner for that OS/configuration) and
+sometimes even how to startup and supervise processes on those machines. I have
+to include it here because there's a bunch of stuff that metacon does that we
+have done w/ puppet in the past, plus it's declarative nature is a very, very
+good standard for any similar tools to aspire to. Metacon cannot replace
+puppet- just some stuff that people are sometimes driven to hijack puppet to do
+for them. (that's pretty much true of all tools listed above).
+
+=== Description (finally)
+_metacon_ is for easily organizing and developing any project that may consist
+of multiple:
+- runtime environments (development/staging/production/testing...)
+- os environments (mac and linux)
+- specific-machine environments (server82 vs cluster3)
+- roles (possibly no one else may need this- when a project can run as
+  different roles / essentially multiple different projects combined into one)
+
+and that needs to be easily developed, integrated, and deployed without
+interuption of existing services. Or, stated differently, the goals as follows.
+
+    (Aside, Quick redefinition of 'environment')
+
+    Since I keep using the term, when I say "environment" I'm not referring here to
+    the normal bash/shell environment. I'm referring specifically to the
+    combination above:   runtime-context & os & machine & role
+
+==== 1. Develop against the environment union, abstract out divergences
+Develop for the different environment combinations at the same time - with the
+assumption that much of the development is not environment sensitive or that
+the environment-sensitive parts can be factored away. Easily abstract the
+environment stuff away.
+
+==== 2. Easy way to run/iterate in isolated environments.
+
+Keep them ISOLATED - so if you wanted to pristinely run several different
+projects on a server with different needs as far as ruby/python versions and
+packages, binary dependencies, etc., you can (up to a point). Stated another
+way- take the isolation and orthoganality that something like RAILS_ENV /
+.rvmrc provide and extend it pretty much automatically to the following:
+
+- Ruby version/build
+- Ruby gems / packages
+- Python version/build
+- Python modules / packages
+- Anything you can have as a git submodule including but not limited to:
+  - More ruby or python packages that you iterate on or deploy with where the
+    version/branch may change.
+  - Patched or internally developed code that would normally be compiled and
+    installed globally on the target machine.
+  - Other projects that represent loose dependencies that may be getting work
+    done on them orthogonally to this repo (yes, that's mostly a restatement of
+    the last item).
+- Supervisor processes / running contexts
+
+Extending it further. So, you may wonder, why not just go "all the way" and
+actually completely change your PATH or segregate by user or even have
+virtual-machines or something? Because, at least with current technologies,
+that would violate goal #1 and goal #3.
+
+==== 3. Fast environment switching
+Very fast switching between the environments and even running certain tasks on
+environments concurrently within the current file and change-set context.  In
+other words, I modify a script and can immediately test it against my "staging"
+and "test" environments for my "responder" role. Switching ideally
+instantaneous, at least after the first time in that environment (when lots of
+downloading / installing needs to happen).
+
+==== RESULTS EXPECTED
+* *Developer-Platform-Agnosticism*. That is, a large degree of cross-platform
+  commutativity: develop on mac, deploy on linux, etc.
+* *Easy-Continual-Integration*. Dependency conflicts - even needing a
+  different binary usually installed on the target, is revealed in such a way
+  that is very easy to resolve.
+* *Easy-Continual-Deployment*. Environmental concerns built in and coded
+  against from the beginning with very little pain. Complex projects that are
+  already huge and complex and in desparate need of continual deployment should
+  be able to migrate to metacon easily and enjoy all the benefits. (This is why
+  we needed it).
+* *Easy-Scaling*. At least at the meta level. Application-specific scaling
+  concerns are of course your problem, but at least with metacon it's easy to
+  say "this worker needs to use 4 processors on servers 70 - 94, but only one
+  processor when running on my ancient netbook."
+
+
+* Main goal in the end is *Fast/Agile-Development* on complex projects that are
+  aggregates of several projects.
+
+
+== Contributing to metacon
+ 
+* Check out the latest master to make sure the feature hasn't been implemented
+  or the bug hasn't been fixed yet Check out the issue tracker to make sure
+  someone already hasn't requested it and/or contributed it
+* Fork the project
+* Start a feature/bugfix branch
+* Commit and push until you are happy with your contribution
+* Make sure to add tests for it. This is important so I don't break it in a
+  future version unintentionally.
+* Please try not to mess with the Rakefile, version, or history. If you want to
+  have your own version, or is otherwise necessary, that is fine, but please
+  isolate to its own commit so I can cherry-pick around it.
+
+== License
+
+MIT License.
+Copyright (c) 2011 Joseph Wecker.
+See LICENSE.txt for further details.

data/Rakefile

@@ -0,0 +1,51 @@
+# encoding: utf-8
+
+require 'rubygems'
+require 'bundler'
+begin
+  Bundler.setup(:default, :development)
+rescue Bundler::BundlerError => e
+  $stderr.puts e.message
+  $stderr.puts "Run `bundle install` to install missing gems"
+  exit e.status_code
+end
+require 'rake'
+
+require 'jeweler'
+Jeweler::Tasks.new do |gem|
+  # gem is a Gem::Specification... see http://docs.rubygems.org/read/chapter/20 for more options
+  gem.name =           'metacon'
+  gem.homepage =       'http://github.com/josephwecker/metacon'
+  gem.license =        'MIT'
+  gem.summary =        %Q{Metacontroller for organizing aggregate projects}
+  gem.description =    %Q{Tool with some similarities to puppet but specializing in fast development iteration and continuous deployment. Specifically initially for use with justin.tv / twitch.tv project clusters.}
+  gem.email =          'jwecker@justin.tv'
+  gem.authors =        ['Joseph Wecker']
+  gem.requirements <<  'git, v1.7.4.1 or greater'
+  gem.requirements <<  'rvm, v1.8.2 or greater'
+  gem.requirements <<  'pythonbrew, v1.1 or greater'
+
+  gem.post_install_message = "\n\n\e[1;32m\e[40m--- Please run \e[1;37mmetacon-install\e[1;32m to check dependencies & finish the installation --- \e[0m\n\n"
+  # dependencies defined in Gemfile
+end
+Jeweler::RubygemsDotOrgTasks.new
+
+require 'rake/testtask'
+Rake::TestTask.new(:test) do |test|
+  test.libs << 'lib' << 'test'
+  test.pattern = 'test/**/test_*.rb'
+  test.verbose = true
+end
+
+require 'rcov/rcovtask'
+Rcov::RcovTask.new do |test|
+  test.libs << 'test'
+  test.pattern = 'test/**/test_*.rb'
+  test.verbose = true
+  test.rcov_opts << '--exclude "gems/*"'
+end
+
+task :default => :test
+
+require 'yard'
+YARD::Rake::YardocTask.new

data/TODO.md

@@ -0,0 +1,44 @@
+
+
+# Installation
+ (gem -> basic libraries used by commands)
+ (installer -> 
+ - Basic install-script (similar to rvm installation procedure)
+ - Install/ensure dependencies
+   - git
+   - rvm
+   - god
+   - pythonbrew
+ - Install shell shim
+
+# Components
+## General Commandline
+ - Figure out how to load various dependency tools?
+## Commands
+ - st / stat  -> environment + versions of dependencies, state of submodules,
+   current git state, running state, etc.
+ - env     [-l[ist] || new\_env]
+ - role    [-l[ist] || new\_role]
+ - machine [-l[ist] || impersonate\_machine]
+ - os (shows current only?)
+ - br / branch [...] -> alias for git-branch so its clear it's an intergral part of
+   the current operating environment
+
+ - run/start [@as-options]  [cmd...options...]
+ - stop
+ - restart (gracefully)
+ - hard-restart (ungracefully)
+ - test (starts supervisord in non-daemon mode if it's not already running for
+   additional feedback)
+
+## Config
+ - Allow a ~/.metacon-config for filling in general things not specified in
+   project directory.
+ - project.config > home.config > default.config
+ - Make sure there is general (sane) config stuff for supervisord
+
+## Shell Prompt (PS1) for Bash/ZSH
+
+## Autocomplete
+
+