Plugin responsibility

[Justin Love]

I thought I had read that Amp-core was responsible for plugins, (and described it as such in the presentation) but I found the plugin code in Amp-front.  Is this an accident of development that will be changed, or should I update the slides accordingly?

--
Justin Love -- http://JustinLove.name/
http://ComputerGeneratedDreams.com/
"[T]he woods would be silent if no bird sang except the best."
 - Henry Van Dyke

[Michael Edgar]

Getting back to these e-mails now. Worst time for me to have to cram schoolwork + amp, but

those are the breaks.

Amp-front is responsible for the plugins, since the idea was amp-front would be completely

generic (and eventually extractable into its own independent project). That means amp-front

handles our command system and plugins. With those two, you have a completely customizable

application framework, extendable by both the authors and the users.

So the architecture is that amp, the binary, requires amp-front for a generic application framework,

then loads the amp-core plugin as a required plugin that brings in all kinds of good VCS stuff.

To me it seems like a good idea. What are your thoughts?

[Justin Love]

> So the architecture is that amp, the binary, requires amp-front for a generic application framework,
>
> then loads the amp-core plugin as a required plugin that brings in all kinds of good VCS stuff.
> To me it seems like a good idea. What are your thoughts?

I guess my main concern was that someone who wanted to use Amp as an
API wouldn't want to depend on the command-line shell. With the
plugin manager defined in Amp-front, they wouldn't have a choice.

[Michael Edgar]

Ah, I see. Well, the main downside to this approach (which can be as simple as `require 'amp'; Amp.load_rubygems_plugins`) is that it will load in the commands each plugin defines (which will naturally include the core commands). They won't need to be run, but they'll be loaded in. A bug in one of those plugins could break the behavior of amp.

So I propose this:

1. Change the current 'amp-core' plugin load Amp as a library, setting up autoload hooks for API use (currently Amp::Core::Repositories...).
2. Move the current file to 'amp-core/plugin', and have the command-line binary require *that*.

[Justin Love]

On Tue, Nov 9, 2010 at 09:20, Michael Edgar <ad...@carboni.ca> wrote:
> Ah, I see. Well, the main downside to this approach (which can be as simple as `require 'amp'; Amp.load_rubygems_plugins`) is that it will load in the commands each

Slight tangent, but another thing I've been thinking that we might
separate workflows from repos e.g. Amp-wf-git, Amp-wf-svn, with the
generic Amp-wf-amp. So a git user could install his familiar workflow
and then all the repository backends he wants. Longer term goal of
course.

> 1. Change the current 'amp-core' plugin load Amp as a library, setting up autoload hooks for API use (currently Amp::Core::Repositories...).
> 2. Move the current file to 'amp-core/plugin', and have the command-line binary require *that*.

Took me a little bit to make sense of that, but yes, separating
'plugin-nature' from the library itself would be a step in the right
direction. (And by exchanging files, would probably look a lot like
my 'loading' branch) Now the issue is the repos would still be plugins
and need the plugin machinery? Or would the user require each one in
that setup?

[Michael Edgar]

> On Tue, Nov 9, 2010 at 09:20, Michael Edgar <ad...@carboni.ca> wrote:
>> Ah, I see. Well, the main downside to this approach (which can be as simple as `require 'amp'; Amp.load_rubygems_plugins`) is that it will load in the commands each
>
> Slight tangent, but another thing I've been thinking that we might
> separate workflows from repos e.g. Amp-wf-git, Amp-wf-svn, with the
> generic Amp-wf-amp. So a git user could install his familiar workflow
> and then all the repository backends he wants. Longer term goal of
> course.
>

This was one of our early goals... but then we got distracted by mercurial's
harder corners and whatnot. There's a couple of rudimentary Git workflow
commands in the old repo... it's one of the cool parts of the dead-simple
command system.

Emulating svn's (centralized!) workflow could be as simple as adding --workflow=svn to
your command/alias/Ampfile.

>> 1. Change the current 'amp-core' plugin load Amp as a library, setting up autoload hooks for API use (currently Amp::Core::Repositories...).
>> 2. Move the current file to 'amp-core/plugin', and have the command-line binary require *that*.
>
> Took me a little bit to make sense of that, but yes, separating
> 'plugin-nature' from the library itself would be a step in the right
> direction. (And by exchanging files, would probably look a lot like
> my 'loading' branch) Now the issue is the repos would still be plugins
> and need the plugin machinery? Or would the user require each one in
> that setup?

Hrm... interesting. The plugin machinery primarily exists for this, automated
system:

Gem.find_files('amp_plugin').each { |r| require r }
Plugin.each { |p| p.load! }

While also allowing for finer-grained loading.

Almost every interaction with this loading issue will be from someone loading
the API: we only write one binary with the amp library, so we should optimize
for others. I assume most people working with amp will prefer `require 'amp'`,
followed by any non-standard plugins (hg and git come with it).

I'll figure something more specific out in the coming day or two.

[Justin Love]

On Tue, Nov 9, 2010 at 10:04, Michael Edgar <ad...@carboni.ca> wrote:
> for others. I assume most people working with amp will prefer `require 'amp'`,

Agreed. That's why I might like to see plugins in Amp-core, Amp, or
even Amp-plugins

> I'll figure something more specific out in the coming day or two.

Hey, don't kill yourself man. Nobody complained about the current
state of Amp-redux at either of the test runs I did.

[Ari Brown]

On Nov 9, 2010, at 10:54 AM, Justin Love wrote:
> Took me a little bit to make sense of that, but yes, separating
> 'plugin-nature' from the library itself would be a step in the right
> direction.

Indeed, that is our goal: separate interface from implementation.

[Ari Brown]

On Nov 9, 2010, at 11:04 AM, Michael Edgar wrote:
> Hrm... interesting. The plugin machinery primarily exists for this, automated
> system:
>
> Gem.find_files('amp_plugin').each { |r| require r }
> Plugin.each { |p| p.load! }

We should avoid tying ourselves to rubygems, however; there are still (and possibly forever will be) machines that do not have or use rubygems. It would be nice to keep them in mind.

[Michael Edgar]

Providing a convenience method isn't "tying ourselves to rubygems" and the current
implementation more than allows for loading every plugin without any rubygems-specific
logic.

[Ari Brown]

On Nov 9, 2010, at 4:02 PM, Michael Edgar wrote:

> Providing a convenience method isn't "tying ourselves to rubygems" and the current
> implementation more than allows for loading every plugin without any rubygems-specific
> logic.

I just thought it was worth saying in case we got plugin-happy and got caught up with rubygems.

[Justin Love]

On Tue, Nov 9, 2010 at 14:58, Ari Brown <a...@aribrown.com> wrote:
> We should avoid tying ourselves to rubygems, however; there are still (and possibly forever will be) machines that do not have or use rubygems. It would be nice to keep them in mind.

I ran across RIP, which appears to do a lower-overhead kind of
install; thought it might be useful if startup time was an issue - but
it's a user choice, not our choice. I've put off looking into it
since RIP seems to be rebooting also right now.

I remember reading this a while ago:

http://tomayko.com/writings/require-rubygems-antipattern