This tool is a little crude; it runs out of a cron job and will
forward to staging a notice about any new lines in the declared log
files, truncating if there are more than 10 lines.
(imported from commit 6748ddff1def0907b061dc278a3a848bd2e933f1)
This will allow us to substantially decrease the server-side work that
we do to support our Mirroring systems (since the personal mirrors can
request only messages that user sent) and also is what we need to
support a single-stream Zulip widget that we embed in webpages.
(imported from commit 055f2e9a523920719815181f8fdb44d3384e4a34)
This way command-line scripts that use our `optparse` populator can
still specify a custom client without munging their `parser` object.
(imported from commit df8d28a46a4d4574523b106030dbfed2d9ac931e)
We previously sent our client type to the server as a GET/POST parameter
of "client=<something>", most commonly "client=API: Python".
We switch here to providing the same information as a User-agent header
sent on each request, which is more standards-compliant.
Also added is some data about the platform the user is using. If your
client string was set to "MyLittleZulip/1.0", the resultant string could
look something like this:
MyLittleZulip/1.0 (Ubuntu; 12.04)
(imported from commit 39fd187a8f9d4b3c9b63fc623e0836e57a4099ca)
This is designed to be run as a "change-commit" trigger. See [Perforce's
documentation][1] on how to set up a trigger for your platform.
[1]: http://www.perforce.com/perforce/r12.1/manuals/cmdref/triggers.html
Closes trac #1034.
(imported from commit d94fa4e50637ade2847a96eab8c5514de3811c24)
Since we're using the module outside of a git repository context we
don't have a git config to reference. Instead, we'll just use the
environment variables we're passed.
(imported from commit 8ae707d5d60eb700052e0ee89e7d36c660e00bb6)
Previously, users of setuptools would get our data embedded in eggs.
Eggs are horrible things, but more importantly our package data should
be free, in a well-known albeit system-dependant path that is
independent of the package.
By specifying [install_data][1] as an alias of install, we assure that
our data (examples, integrations, etc) are placed in $data/share as
$DEITY intended.
Alternative suggestions included force-adding "--old-and-unmanageable",
which would invoke the distutils-style install command, but that had the
unfortunate side effect of turning off eggs and dependency resolution
altogether.
We could also use "--single-version-externally-managed", but I think
that was designed to be used by package managers, not by us.
In any case, both of the above were fragile and might break if the user
specified additional options to setup.py.
In closing, Python module management is horrible. See [this][2],
[this][3], and [this][4] for info about the status quo, and [this][5]
for information about crack to be smoked later down the road. Don't even
get me started about [PEP 427 -- Python wheels][6].
[1]: http://docs.python.org/2/distutils/commandref.html#install-data
[2]: http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-everywhere/
[3]: http://stackoverflow.com/a/6522905/90777
[4]: http://python-notes.boredomandlaziness.org/en/latest/pep_ideas/core_packaging_api.html
[5]: https://python-packaging-user-guide.readthedocs.org/en/latest/future.html
[6]: http://www.python.org/dev/peps/pep-0427/
(imported from commit 6cf1bd2b8f5a60b2f02f5d11094e4a41cc5e48aa)
Due to limitations in their API, we have to poll and check for
creation and completion events.
(imported from commit be65e507fac16a7f8ad3dc57b2af9c4b98aacf39)
We still need it in integrations, because those don't require Python
2.7, but we don't need it in any of our code that runs on internal
servers.
(imported from commit 3c340567f1a372dcb4206c6af9a6e5e18005b1b8)
