** 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 javascript { "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:brocode/fw.git", "afterclone": "cargo build", "tags": ["git", "rust", "brocode"] }, "docker": { "name": "docker", "git": "git@github.com:docker/docker.git", "overridepath": "/home/brocode/go/src/github.com/docker/docker" } }, "settings": { "shell": ["/usr/bin/zsh", "-c"], "workspace": "~/workspace", "tags": { "git": { "afterworkon": "git remote update --prune", "priority": 0 // lowest priority tags run first }, "js": { "afterworkon": "source ~/.nvm/nvm.sh" }, "rust": { "afterclone": "cargo build", "afterworkon": "cargo test && rustup run nightly cargo clippy" }, "brocode": { "priority": 100, // highest priority tag wins workspace resolution "workspace": "~/workspace/brocode/" }, } } } #+ENDSRC Per default projects are cloned into ~${settings.workspace}/${project.name}~ but you can override that by setting an ~overridepath~ 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:

* 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 [[https://rustup.rs/][rustup]] is recommended but you [[https://github.com/Homebrew/homebrew-core/pull/14490][should be able to use brew too]].

* With fzf Another thing that will make you much more productive is to use the ~zsh~ completions (if you're not using the ~zsh~ I guess you would get a bigger productivity boost by switching to ~zsh~ first).

Since we integrate with [[https://github.com/junegunn/fzf][fzf]] it is recommended to use that for the best possible experience (~workon~ and ~nworkon~ will be helm-style fuzzy finders). Make sure ~fzf~ is installed and then add this to your ~zsh~ configuration:

#+BEGINSRC shell-script if [[ -x "$(command -v fw)" ]]; then if [[ -x "$(command -v fzf)" ]]; then eval $(fw print-zsh-setup -f 2>/dev/null); else eval $(fw print-zsh-setup 2>/dev/null); fi; fi; #+ENDSRC

* Without fzf If you don't want ~fzf~ integration:

#+BEGINSRC shell-script if [[ -x "$(command -v fw)" ]]; then eval $(fw print-zsh-setup 2>/dev/null); fi; #+ENDSRC

In this case ~workon~ and ~nworkon~ will require an argument (the project) and will provide simple prefix-based autocompletion. You should really use the ~fzf~ integration instead it's much better!

* 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:brocode/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:brocode/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 #+ENDSRC

It will open a fuzzy finder which you can use to select a project. Press on a selection and 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 #+ENDSRC as that will no execute any post-workon hooks and simply drop you into the project folder.

In case you're not using ~fzf~ integration (see above) you will need to pass an argument to ~workon~ / ~nworkon~ (the project name). It comes with simple prefix-based autocompletion.