Fig 0.2.0 ideas

[Matthew Foemmel]

Now that folks are actually using Fig in anger I'd like to start work
on a major overhaul based on what we've learned. Here's what I'm
thinking for Fig 0.2.0:

First off, I'd like to rewrite it from the ground up in Go (http://
golang.org/). Reasons:

    * Zero dependencies. Go produces executables that don't depend on
any runtime, including libc(!). This gets us out of the rather
unfortunate situation we have now where our dependency management tool
requires a dependency management tool to get itself running. Awkward.
    * Lightweight. Go executables start up faster than Ruby and use
less memory. I want fig to be as small as possible e.g. something you
would be ok calling thousands of times from within a script.
    * Good fit. Go bills itself as a systems language and I would
classify Fig as a systems tool. Go lets you get closer to the OS when
doing things like starting up new processes, managing environment
variables, etc.
    * Concurrency. Goroutines should make it easy to implement things
like parallel downloads.

The downsides;

    * Windows support isn't 100% there yet (but getting close)
    * No built-in library for handling zip files (there's support for
tar and gzip, however). We can shell out to another app for the time
being.
    * Nobody knows Go.

I think all of these will be fixed with time, however.

There are a bunch of features that I want to include in Fig 0.2.0, but
I'm going to try tackling the tricky ones first to make sure we don't
design ourselves into a corner again. In particular I'd like to make
sure we can:

    * Detect of cyclic dependencies
    * View all transitive dependencies for a package, without actually
downloading and installing them
    * Print a backtrace (i.e. the chain of "includes") whenever we get
an error
    * Support an "override" keyword, to override the version of a
package specified in a dependency
    * Keep track of which packages "fig retrieved" files came from, so
that we can handle changes to the package.fig file gracefully
    * Lock packages in the repository during download/install so that
multiple fig processes running at the same time don't clobber each
other
    * Support multiple repositories
    * Handle platform specific configurations (e.g. run config A on
windows, config B on linux, etc)
    * Separate the repository directory (where archives live) from the
workspace directory (where things are actually installed) in FIG_HOME
    * Use MD5 checksums for repository files so we know when a local
package is corrupt

I'm also going to trying implementing the following not-so-tricky
features. If you want something that's not on this list let me know:

    * Command-style command line syntax
    * Make update-if-missing the default
    * Allow "retrieve" statements inside configs
    * Wildcards in retrieve statements (e.g. "retrieve @foo/**/*.jar-
>lib")
    * "fig clean" should delete retrieved files; "fig uninstall"
should delete files from the local repos
    * Anything else listed at: http://github.com/mfoemmel/fig/issues

I have checked some inital work into a 'go' branch in the github
repository, if anyone wants to follow along or help out.

- Foemmel