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.
