scripts: Rename inline-email-css to inline_email_css.py.

This is a preparatory step for making it a module that we can import
and call from other code.

docs/development/setup-advanced.md

@@ -159,7 +159,7 @@ yarn install
 sudo mkdir /srv/zulip-emoji-cache
 sudo chown -R `whoami`: /srv/zulip-emoji-cache
 ./tools/setup/emoji/build_emoji
-./scripts/setup/inline-email-css
+./scripts/setup/inline_email_css.py
 ./tools/setup/build_pygments_data
 ./tools/setup/generate_zulip_bots_static_files.py
 ./scripts/setup/generate_secrets.py --development

docs/subsystems/email.md

@@ -85,7 +85,7 @@ EmailMessage instance for each message that would be sent.
 
 Other notes:
 * After changing any HTML email or `email_base.html`, you need to run
-  `scripts/setup/inline-email-css` for the changes to be reflected in the dev
+  `scripts/setup/inline_email_css.py` for the changes to be reflected in the dev
   environment. The script generates files like
   `templates/zerver/emails/compiled/<template_prefix>.html`.
 ## Email templates
@@ -103,13 +103,13 @@ two copies of each email (plain-text and HTML).
 So for each email, there are two source templates: the `.txt` version
 (for plain-text format) as well as a `.source.html` template.  The
 `.txt` version is used directly; while the `.source.html` template is
-processed by `scripts/setup/inline-email-css` (generating a `.html` template
+processed by `scripts/setup/inline_email_css.py` (generating a `.html` template
 under `templates/zerver/emails/compiled`); that tool (powered by
 `premailer`) injects the CSS we use for styling our emails
 (`templates/zerver/emails/email.css`) into the templates inline.
 
 What this means is that when you're editing emails, **you need to run
-`scripts/setup/inline-email-css`** after making changes to see the changes
+`scripts/setup/inline_email_css.py`** after making changes to see the changes
 take effect.  Our tooling automatically runs this as part of
 `tools/provision` and production deployments; but you should bump
 `PROVISION_VERSION` when making changes to emails that change test
@@ -132,7 +132,7 @@ translators to not have to deal with multiple versions of each string
 in our emails.
 
 One can test whether you did the translating part right by running
-`scripts/setup/inline-email-css && manage.py makemessages` and then searching
+`scripts/setup/inline_email_css.py && manage.py makemessages` and then searching
 for the strings in `locale/en/LC_MESSAGES/django.po`; if there
 are multiple copies or they contain CSS colors, you did it wrong.
 

templates/zerver/dev_tools.html

@@ -41,7 +41,7 @@
                 </tr>
                 <tr>
                     <td><a href="/emails">/emails</a></td>
-                    <td><code>./scripts/setup/inline-email-css</code><br/>
+                    <td><code>./scripts/setup/inline_email_css.py</code><br/>
                         Run the command if you made changes to source.html email templates.
                     </td>
                     <td>View outgoing and example emails.</td>

tools/lib/provision_inner.py

@@ -134,12 +134,12 @@ def main(options: argparse.Namespace) -> int:
     else:
         print("No need to run `tools/setup/build_pygments_data`.")
 
-    email_source_paths = ["scripts/setup/inline-email-css", "templates/zerver/emails/email.css"]
+    email_source_paths = ["scripts/setup/inline_email_css.py", "templates/zerver/emails/email.css"]
     email_source_paths += glob.glob('templates/zerver/emails/*.source.html')
     if file_or_package_hash_updated(email_source_paths, "last_email_source_files_hash", options.is_force):
-        run(["scripts/setup/inline-email-css"])
+        run(["scripts/setup/inline_email_css.py"])
     else:
-        print("No need to run `scripts/setup/inline-email-css`.")
+        print("No need to run `scripts/setup/inline_email_css.py`.")
 
     if not options.is_production_travis:
         # The following block is skipped for the production Travis

tools/update-prod-static

@@ -43,7 +43,7 @@ setup_node_modules(production=True, stdout=fp, stderr=fp)
 run(['./tools/setup/emoji/build_emoji'], stdout=fp, stderr=fp)
 
 # Inline CSS in emails
-run(['./scripts/setup/inline-email-css'], stdout=fp, stderr=fp)
+run(['./scripts/setup/inline_email_css.py'], stdout=fp, stderr=fp)
 
 # Copy over static files from the zulip_bots package
 run(['./tools/setup/generate_zulip_bots_static_files.py'], stdout=fp, stderr=fp)

zerver/management/commands/send_custom_email.py

@@ -38,19 +38,19 @@ def send_custom_email(users: List[UserProfile], options: Dict[str, Any]) -> None
         with open(markdown_email_base_template_path) as base_template:
             # Note that we're doing a hacky non-Jinja2 substitution here;
             # we do this because the normal render_markdown_path ordering
-            # doesn't commute properly with inline-email-css.
+            # doesn't commute properly with inline_email_css.
             f.write(base_template.read().replace('{{ rendered_input }}',
                                                  rendered_input))
 
     with open(subject_path, "w") as f:
         f.write(options["subject"])
 
-    # Then, we compile the email template using inline-email-css to
+    # Then, we compile the email template using inline_email_css to
     # add our standard styling to the paragraph tags (etc.).
     #
     # TODO: Ideally, we'd just refactor inline-email-css to
     # compile this one template, not all of them.
-    subprocess.check_call(["./scripts/setup/inline-email-css"])
+    subprocess.check_call(["./scripts/setup/inline_email_css.py"])
 
     # Finally, we send the actual emails.
     for user_profile in users:

zerver/views/development/email_log.py

@@ -50,7 +50,7 @@ def generate_all_emails(request: HttpRequest) -> HttpResponse:
         # here, since that saves a step when testing out changes to
         # the email CSS.  But we don't run this inside the test suite,
         # because by role, the tests shouldn't be doing a provision-like thing.
-        subprocess.check_call(["./scripts/setup/inline-email-css"])
+        subprocess.check_call(["./scripts/setup/inline_email_css.py"])
 
     # We import the Django test client inside the view function,
     # because it isn't needed in production elsewhere, and not