Amp Redux

[Justin Love]

Hello.

I saw Amp go through my news feeds several months ago, but didn't
devote any time to it. However, I wanted to get involved, and see the
project prosper, so I threw in a second proposal to RubyConf with what
seemed like plenty of time to dig into the project. Surprisingly, it
got accepted. So I started looking into the project more deeply,
following the web page to the recently updated repository.

A few weeks later there were no updates to the repository, the web
page had disappeared, and I was left wondering if I'd just signed up
for a funeral speech. A little later, I found 'amp_redux' on github;
Not having the web page readily accessible to point me to the group, I
contacted Mike and Ari directly. It seems they've been consumed in
other pursuits, but are working on reboot of the Amp project. I'm
reposting some of the more informative parts to help let people know
what is going on. General info below; I'll post separate message for
some topics.

Ari Brown, on the last straw:

"When we realized that amp and mercurial have fundamentally different
views on the repository. HG focuses on the implementation (filelogs,
changelogs, indexes/indices), and we wanted to focus on changesets,
repositories, and stuff like that, with their implementations being
background. This naturally gives us a more repo-independent
structure."

Michael Edgar:

"We're currently restructuring, though we'll be pulling in major
components of the
existing Amp code. Right now, we're trying to separate the front-end
and back-end
architectures and dogfood our plugin system, hence the amp_redux repo
we've
got right now. The idea is that we'll have a generic front-end that
consumes plugins
for each repository format, and the mercurial support will be a plugin
following that
API. Right now, we designed the front-end and back-end together with
mercurial support,
so extricating the generic plugin API has proven difficult.

The idea will be that, when you install "amp", you get amp-front, amp-
core, amp-hg, and
amp-git as rubygems dependencies.

I can say that our new version is coming from the "throw away the
first one" mentality. We had to build the first version of Amp to
figure out how to do it right.

The new plugin architecture will force us to keep our APIs consistent
(by
dogfooding), which is important for a project focused on
customization. Also,
the best part is that each component can be licensed independently, so
while
the mercurial plugin might be GPLv2 until we can rewrite it, the git
plugin will
be Ruby licensed, so those concerned about licensing can rest easy
that we
have a path to lose the GPL soon!

(I don't want to start a licensing flamewar, but Ruby projects are
typically MIT/Ruby
licensed, and we want *anyone* to use Amp, even if they want to make a
proprietary
product out of it.)


So I'm using RSpec for new tests, but I want to use tools to the best
of my advantage,so I've pulled the tests for Trollop (the command line
parser) in, and those are designed
for Test::Unit. I actually added a few more tests to bump up the
coverage around
error conditions :-)

In addition, I'm setting up some cucumber features for end-to-end
testing.


Also, check out the new repos we'll be migrating to, for our different
components:

http://github.com/michaeledgar/amp-core
http://github.com/michaeledgar/amp-hg
http://github.com/michaeledgar/amp-git
http://github.com/michaeledgar/amp-front

(Everything but amp-front is empty right now)

The idea is amp_redux, as it is now, will be a super-tiny wrapper
around those other projects. It'll load up amp-front, which will find
the amp-core, amp-hg, and amp-git plugins (and additional plugins, of
course), and amp-front will handle command dispatch.

As it stands, amp-front is close to being able to be separated out as
a standalone command-line app framework, but that's not a top priority
of course."

[Ari Brown]

Great writeup! An important thing to reiterate is that we originally conflated interface with implementation; amp-redux is our attempt at correcting this.