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.
Previously, if you didn't specify a list of `event_types` in either `register` or `call_on_each_event`, you'd get an exception due to the invalid event format.
This fixes#86.
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.