[TangerineSDR] Webserver for local host

[Rob Wiesler]

ACK what's been said about Python, Python 3 vs. 2, and Flask.  I'm not
so vehemently against Java/JSP/Tomcat, but that's because I wasn't about
about to form a strong opinion against it if I wasn't the one writing
the web application.

... that said, please do not consider writing a web application where
the backend (running on the SBC) is written in Javascript (e.g. Node).
That entire software ecosystem is a nightmare, and actively resists
packaging and normal maintenance.

On Tue, Dec 03, 2019 at 19:34:38 +0000, Engelke, Bill via TangerineSDR wrote:
> It seems that Flask is often used in a container (i.e., venv).  How
> important is it to do this? Seems like an unnecessary complication for
> our application, especially if we are going to standardize on Python
> 3.

Nathan has already responded, but I'd like to follow up with a much
stronger response in the negative (which seems to be how this thread is
organized).

We absolutely must *not* use venv in a software package we intend to
distribute as part of an operating system.  Developers who insist on
using bleeding-edge versions of everything use venv to isolate
themselves from a dependency hell of their own creation in a way that
effectively generates a second, private dependency hell, and in the
process make it significantly harder to package their software.  We
avoid that by writing software that uses libraries packaged for a stable
operating system distribution.

> Documentation indicates (indeed, Flask itself gives a warning) that
> Flask (by itself) should not be run as a server "in a production
> environment." The advice is to run it under the control of a
> production WSGI such as Waitress (in fact, running under a venv).  Do
> we need to plan to do this?

Flask is a WSGI framework, not a web server.  It comes with a simple
HTTP server suitable for development only.  A proper WSGI HTTP server
should exist in front of it to handle requests.  Flask's tutorial
mentions Waitress (which is probably fine).  Apache with mod_wsgi is
another option.  For setups more complicated than ours, I like uwsgi.
Gunicorn is probably fine, too.  Avoid twisted at all costs.  Some WSGI
servers shouldn't be used to host Internet-facing websites - in this
case one would typically stick nginx in front of it (but TangerineSDR's
web interface won't be Internet-facing, so that's largely moot).

So, yes, plan on using Waitress.  Just don't stick it in a venv, and
don't rely on anything installed with pip, as opposed to apt-get (and
friends).

For example, my company's system uses uwsgi running in Emperor mode.  We
cobbled together a simple framework that allows multiple web
applications to coexist at the same time with different URI prefixes.
All customers have to do is drop an INI file and a directory containing
their webapp in a specific subdirectory of /srv/www, and uwsgi
automatically spots the new webapp, loads it, and serves it.  In order
to make this work without modifying uwsgi-emperor's global configuration
in /etc (because that's a bad thing to make a package do), we built a
new package containing a systemd unit that starts uwsgi in a custom way,
and gave it a dependency on uwsgi-core (instead of uwsgi-emperor).

For TangerineSDR, I envision a package built out something like this:
- A webapp written with Flask and Python3 in pretty much the way Flask
  tells you to do it, minus venv and pip (but including the setup.py
  file they have you write).  This will live in
  /usr/lib/python3/dist-packages, and be importable without editing the
  python path or changing the home directory.
- Dependencies on at least python3-flask and python3-waitress.
- A init script that calls waitress-serve (this will also work with
  systemd).