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)
These are from a list that Camilla Fox sent me of all
non-world-readable Zephyr classes currently configured.
(imported from commit 6246a981402b47056b28cd14be688e15224aacd1)
Steps needed:
- puppet apply on staging/prod when deployed to respective sites
- puppet apply on bots.z.n when deployed to prod
- copy /var/tmp/.feedback-bot-ticket-number from bots to staging
(imported from commit 2c943dac8d871809b0997a4484f508ec5b078bcd)
Have the Feedback Bot provide the sender's full name.
Put the email in the message to help searching.
Generate a ticket number to make it easier to refer to the message from
elsewhere.
(imported from commit 4d789135a0097bade50b4d980f49ca596d85b73b)
This requires renaming the account in Google Apps at the time we
deploy this; we'll probably want to do this during off hours to avoid
any user-visible downtime.
This also updates some related email addresses.
(imported from commit fce7629b359a4f278bbf7815c8d177a8fa0484fe)
This may require just doing an mv on the home directory, plus changing
the home directory in /etc/passwd. It should of course be done carefully.
(imported from commit 660997d897ee6d33563af74f0fc5d4267a911755)
