* Add pytest to requirements.txt
* Add pass-through option to run pytest in verbose mode
* Use various default pytest options
* Exclude merels bot for now
Previously the test-bots script filtered out base-class tests from
BotTestCase. With this change, BotTestCase continues to inherit from
unittest.TestCase, but the default test_* methods previously in this
class are now in a new DefaultTests class, which does not. Instead, each
bot needs to inherit from BotTestCase and DefaultTests *explicitly*.
This avoids the need to filter out the base-class tests, which
simplifies the test-bots script, and may ease any migration to eg.
pytest.
The DefaultTests class does require some non-implemented methods which
BotTestCase provides.
A lot of these bot dependencies are pretty hefty and shouldn't be
installed as part of the zulip_bots package. So the installation of
these belongs in tools/provision, not in setup.py.
This simplifies the usage of the script by eliminating the need to
pass --server=$SERVER and --token=$TOKEN in each call to the script.
Also renames key=>token for consistency.
This assumes that files passed in force_include without any extension are meant
to be run with mypy, and thus assumed to be python scripts.
Also, we ignore the most of the tools dir, except for the tools/deploy script
for which #349 adds type annotations.
This script interfaces with a Zulip Botfarm - a flask server that wraps
docker and runs Zulip bots using the docker engine. This allows for
remotely hosting bots for better uptime, and reduces the configuration
steps needed for safely hosting a bot online.
Now that zulip_bots is fully Python3, it makes sense to only
generate a Python3 wheel dist for it. zulip and zulip_botserver
are still distributed as a py2/py3 universal wheel.
Now that we do not use MANIFEST.in for zulip_bots, it doesn't
make sense to distribute sdists, because sdists don't pick up
data files specified in the package_data argument to setup().
Also, it isn't a huge deal if we don't distribute sdists for our
packages. Most PyPI projects only release wheels and pip will also
use wheels if available. So, this made sense!
This commit removes generate_manifest.py and package data files
are now included using the package_data kwarg to setup().
This is because, in certain situations, MANIFEST.in is a bit
finicky. For instance installing a package using:
python setup.py install
doesn't include files specified in MANIFEST.in, while using
pip install ./zulip_bots
does. package_data doesn't pose this problem, ergo it's better
for us.
The ability to update the zulip/requirements/* files in the main
zulip repo has now been made a part of its own subcommand.
To update the requirements to install the packages off of the
0.4.0 tag, run:
./release-packages ZULIP_DIR_PATH 0.4.0
To update the requirements to install the packages off of the
commit hash abcdefg, but the version to be 0.4.0, run:
./release-packages ZULIP_DIR_PATh 0.4.0 --hash abcdefg
This commit removes the following:
* This script's dependency on gitpython, it is not maintained actively.
* The ability to push changes in this and the main zulip/ repo. Doing
so automatically was turning out to be cumbersome and buggy and
doing it manually doesn't take significantly longer anyway.
* The ability to automatically increment PROVISION_VERSION in
zulip/version.py. Again, this was too buggy and it doesn't take
much longer to just increment it by hand.
Removing the above features made the script a lot easier to maintain
and read.
This commit fixes a couple of things:
* Removes the command line argument called release_version, now
one doesn't have to supply a version number when running just
running --cleanup, for instance.
* Run --cleanup before building the wheels and sdists. This is so
that outdated distributions are removed before generating new
ones.
* Set IS_PYPA_PACKAGE back to False at the end of the --build
process so that we don't accidentally set it to True. This was
a huge bug in the previous version of the script.
Wit.ai Bot communicates with the Wit.ai API. It can be configured with
any Wit.ai token and allows for setting up a custom handler function to
handle Wit.ai responses.
