This is part of our efforts to have the documentation for a
particular bot live in this repo but still be able to render it
in the main repo (in a way similar to how we render the webhooks
docs).
This function allows us to specify the path to a bot's doc.md file
in zerver.lib.integrations.BotIntegration.
doc.md better describes the style of documentation that will live
inside these files, since we want these to be similar to our
webhooks' doc.md files in terms of how these are rendered and
composed of Markdown macros.
This is part of our efforts to have the documentation for a
particular bot live in this repo but still be able to render it
in the main repo (in a way similar to how we render the webhooks
docs).
This function allows the calling code to get the absolute path
to the bots/ directory. This will allow us to specify an
arbitrary path (jinja2.env.loader.searchpath)
to look for templates for bots' documentation.
This is part of our efforts to have the documentation for a
particular bot live in this repo but still be able to render it
in the main repo (in a way similar to how we render the webhooks
docs).
For the logo, if a particular bot has a logo, get_bot_logo_path
expects to find it as /zulip_bots/bots/{bot_name}/logo.png or
/zulip_bots/bots/{bot_name}/logo.svg.
The help message string was modified in yoda.py file to correctly
instruct the user. But the help message string was not modified
accordingly in the test file.
In case of an errored input (not consistent with the format
of input that the bot seeks), Converter bot was displaying the
errored part first, along with the error message.
This can lead to many failure, if removing_at_mention function
is not working properly then the input '@bot-name 2 m cm' leads
to the bot getting stuck in infinite loop as converter bot will
want to output '@bot-name not a valid number' and hence calling
itself again.
Add error handling support for empty messages and invalid
input to yoda bot, which was previously making the bot crash.
Add comments to describe tests.
With the new repo, doing a `pip install -e ./zulip` will be a part
of the core workflow. This mitigates the risk of developers
accidentally testing their changes against an installed copy of the
zulip package rather than the copy in their checkout. Therefore,
we can now get rid of the various `sys.path.inserts` in the examples.
This adds support to check and raise a BadRequest when either the
configuration of bot couldn't be found or the BotHandler code of bot
couldn't be fetched. There can be cases where flaskbotrc contains config
details of a bot, but the user hasn't added it's handler class code. This
fixes server to handle such cases, by reporting it to user.
This also fixes the response of bot server to make it possible to skip
the response message.
Since we want our bots to be both python 2 and python 3 compatible,
we use six to make up for both of them and run the bot smoothly.
'http.client' was basically used for error-handling by the author
of the bot, urllib errors can be handled by the urllib itself. So,
using this for simplicity.
urllib.request.urlopen raises URLError on protocol errors.
Instead of discovering unit tests using loader.discover() by passing
it a set of starting and top level directories, we now discover
unit tests by loading them from specific test module objects. This
makes it easier to include and exclude specific bots from testing.
The zulip-run-bot script now supports passing in a --path-to-bot
option. This allows users to specify the path to the source file
for their own custom bots, the first step towards being able to
support out-of-tree bots.
To run an existing bot in the zulip_bots package, just passing in
the name of the bot should suffice.
There is no library as 'http.bot_handler'.
'http.client' is what the author of this bots initially wrote.
Searching through the git history shows that someone mistakenly
replaced 'client' with 'bot_handler' here.
