librelist archives

« back to archive

Command-line plugins broken

Command-line plugins broken

From:
Nathanael D. Jones
Date:
2012-02-01 @ 20:29
I'm running into multiple issues integrating my Wordpress import script
into Nesta's plugin system.

Problem A: It seems that /bin/nesta* does not load/require any plugins*,
even if they are in the gemfile, and therefore cannot execute plugin
command line options.

I've found two ways to get it to work, but both require modifications to
the Nesta core.

Adding this to the top of /bin/nesta or /lib/nesta/commands.rb seems to
work, as long as I both

1) Use 'bundle exec nesta ..."
2) Put the plugin's code in the 'nesta-plugin-pluginname.rb' file directly,
and not in init.rb.

require "rubygems"
require "bundler"
Bundler.setup(:default, :ci)
Bundler.require(:default, :ci)

Or, modifying /bin/nesta main() to automatically require
'nesta-plugin-command/commands.rb'

def self.main(options)
      command = ARGV.shift
      command.nil? && usage
      begin
        begin
          command_cls = class_for_command(command)
        rescue NameError => e
          plugin_name = "nesta-plugin-#{command.split(':')[0]}/commands"
          $stderr.puts "#{class_name_for_command(command)} not loaded."
          $stderr.puts "Trying to load '#{plugin_name}'"
          require plugin_name
        end
        command_cls = class_for_command(command)
      rescue NameError
        usage
      else
        command_cls.new(ARGV[0], options).execute
      end
    rescue RuntimeError => e
      $stderr.puts "ERROR: #{e}"
      exit 1
    rescue Nesta::Commands::UsageError => e
      $stderr.puts "ERROR: #{e}"
      usage
    end

Problem B:

Nesta throws an error on un-identified command line options, currently
preventing plugins from executing. This error (and the help) should instead
be shown after plugins have had their turn at parsing the commands.

Problem C:

Nesta doesn't offer a way to improve the usage/help screen via a plugin.

My opinion:

This situation needs to be overhauled or abandoned. Either plugins do their
own /bin/ script, or we need to introduce a counterpart to
Nesta::Plugin.register(__FILE__) for command-line scripts.

If there's a consensus quickly, I can help build the new system.

Best regards,
Nathanael Jones

Re: [nesta] Command-line plugins broken

From:
Graham Ashton
Date:
2012-02-02 @ 11:32
On 1 Feb 2012, at 20:29, Nathanael D. Jones wrote:

> Problem A: It seems that /bin/nesta does not load/require any plugins, 
even if they are in the gemfile, and therefore cannot execute plugin 
command line options.

True; this part of the plugin system hasn't been implemented yet (which is
why "plugins can add commands" isn't in the docs). I know the CHANGES file
mentions plugins with command line options as an upcoming feature of 
0.9.12, but after I rewrote the command parsing code to support it, Wynn 
pointed out I hadn't finished...

I just pushed a patch that'll load the plugins in bin/nesta. It's 
currently in a branch (only commit efc3d3 is relevant):

https://github.com/gma/nesta/commits/command-plugins

Let me know if that works for you. I created a small plugin whose execute 
method just prints "hello" and it works, like this:

  $ bundle exec nesta hello

If I happen to have the right version of the relevant gems installed I can
run it successfully without bundle exec too.

Here's the code for that plugin, should you want to test with it:

https://github.com/gma/nesta-plugin-cli-test

> Problem B: Nesta throws an error on un-identified command line options, 
currently preventing plugins from executing. This error (and the help) 
should instead be shown after plugins have had their turn at parsing the 
commands.

If we allowed plugins to support the same kind of options as bin/nesta 
consumes itself (e.g. --help and --version) we could then update the 
parse_command_line method to include them. That bit would be quite 
straightforward.

How do we prevent multiple plugins from trying to use the same option? Do 
we need a namespace, or do we pass arguments to plugins via a different 
technique (e.g. environment variables) and just document that you need to 
namespace your env vars (e.g. CLI_TEST_SETTING)?

> Problem C: Nesta doesn't offer a way to improve the usage/help screen 
via a plugin.

I agree that's an issue that needs addressing.

> This situation needs to be overhauled or abandoned. Either plugins do 
their own /bin/ script, or we need to introduce a counterpart to 
Nesta::Plugin.register(__FILE__) for command-line scripts.

Abandoned?!! ;-)

Cheers for the offer of helping implement this. That patch above was one 
of those things that I'd written as soon as I'd worked out how to approach
it.

