allow command line arguments, limit help regex matching #38

bfhenderson · 2014-06-03T20:58:19Z

change the "^help" regex to "^help$" so other plugins may also start with the word help, i.e. "help me do XYZ" without also matching the general "help" command.
help response is now organized by plugin class

NO LONGER IN THIS PR
--- start_will.py and start_dev_will.py accept optional arguments to override plugins and templates directories. ---

./start_dev_will.py --help
usage: start_dev_will.py [-h] [-p [PLUGINS]] [-t [TEMPLATES]]

Start Will the Chatbot

optional arguments:
  -h, --help            show this help message and exit
  -p [PLUGINS], --plugins [PLUGINS]
                        comma seperated plugin directory paths (default:
                        ['plugins'])
  -t [TEMPLATES], --templates [TEMPLATES]
                        comma seperated template directory paths (default:
                        ['templates'])

…lugin

dpoirier · 2014-06-04T11:28:03Z

start_dev_will.py

+            description='Start Will the Chatbot',
+            formatter_class = argparse.ArgumentDefaultsHelpFormatter)
+    parser.add_argument('-p', '--plugins', type=csv, nargs='?', help="comma seperated plugin directory paths", default=["plugins",])
+    parser.add_argument('-t', '--templates', type=csv, nargs='?', help="comma seperated template directory paths", default=["templates",])


Similarly here - can we add "paths" or "dirs" to the parameter name?

skoczen · 2014-06-04T15:56:06Z

Hey @bfhenderson,

Thanks for the PR! Big-picture, this is one of those cases where I realize a) I need to do a much better job communicating future plans, and b) open-source development is sometimes just messy.

Your pain-points for the plugins and template config are felt by me and lots of other users. Right now, the proposed path forward is #37. One thing I also want to avoid with will is having two ways to do the same thing, and from how I see the landscape now, the config file format of 37 feels like a better solve. Please take a look and see if you agree, or if there are aspects to the CLI approach that accomplish something that's missing in the config. Input welcome!

I'm also +1 to a better CLI for will, generally - see the --dev flag on #31 / #37, so I think a lot of what's here is helpful in the long term.

Generally +1 to the PR comments by dpoirer, but before taking on all of those, Please take a look at 37 and the big picture, and let me know your thoughts! Apologies for not doing better communication on this - if you have ideas for how to and where we could communicate this better, I'm all ears!

-Steven

skoczen · 2014-06-04T15:58:17Z

README.md

