Before this change, we were looking for config files in
default locations in source control, which is not a good
place to look for them. Now `run.py` and friends have a
command line argument where users can specify the config
files.
Note that the change to server.py is only a partial fix
to make it so that bots that don't use third party config
files won't crash. That program needs an overhaul, anyway.
This patch is particularly useful in the scenario that your
API key is wrong or out of date, but it's targeted more
generally at any error that `client.get_profile()` reports.
The API has aggressive retry logic for connecting to a
server, which may make sense for situation where you have
connection blips or server restarts.
When you're first connecting to the API, however, connection
failures are almost certainly a sign of misconfiguration, so
now we fail fast.
The bot lib takes advantage of this API change by catching the
ZulipError exception and exiting gracefully.
Before this commit, you would get a traceback if you supplied
a non-existent filename for your config file. Now we exit
gracefully with a useful error message.
We now require users to specify where their config file is
located, and we no longer default to ~/.zuliprc.
As part of this, we needed to make the "usage" more accurate
in the command line, which I mostly achieved by cutting out
unnecessary stuff.
This makes the StateHandler functional. To reduce the
number of server roundtrips when fetching/updating the
state, the entire state is fetched ocne at bot
initialization and cached. All changes are stored in the
cache and only saved externally after handle_message()
has been executed.
Fixes#141.
With this change, StateHandler.put() does only accept JSON-able
objects by default. The incrementor test tried to store the return
value of send_reply(), a non-JSON-able MockObject, in the state.
Therefore, this commits also sets functional default test return
values for send_message() and send_reply().
Finally, it fixes the tictactoe bot which relied on directly
modifying the state_ attribute.
unittest includes by default all module-level classes that inherit
from TestCase and implement at least one method starting with 'test'.
Since it doesn't provide a convenient way for excluding TestSuites,
we need to manually filter out the unwanted testing of our test base
class itself.
No bot is dependant on this module. No
future bot should be dependant on it,
since it is not a bot itself and is thus
blurring the structure of the bots dir.
This simplifies testing stateful bots by integrating the StateHandler
into the test library. As a side-effect, the mock bot handler gets
reused during a test, making the tests more realistic. The
StateHandler now keeps its state during a call to check_expected_responses,
forcing some stateful tests to be more verbose and explicit.
The Zulip server, starting in 1.7, no longer sends
`is_mentioned` in the message payload, and it was buggy in
earlier versions, so now we check `flags`.
This commit adds a script to automate the PyPA release of the
zulip, zulip_bots and zulip_botserver packages.
The tools/release-packages script would take care of uploading
the packages to PyPA, and push commits to both repos updating the
package versions. If you have commit access to the repos, you
can --push upstream to master. If not, then you can --push
origin to a new branch on your fork and create a PR for those
changes.
Ideally, a release shouldn't take longer than however long it
takes one to type the above command. If you have SSH set up on
GitHub, you won't need to type in your GitHub username and
password. You can also store your PyPA credentials in a file
in your home directory; it isn't very secure, but it saves
time nevertheless.
In zulip_bots/setup.py, we now don't specify a minimum version when
checking for dependency on the zulip package. We just want the
latest one.
In zulip_botserver/setup.py, we now don't specify a minimum version
when checking for dependencies on the zulip and zulip_bots package.
We just want the latest ones.
We now have a custom command in zulip_bots/setup.py to generate
a MANIFEST.in. To generate a MANIFEST for a PyPA release, we
can now run:
python setup.py gen_manifest --release
To generate a non-release MANIFEST, we can run:
python setup.py gen_manifest
This allows us to automate the MANIFEST generation in our
release automation script.
The generate_manifest.py script now takes a --release argument
that generates a separate MANIFEST for a PyPA release that
include:
* doc.md files
* related assets/* files
A release MANIFEST doesn't include logos and fixtures.
A non-release MANIFEST includes everything.
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.
