actions: Delete zerver.lib.actions.

Signed-off-by: Anders Kaseorg <anders@zulip.com>

analytics/lib/counts.py

@@ -288,7 +288,7 @@ def do_aggregate_to_summary_table(
 
 ## Utility functions called from outside counts.py ##
 
-# called from zerver/lib/actions.py; should not throw any errors
+# called from zerver.actions; should not throw any errors
 def do_increment_logging_stat(
     zerver_object: Union[Realm, UserProfile, Stream],
     stat: CountStat,

docs/contributing/code-style.md

@@ -155,7 +155,7 @@ object before the first thread wrote out its change.
 
 ### Using raw saves to update important model objects
 
-In most cases, we already have a function in zerver/lib/actions.py with
+In most cases, we already have a function in `zerver.actions` with
 a name like do_activate_user that will correctly handle lookups,
 caching, and notifying running browsers via the event system about your
 change. So please check whether such a function exists before writing

docs/overview/directory-structure.md

@@ -23,7 +23,7 @@ paths will be familiar to Django developers.
 
 - `zerver/lib/*.py` Most library code.
 
-- `zerver/lib/actions.py` Most code doing writes to user-facing
+- `zerver/actions/*.py` Most code doing writes to user-facing
   database tables lives here. In particular, we have a policy that
   all code calling `send_event` to trigger [pushing data to
   clients](../subsystems/events-system.md) must live here.

docs/production/management-commands.md

@@ -91,12 +91,12 @@ database, for most objects, in addition to saving the changes to the
 database, one may also need to flush caches, notify the apps and open
 browser windows, and record the change in Zulip's `RealmAuditLog`
 audit history table. For almost any data change you want to do, there
-is already a function in `zerver.lib.actions.py` with a name like
+is already a function in `zerver.actions` with a name like
 `do_change_full_name` that updates that field and notifies clients
 correctly.
 
-For convenience, Zulip automatically import `zerver/models.py` and
-`zerver/lib/actions.py` into every management shell; if you need to
+For convenience, Zulip automatically imports `zerver/models.py`
+into every management shell; if you need to
 access other functions, you'll need to import them yourself.
 
 ## Other useful manage.py commands

docs/subsystems/management-commands.md

@@ -51,7 +51,7 @@ project.
   (and ideally, also used in Zulip's existing code). Look for code in
   `zerver/lib/` that already does what you need. For most actions,
   you can just call a `do_change_foo` type function from
-  `zerver/lib/actions.py` to do all the work; this is usually far
+  `zerver/actions/` to do all the work; this is usually far
   better than manipulating the database directly, since the library
   functions used by the UI are maintained to correctly live-update the
   UI if needed.

docs/testing/testing.md

@@ -32,7 +32,7 @@ because it takes a long time. Instead, your edit/refresh cycle will
 typically involve running subsets of the tests with commands like these:
 
 ```bash
-./tools/lint zerver/lib/actions.py # Lint the file you just changed
+./tools/lint zerver/models.py # Lint the file you just changed
 ./tools/test-backend zerver.tests.test_markdown.MarkdownTest.test_inline_youtube
 ./tools/test-backend MarkdownTest # Run `test-backend --help` for more options
 ./tools/test-js-with-node util

docs/tutorials/writing-views.md

@@ -242,7 +242,7 @@ change the server more than once or cause unwanted side effects.
 ### Making changes to the database
 
 If the view does any modification to the database, that change is done
-in a helper function in `zerver/lib/actions.py`. Those functions are
+in a helper function in `zerver/actions/*.py`. Those functions are
 responsible for doing a complete update to the state of the server,
 which often entails both updating the database and sending any events
 to notify clients about the state change. When possible, we prefer to

scripts/lib/pythonrc.py

@@ -2,7 +2,6 @@ try:
     from django.conf import settings  # noqa: F401
 
     from analytics.models import *  # noqa: F401, F403
-    from zerver.lib.actions import *  # noqa: F401, F403
     from zerver.models import *  # noqa: F401, F403
 except Exception:
     import traceback

tools/linter_lib/custom_check.py

@@ -374,7 +374,7 @@ python_rules = RuleList(
         },
         {
             "pattern": "get_stream[(]",
-            "include_only": {"zerver/views/", "zerver/actions/", "zerver/lib/actions.py"},
+            "include_only": {"zerver/views/", "zerver/actions/"},
             "exclude_line": {
                 # This one in check_message is kinda terrible, since it's
                 # how most instances are written, but better to exclude something than nothing

tools/test-queue-worker-reload

@@ -88,7 +88,7 @@ if __name__ == "__main__":
     time.sleep(1.3)
 
     print("Attempting to modify a file")
-    os.utime("zerver/lib/actions.py")
+    os.utime("zerver/models.py")
     failed = check_worker_launch(run_dev)
 
     run_dev.send_signal(signal.SIGINT)

zerver/lib/actions.py

@@ -1 +0,0 @@
-

zerver/tornado/django_api.py

@@ -149,7 +149,7 @@ def send_notification_http(realm: Realm, data: Mapping[str, Any]) -> None:
 # The core function for sending an event from Django to Tornado (which
 # will then push it to web and mobile clients for the target users).
 # By convention, send_event should only be called from
-# zerver/lib/actions.py, which helps make it easy to find event
+# zerver/actions/*.py, which helps make it easy to find event
 # generation code.
 #
 # Every call point should be covered by a test in `test_events.py`,