I don't have a plan for updating the help messages yet, but the most 
obvious (easy) solution would be to get each plugin to include a snippet 
of command line docs that bin/nesta would include on demand. Those 
snippets could then be sorted and concatenated to the end of the help 
message.

How does that sound? If you fancied doing that I'd happily merge a pull request.

Cheers,
Graham

--
Graham Ashton
Founder, The Agile Planner
http://theagileplanner.com | @agileplanner | @grahamashton


Re: [nesta] Command-line plugins broken

From:
Nathanael D. Jones
Date:
2012-02-15 @ 04:07
Graham - Sorry for the late response; prior to your reply I'd already
gotten the plugin in pretty good shape using a dedicated
bin/wordpress-to-nesta script.

I'd planned on an immediate rewrite to take advantage of your changes, but
due to unforeseen circumstances, I wasn't able to, and might not be able to
for a few more weeks.

I should have immediately replied with the current state of the plugin
anyhow, since others might have needed it - but better late than never.

Here's the link:

https://github.com/nathanaeljones/nesta-plugin-wordpress

The docs are quite thorough and the script seems very stable. If you run
into a problem, please open an issue or email support@imageresizing.net.

Right now, the plugin requires my branch of nesta, since the main version
doesn't allow for plugins to add new formats (and a plain XHTML format is a
prereq to import from wordpress).

Anyhow, it's all in the readme:
https://github.com/nathanaeljones/nesta-plugin-wordpress

Best regards,
Nathanael Jones



On Thu, Feb 2, 2012 at 6:32 AM, Graham Ashton <graham@effectif.com> wrote:

> On 1 Feb 2012, at 20:29, Nathanael D. Jones wrote:
>
> > Problem A: It seems that /bin/nesta does not load/require any plugins,
> even if they are in the gemfile, and therefore cannot execute plugin
> command line options.
>
> True; this part of the plugin system hasn't been implemented yet (which is
> why "plugins can add commands" isn't in the docs). I know the CHANGES file
> mentions plugins with command line options as an upcoming feature of
> 0.9.12, but after I rewrote the command parsing code to support it, Wynn
> pointed out I hadn't finished...
>
> I just pushed a patch that'll load the plugins in bin/nesta. It's
> currently in a branch (only commit efc3d3 is relevant):
>
> https://github.com/gma/nesta/commits/command-plugins
>
> Let me know if that works for you. I created a small plugin whose execute
> method just prints "hello" and it works, like this:
>
>  $ bundle exec nesta hello
>
> If I happen to have the right version of the relevant gems installed I can
> run it successfully without bundle exec too.
>
> Here's the code for that plugin, should you want to test with it:
>
> https://github.com/gma/nesta-plugin-cli-test
>
> > Problem B: Nesta throws an error on un-identified command line options,
> currently preventing plugins from executing. This error (and the help)
> should instead be shown after plugins have had their turn at parsing the
> commands.
>
> If we allowed plugins to support the same kind of options as bin/nesta
> consumes itself (e.g. --help and --version) we could then update the
> parse_command_line method to include them. That bit would be quite
> straightforward.
>
> How do we prevent multiple plugins from trying to use the same option? Do
> we need a namespace, or do we pass arguments to plugins via a different
> technique (e.g. environment variables) and just document that you need to
> namespace your env vars (e.g. CLI_TEST_SETTING)?
>
> > Problem C: Nesta doesn't offer a way to improve the usage/help screen
> via a plugin.
>
> I agree that's an issue that needs addressing.
>
> > This situation needs to be overhauled or abandoned. Either plugins do
> their own /bin/ script, or we need to introduce a counterpart to
> Nesta::Plugin.register(__FILE__) for command-line scripts.
>
> Abandoned?!! ;-)
>
> Cheers for the offer of helping implement this. That patch above was one
> of those things that I'd written as soon as I'd worked out how to approach
> it.
>
> I don't have a plan for updating the help messages yet, but the most
> obvious (easy) solution would be to get each plugin to include a snippet of
> command line docs that bin/nesta would include on demand. Those snippets
> could then be sorted and concatenated to the end of the help message.
>
> How does that sound? If you fancied doing that I'd happily merge a pull
> request.
>
> Cheers,
> Graham
>
> --
> Graham Ashton
> Founder, The Agile Planner
> http://theagileplanner.com | @agileplanner | @grahamashton
>
>
>
>

