• fw [[https://travis-ci.org/mriehl/fw][file:https://travis-ci.org/mriehl/fw.svg?branch=master]] [[https://crates.io/crates/fw][file:https://img.shields.io/crates/v/fw.svg]]

** Why fw? With ~fw~ you have a JSON file describing your workspace. It takes care of cloning projects and can run commands across your entire workspace. You can start working on any project quickly, even if it's not in your flat structured workspace (better than ~CDPATH~!). It also "sets up" your environment when you start working on a project (compile stuff, run ~make~, activate ~virtualenv~ or ~nvm~, fire up ~sbt~ shell, etc.)

Here's an example configuration that should be easy to grasp:

#+BEGINSRC json { "projects": { "pybuilder": { "name": "pybuilder", "git": "git@github.com:pybuilder/pybuilder.git", "afterclone": "virtualenv venv && source venv/bin/activate && ./build.py installdependencies", "afterworkon": "source venv/bin/activate" }, "fw": { "name": "fw", "git": "git@github.com:mriehl/fw.git", "afterclone": "cargo build", "afterworkon": "git remote update --prune && cargo test" }, "docker": { "name": "docker", "git": "git@github.com:docker/docker.git", "overridepath": "/home/mriehl/go/src/github.com/docker/docker" } }, "settings": { "workspace": "/home/mriehl/workspace" } } #+ENDSRC Per default projects are cloned into ~${settings.workspace}/${project.name}~ but you can override that by setting an ~override_path~ attribute as seen above.

** What this is, and isn't ~fw~ is a tool I wrote to do my bidding. It might not work for you if your workflow differs a lot from mine or might require adjustments. Here are the assumptions:

• only git repositories
• only ssh clone (easily resolveable by putting more work in the git2 bindings usage)
• ~ssh-agent~ based authentication

* If you can live with all of the above, you get: - workspace persistence (I can ~rm -rf~ my entire workspace and have it back in a few minutes) - ZERO overhead project switching with the ~workon~ function (need to activate ~nvm~? Run ~sbt~? Set LCD brightness to 100%? ~fw~ will do all that for you) - zsh completions on the project names for ~workon~ - generate projectile configuration for all your project (no need to ~projectile-add-known-project~ every time you clone some shit, it will just work)

** Installation #+BEGINSRC bash cargo install fw #+ENDSRC

If you are using OSX make sure that you got the rust toolchain from [[https://rustup.rs/][rustup]] and not from homebrew. If you're using the homebrew formula you will run into [[https://github.com/mriehl/fw/issues/11][issues]].

You will also want to add the following hack to your ~.zshrc.local~ or the ~workon~ automation will not work: #+BEGIN_SRC bash workon () { SCRIPT="$(~/.cargo/bin/fw -q gen-workon $@)" if [ $? -eq 0 ]; then eval "$SCRIPT" else printf "$SCRIPT\n" fi }

nworkon () { SCRIPT="$(~/.cargo/bin/fw -q gen-workon -x $@)" if [ $? -eq 0 ]; then eval "$SCRIPT" else printf "$SCRIPT\n" fi } #+END_SRC

I suggest you thoroughly think this through because it will eval the stdout created by ~fw~ in your shell when you run the ~workon~ function.

Another thing that will make you much more productive is to use the ~zsh~ completions from this repo (if you're not using the ~zsh~ I guess you would get a bigger productivity boost by switching to ~zsh~ first). I suggest dropping them here: ~/usr/share/zsh/functions/Completion/Linux/~. After cloning this repo you could do this:

#+BEGINSRC bash cp completions/zsh/* /usr/share/zsh/functions/Completion/Linux/ #+ENDSRC

* Usage ** Migrating to ~fw~ / Configuration Initial setup is done with

#+BEGINSRC bash fw setup DIR #+ENDSRC

This will look through ~DIR~ (flat structure!) and inspect all git repositories, then write ~.fw.json~ in your home. You can edit that file manually to add stuff. If you have repositories elsewhere you will need to add them manually and set the ~overridepath~ property. The ~fw.json~ file is portable as long as you change the ~workspace~ attribute, so you can share the file with your colleagues (projects with ~overridepath~ set won't be portable obviously. You can also add shell code to the ~afterclone~ and ~afterworkon~ fields on a per-project basis. ~afterclone~ will be executed after cloning the project (interpreter is ~sh~) and ~afterworkon~ will be executed each time you ~workon~ into the project.

* Turn ~fw~ configuration into reality From now on you can

#+BEGINSRC bash fw sync #+ENDSRC

which will clone all missing projects that are described by ~.fw.json~ but not present in your workspace.

* Running command across all projects There is also #+BEGINSRC bash fw foreach 'git remote update --prune' #+ENDSRC which will run the command in all your projects using ~sh~.

* Updating ~fw~ configuration (adding new project) Instead of cloning new projects you want to work on, I suggest adding a new project to your ~.fw.json~. This can be done using the tool with

#+BEGINSRC bash fw add git@github.com:mriehl/fw.git #+ENDSRC

(you should run ~fw~ sync afterwards!) In case you don't like the computed project name (the above case would be ~fw~) you can override this (like with ~git clone~ semantics):

#+BEGINSRC bash fw add git@github.com:mriehl/fw.git my-fw-clone #+ENDSRC

If you're an emacs user you should always run #+BEGINSRC bash fw projectile #+ENDSRC

after a ~sync~. This will overwrite your projectile bookmarks so that all your ~fw~ managed projects are known.

** workon usage Just

#+BEGINSRC bash workon MYPROJECT #+ENDSRC

It will drop you into the project folder and execute all the hooks.

If you're in a pinch and just want to check something real quick, then you can use

#+BEGINSRC nworkon MYPROJECT #+ENDSRC as that will no execute any post-workon hooks and simply drop you into the folder.