This commit does the following:
* Minor improvements to the writing wherever possible.
* Replace links to screenshots with links that would work when
rendering said screenshots on the main repo. This would mean
the screenshots won't be rendered outside the main repo.
* Adds a section that links to our Bots Guide's How to run a bot
tutorial by using a Markdown a macro.
These functions were rendered redundant by changes in our
approach on how the main repo renders docs and logos contained
in the zulip_bots package (see #6103). So, these should now be
removed.
This allows a user to exclusively enter a bot's name or a bot's
directory as the first and only positional argument. Therefore,
no complicated checks for multiple bot specifications are required
anymore.
Additionally, this cleans help messages and makes arguments more
accessible.
This allows a user to exclusively enter a bot's name or a bot's
directory as the first and only positional argument. Therefore,
no complicated checks for multiple bot specifications are required
anymore.
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.
