If a user provides both the name and the path to the bot
as input then we either will have to chose one of them
or alert the user to check the input. Selecting the latter
by sending an error message to the user.
Very few bots like followup bot directly call 'send_message'
function from the bot code. Since ExternalBotHandler class is
mocked, we'll have to mock 'send_message' function as well.
Added dummy field value of 'sender_email' for the message to be
as followup bot requires that field while processing
the message.
Since send_message is directly called from a specific bot's code,
so it can be sent to a different stream or under a different topic
than that of the incoming message. So, print the entire message
along with stream name.
A bot calling 'send_reply' function will reply to the incoming
message in the same stream under the same topic. So, only printing
bot's response message content for that.
This eliminates the need to setup dev environment and to
create a bot, setup zuliprc file, subscribe the bot to the
stream in order to try out a bot.
Manual command get-bot-output gives the bots response content
directly.
When testing bots with state and using type="all", it is expected that
the passed-in state will be applied for each source individually.
This commit moves away from alternating between sources for each test,
to running all the tests on each source with a copy of state_handler.
This is done so that Embedded bot system can also make use of
this function directly, as only id is needed in this function.
Tweaked by tabbott to have a cleaner interface and simpler
documentation.
get_bot_logo_path now first formats the path string with the name
of the bot before checking if the path exists. Not doing so is a
bug and causes the function to always return None.
This bot depends on PyDictionary, which isn't very well-implemented
or well-maintained. PyDictionary's dependency on goslate and
goslate's dependency on concurrent.futures has been known to cause
problems in Python 3 virtualenvs. This bot has also been the
source of disruptive BeautifulSoup warnings. Since this bot is only
meant to be an example bot, and for all the above reasons,
it makes sense to remove this bot. The cons of debugging the above
issues outweight the pros of having the bot at all.
As a package maintainer, I have to exclude the test fixtures in
MANIFEST.in so that they aren't shipped with the package release.
But for the repo, we need to include fixtures, logos and docs so
that Travis can run the tests after running
`pip install ./zulip_bots`.
Also, since we are installing zulip_bots off of this repo in our
main repo, docs and logos should be included so that they can be
rendered alongside our webhooks/integrations documentation, so we
need to include them in MANIFEST.in as well.
To automate this process, I just wrote this handy little script
that future bot contributors can run instead of having to manually
specify what to include in MANIFEST.in in the repo.
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.
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.
