Drop last references to uWSGI

client/README.md

@@ -75,8 +75,7 @@ This will start up an extra client development server running on port 8081.
 Open your browser to http://localhost:8081 (instead of the default 8080 that
 Galaxy would run on), and you should see Galaxy like normal.  Except now, when
 you change client code it'll automatically rebuild *and* reload the relevant
-portion of the application for you.  Note that unlike previous versions of this
-functionality, it is no longer required to use uWSGI for this.  Lastly, if you
+portion of the application for you. Lastly, if you
 are running Galaxy at a location other than the default, you can specify a
 different proxy target (in this example, port 8000) using the GALAXY_URL
 environment variable:

doc/source/admin/migrating_to_gunicorn.md

@@ -1,13 +1,13 @@
 # Migrating from uWSGI to Gunicorn and FastAPI
 
-## Why do we migrate away from uWSGI
+## Why we migrated away from uWSGI
 
 Starting with Galaxy release 22.01 the default application webserver is [Gunicorn](https://gunicorn.org/), which replaces [uWSGI](https://uwsgi-docs.readthedocs.io/en/latest/).
-We have removed support for running Galaxy under uWSGI in Galaxy release 22.05.
-We have made this move because uWSGI support for newer Python versions has been problematic and because
+We removed support for running Galaxy under uWSGI in Galaxy release 22.05.
+We made this move because uWSGI support for newer Python versions has been problematic and because
 we have modernized the API portion of our backend. The Galaxy web application is now an ASGI application
 driven by [FastAPI](https://fastapi.tiangolo.com/) and [Starlette](https://www.starlette.io/).
-This will enable numerous important features in the future that would not be possible (or would be more complicated to set up)
+This enables numerous important features that were not be possible (or were more complicated to set up)
 otherwise. Importantly, [FastAPI's documentation](https://fastapi.tiangolo.com/tutorial/) is very good and
 should increase developer productivity.
 
@@ -25,22 +25,22 @@ of the Galaxy user interface. This would not be as simple under uWSGI.
 
 ## How do I upgrade my instance to use Gunicorn
 
-If you are using `run.sh` to start Galaxy and have not set up job handling via uWSGI mules,
+If you use `run.sh` to start Galaxy and have not set up job handling via uWSGI mules,
 you do not need to do anything to start Galaxy under Gunicorn.
 
 If you are using uWSGI mules, please read the [Scaling and Load Balancing documentation](scaling.md).
 You will most likely want to set up the **Gunicorn + Webless** strategy.
 
-If you are using an upstream proxy server such as NGINX or Apache and you've been
-using the uWSGI protocol, you need to replace `uwsgi_pass` and `mod_proxy_uwsgi`.
+If you use an upstream proxy server such as NGINX or Apache
+via the uWSGI protocol, you need to replace `uwsgi_pass` and `mod_proxy_uwsgi`.
 You can find detailed documentation in the [NGINX](nginx.md) and [Apache](apache.md)
 documentation.
 
-If you are managing your Galaxy server via Ansible, you can continue to run Galaxy
-under uWSGI while we are working on updating the Ansible roles for installing Galaxy.
+If you manage your Galaxy server via Ansible, you should continue to run Galaxy <=22.01
+while we are working on updating the Ansible roles for installing Galaxy.
 We will update instructions here and on the [Galaxy Training Network](https://training.galaxyproject.org/).
 
-If you are starting Web and Job Handlers using an external process manager like
+If you start web and job Handlers using an external process manager like
 systemd or supervisor, please read the [Scaling and Load Balancing documentation](scaling.md).
 In particular, you can use [gravity](https://github.com/galaxyproject/gravity) to generate supervisor configuration files
 that you can either use directly or as a basis to update your existing configuration.

doc/source/admin/mq.md

@@ -34,4 +34,4 @@ complete list of supported transports and their configuration.
 
 <!-- TODO Specify any requirements Galaxy has for transport features. -->
 
-<!-- TODO Specify what nodes need to be able to access the MQ (nginx proxy, uwsgi web, job handlers, workflow schedulers, compute nodes, etc?). -->
+<!-- TODO Specify what nodes need to be able to access the MQ (nginx proxy, web and job handlers, workflow schedulers, compute nodes, etc?). -->

doc/source/admin/scaling.md

@@ -26,14 +26,19 @@ The key to scaling Galaxy is the ability to run *multiple* Galaxy servers which
 ## Application Servers
 
 It is possible to run the Galaxy server in many different ways, including under different web application frameworks, or
-as a standalone server with no web stack. Prior to the 18.01 release, Galaxy (by default)
-used the [Python Paste][paste] web stack, and ran in a single process. Between the 18.01 release and the 22.01 release
-[uWSGI](https://uwsgi-docs.readthedocs.io/) was used as the default application server. Starting with the 22.01 release the default application server is
-[Gunicorn][Gunicorn]. For information about uWSGI in the Galaxy context please consult the version of this document that is
-appropriate to your Galaxy release.
+as a standalone server with no web stack.
 
-Gunicorn is able to serve ASGI applications. Galaxy can act as an ASGI web application since release 21.01,
-and we will drop support for being run as a WSGI application via uWSGI in Galaxy release 22.05.
+Starting with the 22.01 release the default application server is [Gunicorn][Gunicorn].
+Gunicorn serves Galaxy as an ASGI web application.
+
+### Historical note
+
+Prior to the 18.01 release, Galaxy (by default) used the [Python Paste][paste] web stack, and ran in a single process.
+Between the 18.01 release and the 22.01 release, [uWSGI](https://uwsgi-docs.readthedocs.io/) was used as the default
+application server.
+In release 22.05 we dropped support for running Galaxy as a WSGI application via uWSGI or paste.
+For more information about this, please consult the version of this document that is
+appropriate to your Galaxy release.
 
 [Gunicorn]: https://gunicorn.org/
 [paste]: https://paste.readthedocs.io/
@@ -74,14 +79,6 @@ Referred to in this documentation as the **Gunicorn + Webless** strategy.
 By default, handler assignment will occur using the **Database Transaction Isolation** or **Database SKIP LOCKED**
 methods (see below).
 
-### uWSGI for web serving with Mules as job handlers
-
-This strategy is deprecated and will be removed in Galaxy release 22.05.
-You can consult the documentation for older versions of Galaxy for details.
-
-If you're upgrading Galaxy to release 22.01 or newer we recommend you set up the
-**Gunicorn + Webless** strategy above.
-
 ## Job Handler Assignment Methods
 
 Job handler assignment methods are configurable with the `assign_with`
@@ -126,7 +123,7 @@ assignment method.
 
 ### Choosing an Assignment Method
 
-Prior to Galaxy 19.01, the most common deployment strategies (e.g. **uWSGI + Webless**) assigned handlers using what is
+Prior to Galaxy 19.01, the most common deployment strategies assigned handlers using what is
 now (since 19.01) referred to as *Database Preassignment*.  Although still a fallback option when the database
 does not support *Database SKIP LOCKED* or *Database Transaction Isolation*, preassignment has a few drawbacks:
 

lib/galaxy/app.py

@@ -631,8 +631,7 @@ class UniverseApplication(StructuredApp, GalaxyManagerApplication):
         # Heartbeat for thread profiling
         self.heartbeat = None
         self.auth_manager = self._register_singleton(auth.AuthManager, auth.AuthManager(self.config))
-        # Start the heartbeat process if configured and available (wait until
-        # postfork if using uWSGI)
+        # Start the heartbeat process if configured and available
         if self.config.use_heartbeat:
             if heartbeat.Heartbeat:
                 self.heartbeat = heartbeat.Heartbeat(

lib/galaxy/config/script.py

@@ -17,11 +17,6 @@ DESCRIPTION = "Initialize a directory with a minimal Galaxy config."
 HELP_CONFIG_DIR = "Directory containing the configuration files for Galaxy."
 HELP_DATA_DIR = "Directory containing Galaxy-created data."
 HELP_FORCE = "Overwrite existing files if they already exist."
-HELP_WSGI_SERVER = "Web server stack used to host Galaxy web application, and if uWSGI, which protocol to use."
-HELP_LIBDRMAA = (
-    "Configure Galaxy to submit jobs to a cluster via DRMAA by supplying the path to a libdrmaa.so file using this "
-    "argument."
-)
 HELP_INSTALL = "Install optional dependencies required by specified configuration (e.g. drmaa, etc...)."
 HELP_HOST = (
     'Host to bind Galaxy to - defaults to localhost. Specify an IP address or "all" to listen on all interfaces.'

lib/galaxy/dependencies/dev-requirements.txt

@@ -160,7 +160,6 @@ python-jose==3.3.0
 python-multipart==0.0.5
 python3-openid==3.2.0; python_version >= "3.0"
 pytz==2021.3; python_version >= "3.7" and python_full_version < "3.0.0" or python_full_version >= "3.5.0" and python_version < "4" and python_version >= "3.7"
-pyuwsgi==2.0.20
 pyyaml==6.0; python_version >= "3.6"
 pyzmq==22.3.0; python_version >= "3.6"
 rdflib==6.0.2; python_version >= "3.7" and python_version < "4"

lib/galaxy/dependencies/pinned-requirements.txt

@@ -121,7 +121,6 @@ python-jose==3.3.0
 python-multipart==0.0.5
 python3-openid==3.2.0; python_version >= "3.0"
 pytz==2021.3; python_version >= "3.7" and python_full_version < "3.0.0" or python_full_version >= "3.5.0" and python_version < "4" and python_version >= "3.7"
-pyuwsgi==2.0.20
 pyyaml==6.0; python_version >= "3.6"
 pyzmq==22.3.0; python_version >= "3.6"
 rdflib==6.0.2; python_version >= "3.7" and python_version < "4"