Re: [nesta] Command-line plugins broken

From:
Graham Ashton
Date:
2012-02-15 @ 11:48
On 15 Feb 2012, at 04:07, Nathanael D. Jones wrote:

> Graham - Sorry for the late response; prior to your reply I'd already 
gotten the plugin in pretty good shape using a dedicated 
bin/wordpress-to-nesta script.

No problem.

> https://github.com/nathanaeljones/nesta-plugin-wordpress

Blimey. There's plenty of stuff in there! Nice work.

> Right now, the plugin requires my branch of nesta, since the main 
version doesn't allow for plugins to add new formats (and a plain XHTML 
format is a prereq to import from wordpress).

Okay, well we'll need to look into that. Can you send me links to the 
commits that add the features that are required so I can have a look?

Graham

Re: [nesta] Command-line plugins broken

From:
Nathanael D. Jones
Date:
2012-02-15 @ 16:02
https://github.com/nathanaeljones/nesta/compare/master

I'm afraid the changes are spread across 32 commits; but as you can see in
diff above they only comprise about 10 changes.

There are three changes in my branch that aren't directly needed by the
formats system: 1) plain .css files in /views/ are supported (the first
change in the diff),  2) HAML can reference external content in
/content/pages (the very last change in the diff). and 2) in Navigation.rb,
I allow the menu text to be overridden through metadata. There' all
one-liners that I could move the nesta-plugin-simplicity if needed (I think
- can you monkey patch private methods)?

I tried to follow Tilt's interface for registration, with the exception
that formats don't need to be initialized. Initialization doubles the code
complexity, and I didn't see a use-case since Tilt itself handles all the
heavy lifting.

Best regards,
Nathanael Jones


On Wed, Feb 15, 2012 at 6:48 AM, Graham Ashton <graham@effectif.com> wrote:

> On 15 Feb 2012, at 04:07, Nathanael D. Jones wrote:
>
> > Graham - Sorry for the late response; prior to your reply I'd already
> gotten the plugin in pretty good shape using a dedicated
> bin/wordpress-to-nesta script.
>
> No problem.
>
> > https://github.com/nathanaeljones/nesta-plugin-wordpress
>
> Blimey. There's plenty of stuff in there! Nice work.
>
> > Right now, the plugin requires my branch of nesta, since the main
> version doesn't allow for plugins to add new formats (and a plain XHTML
> format is a prereq to import from wordpress).
>
> Okay, well we'll need to look into that. Can you send me links to the
> commits that add the features that are required so I can have a look?
>
> Graham
>

Re: [nesta] Command-line plugins broken

From:
Graham Ashton
Date:
2012-02-16 @ 13:58
On 15 Feb 2012, at 16:02, Nathanael D. Jones wrote:

> I'm afraid the changes are spread across 32 commits; but as you can see 
in diff above they only comprise about 10 changes.

Okay, thanks. I've added a task to my todo list to go through it in detail.

> There are three changes in my branch that aren't directly needed by the 
formats system: 1) plain .css files in /views/ are supported (the first 
change in the diff),  2) HAML can reference external content in 
/content/pages (the very last change in the diff). and 2) in 
Navigation.rb, I allow the menu text to be overridden through metadata.

Is (1) really required for a Wordpress import, or could it be handled a 
different way? It's not how Sinatra works, and I'm not keen on moving 
Nesta away from Sinatra's conventions.

For (2), is the Haml that needs to reference stuff in content/pages also 
in content/pages, or do you have templates in ./views that need to access 
content/pages? The latter feels instinctively wrong to me, but perhaps 
there's a use case I haven't thought of.

For overriding menu link text, I quite like the simplicity of your 
solution. I think the "UI" would be easier if it was specified in menu.txt
itself though. Would you Wordpress import script still work (if modified, 
of course) if we put that info in menu.txt?

> There' all one-liners that I could move the nesta-plugin-simplicity

From a quick look through I got the feeling that nesta-plugin-simplicity 
is really about stuff that you think would make sense to go in core, along
with some things you needed to make the Wordpress import easier? If so, 
would you be up for moving the features that the Wordpress import depends 
on into nesta-plugin-wordpress?

I'm wondering if the simplicity plugin does too many different things, 
that might prevent people from using it. The name doesn't tell you what it
does either, which might be a good thing.

--
Graham Ashton
Founder, The Agile Planner
http://theagileplanner.com | @agileplanner | @grahamashton