-        bot = WillBot(plugins_dirs=["plugins",], template_dirs=["templates",])
-        bot.bootstrap()
-    ```
+    Where `run_will.py` can be called with or without arguments to bootstrap an instance of WillBot. 


Note: I'd prefer to keep something like this in docs - the idea being that you could implement will within another project as pure python, instead of having to call him via the CLI.

skoczen · 2014-06-04T16:00:29Z

Also, re: the help plugin stuff, if it's easy to separate that out from the CLI stuff, that'd be great - that stuff doesn't conflict with #37 at all, and makes sense to get merged in without having to talk through the big config space!

bfhenderson · 2014-06-04T16:03:01Z

will/main.py

-                print "\n %s:" % plugin_info["name"]
+                print "\n %s: (%s)" % (plugin_info["name"], plugin_info["class"].__doc__)
+                self.help_files[plugin_info["name"]] = []
+                plugin_help = self.help_files[plugin_info["name"]]


Sorry dpoirier, looks like the act of updating the code destroys comments. Anyways plugin_help should be a more accurate name.

They're still there, but as "commented as an outdated diff" up above, when in conversation view. :)

This reverts commit 887807e.

This reverts commit 806d8e7.

This reverts commit 6634892.

…, templates" This reverts commit ac9cfd3.

…will" This reverts commit 1515c96.

bfhenderson · 2014-06-04T20:52:01Z

No worries, config file looks like a fine solution. I'll just do some
hardcodes until 50 rolls out. Will submit a new PR.

On Wed, Jun 4, 2014 at 10:56 AM, Steven Skoczen notifications@github.com
wrote:

Hey @bfhenderson https://github.com/bfhenderson,

Thanks for the PR! Big-picture, this is one of those cases where I realize
a) I need to do a much better job communicating future plans, and b)
open-source development is sometimes just messy.

Your pain-points for the plugins and template config are felt by me and
lots of other users. Right now, the proposed path forward is #37
#37. One thing I also want to
avoid with will is having two ways to do the same thing, and from how I see
the landscape now, the config file format of 37 feels like a better solve.
Please take a look and see if you agree, or if there are aspects to the CLI
approach that accomplish something that's missing in the config. Input
welcome!

I'm also +1 to a better CLI for will, generally - see the --dev flag on
#31 #31 / #37
#37, so I think a lot of
what's here is helpful in the long term.

Generally +1 to the PR comments by dpoirer, but before taking on all of
those, Please take a look at 37 and the big picture, and let me know your
thoughts! Apologies for not doing better communication on this - if you
have ideas for how to and where we could communicate this better, I'm all
ears!

-Steven

—
Reply to this email directly or view it on GitHub
#38 (comment).

bfhenderson · 2014-06-04T21:08:42Z

Oops, thought this PR had been closed but was mistaken. Anyways the outstanding changes are in and this request is now only about the help command. It is easy enough to toss back in argparse if/when the time comes.

skoczen · 2014-06-05T16:03:48Z

Awesome, thanks for making those changes - going to play with this version of help this AM and see functionally how it feels! (Have some wonders if as a non-technical user I'm more confused by the plugin list, but want to actually live with it before making a decision!)

bfhenderson · 2014-06-05T18:15:01Z

Great, yeah let me know how it feels. Fundamentally what I've got to solve
is grouping help about related commands together. There are a pair of
plugins with maybe a dozen related commands each. When their help is all
mixed together it became much harder to understand how to use the system.

An improvement might be to use the class' doc parameter if not None
instead of its name. Doing such would hide end users from potentially
overly-technically plugin names, and allow will default plugins that span
multiple classes to be carried under some common monicker like "Common
Commands"

On Thu, Jun 5, 2014 at 11:03 AM, Steven Skoczen notifications@github.com
wrote:

Awesome, thanks for making those changes - going to play with this version
of help this AM and see functionally how it feels! (Have some wonders if as
a non-technical user I'm more confused by the plugin list, but want to
actually live with it before making a decision!)

—
Reply to this email directly or view it on GitHub
#38 (comment).

skoczen · 2014-06-07T00:15:14Z

So, the team here thought that with the number of plugins we had, the list got too long, but agreed generally that grouping itself was good. So, here are my thoughts/plan:

a) I'm going to pull in the ^help fix now, since that's awesome.
b) I think the new structure that comes with #37 (plugins will be grouped into logical modules) may fit really well with what you're doing here, and once that hits, that should be a great foundation for this code.

So, with that, I'd say let's leave this PR open, and once 0.5 hits, revisit. How's that sound to you?

skoczen · 2014-06-07T00:48:31Z

Help fix has been released with 0.4.10!

bfhenderson · 2014-06-07T06:03:03Z

Cool! Yeah we can revisit after 0.5 for the help response formatting, will
be keeping it in our fork. Ultimately I think there will be a lot of
considerations going into help, mulling over #41 now.

I'll try to move feature brainstorming/communication more into github
issues before creating PR's directly in the future. That should help keep
the PRs better in tune with upstream goals.

On Fri, Jun 6, 2014 at 7:48 PM, Steven Skoczen notifications@github.com
wrote:

Help fix has been released with 0.4.10!

—
Reply to this email directly or view it on GitHub
#38 (comment).

bfhenderson · 2014-06-18T22:36:33Z

I'm closing this PR. Can create a new one for some of the other features, but for now its all kind of waiting on what 0.5 contains.

The next PR will

add help search
provide a user_help decorator, and allow for nested decorators
decouple some of the assumptions made in the help system
deprecates doc end-user documentation (but provides backward compatibility)

Considerations I'll need to see before issuing it:

admin commands - how closely aligned are they with "programmer" commands, can we get rid of "programmer" help?
new plugin module system, and generally what that means to help

Ubuntu and others added 20 commits May 8, 2014 16:10

add default plugin directory below project root, amend some default p…

aad70d8

…lugin

accept a plugins directory below project root

9b596db

slightly change some default plugin regexes

7bf87ee

allow override of 'help'

885c213

Merge branch 'master' of https://github.com/bfhenderson/will

ed77949

Merge remote-tracking branch 'upstream/master'

6eb8f0d

backout hardcoded plugin changes, add argparse for start_dev_will

1515c96

backout unecessary change to friendly plugin

ba2953f

allow the generated run_will.py to take arguments for plugins, templates

ac9cfd3

update documentation

6634892

use correct description for start_will.py

806d8e7

remove unecessary change to remind_me

cd6bbf9

improve argparse help

887807e

categorize plugin help by plugin type

4ffaf45

better help formatting

46e39d4

better help formatting

d3fce32

iterate correctly in help

caa1b4f

don't show plugins that don't have easy help

5e945bd

improve help format

9de5bac

yet another attempt at help formatting

d498db7

dpoirier reviewed Jun 4, 2014
View reviewed changes

some amendments based on feedback from greenkahuna/will pull request 38

112cdf1

skoczen reviewed Jun 4, 2014
View reviewed changes

bfhenderson reviewed Jun 4, 2014
View reviewed changes

bfhenderson added 2 commits June 4, 2014 15:43

Revert "improve argparse help"

3c97516

This reverts commit 887807e.

Revert "use correct description for start_will.py"

c7799b4

This reverts commit 806d8e7.

bfhenderson added 4 commits June 4, 2014 15:43

Revert "update documentation"

502db0b

This reverts commit 6634892.

Revert "allow the generated run_will.py to take arguments for plugins…

b862ed2

…, templates" This reverts commit ac9cfd3.

Revert "backout hardcoded plugin changes, add argparse for start_dev_…

17c0519

…will" This reverts commit 1515c96.

revert plugins hardcode

1e61bfc

bfhenderson added 4 commits June 17, 2014 14:13

simple help pattern matching

b667d7f

better help on

266298b

structured help data

bfa82cc

help plugin updated to use decorators, search terms

a9cab65

bfhenderson closed this Jun 18, 2014

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

allow command line arguments, limit help regex matching #38

allow command line arguments, limit help regex matching #38

bfhenderson commented Jun 3, 2014

dpoirier Jun 4, 2014

skoczen commented Jun 4, 2014

skoczen Jun 4, 2014

skoczen commented Jun 4, 2014

bfhenderson Jun 4, 2014

skoczen Jun 4, 2014

bfhenderson commented Jun 4, 2014

bfhenderson commented Jun 4, 2014

skoczen commented Jun 5, 2014

bfhenderson commented Jun 5, 2014

skoczen commented Jun 7, 2014

skoczen commented Jun 7, 2014

bfhenderson commented Jun 7, 2014

bfhenderson commented Jun 18, 2014

allow command line arguments, limit help regex matching #38

allow command line arguments, limit help regex matching #38

Conversation

bfhenderson commented Jun 3, 2014

dpoirier Jun 4, 2014

Choose a reason for hiding this comment

skoczen commented Jun 4, 2014

skoczen Jun 4, 2014

Choose a reason for hiding this comment

skoczen commented Jun 4, 2014

bfhenderson Jun 4, 2014

Choose a reason for hiding this comment

skoczen Jun 4, 2014

Choose a reason for hiding this comment

bfhenderson commented Jun 4, 2014

bfhenderson commented Jun 4, 2014

skoczen commented Jun 5, 2014

bfhenderson commented Jun 5, 2014

skoczen commented Jun 7, 2014

skoczen commented Jun 7, 2014

bfhenderson commented Jun 7, 2014

bfhenderson commented Jun 18, 2014