Amp Redux: Dependencies and RubyGems

0 views
Skip to first unread message

Justin Love

unread,
Oct 28, 2010, 8:35:38 PM10/28/10
to amp-vcs
One of the surprising things I've run into is that Amp is trying to
avoid using Rubygems. It's a strictly performance concern: requiring
rubygems adds overhead, and a command line program like Amp will be
run repeatedly with an expectation of rapid feedback. I already put
most of this information into a document in amp-front, plus one more
piece of interest:

Michael Edgar:

"I'm a bit unsure how to test amp-core right now, so I've set it to
require
rubygems then amp-front during specs. I'd prefer a non-rubygems
dependent
solution, but it seems that when designing a modular system, the tests
are
going to have to have an increasingly elaborate harness."

# Amp Dependancies Design Doc

Amp has so far avoided Rubygems dependancies, due to performance
concerns.
Required libraries are included wholesale; so far all such libraires
have
been modified in some way.

## Dependancies

### Maruku

Maruku is a pure ruby markdown interpreter.
Amp uses a highly hacked version of Maruku
(it adds an output form with ANSI color codes)
that was trimmed down to try to make it lightweight.

### Trollop

Trollop is a command-line parsing library.
It didn't originally expose its --help behavior,
which is really nice because it lists options automatically.
The Amp version exposes the parser object so we can run
parser.educate!.

## The Case Against Rubygems

Loading Rubygems on each invocation of amp adds at least 150-500ms+ to
each invocation.
With the current plugin architecture, we require users to either use
rubygems,
or individually download each repo and load plugins manually using
their Ampfile.
An installer script down the line could automate the latter option.

### Bundler

Bundler (require 'bundler/setup') adds another 400ms+ to startup time.
A Gemfile is used to streamline gem installation, but it is not used
by
Amp itself.
Reply all
Reply to author
Forward
0 new messages