[TangerineSDR] Webserver for local host

[Rob Wiesler]

On Tue, Dec 03, 2019 at 18:38:57 +0000, Engelke, Bill via TangerineSDR wrote:
> Let's gravitate toward Python then.  The framework that Evan mentioned
> (Flask) does seem to be of a lightweight variety, and should allow us
> to implement all the screens we need for controlling the TangerineSDR.
> (I have attached the latest version of the Detailed Design for what is
> planned to run in the SBC for review and comment.  My idea is to
> implement all the web screens in the spec using whatever framework we
> pick).

Any chance the specification could end up in plain text or PDF?

> One question, to try and avoid "interdependency hell" – the latest
> GNUradio runs well with Python V3.6.9. (I’m hoping we can avoid using
> Python2, as I have seen a continuous feed of warnings that support is
> phasing out).   I hope that Flask plays nice with Python3 (??)

It's been converted for years.  The Debian package is python3-flask.


Okay, for fun only, here's the full story on Python 2 deprecation and
support (which are different matters).  The tl;dr is that we shouldn't
have any issues with Python 3, so we should only write Python 3, and
anything we need that's Python 2-only will need to be converted anyway
(I haven't seen anything so far).

- The Python project is dropping support for Python 2 at the end of the
  month.  Then again, it wouldn't be the first super-mature software
  package to end up being supported completely by some combination of
  Debian, Ubuntu, Fedora, and OpenSUSE for over a decade after being
  dropped by its own upstream.

- Debian is in the middle of removing Python 2 versions of its packages
  as quickly as possible without breaking too many things at the same
  time.  This is resulting in a lot of packages being dropped from the
  archive for bullseye (the next stable release, due to release sometime
  around May 2021) (all of these packages remain in current stable,
  minus a handful that are broken for other reasons).  They may or may
  not manage to remove everything, but AFAIR the goal is to continue
  support for Python 2 through current stable (buster), plus a year
  after the transition to bullseye (so, mid-2022).

- Ubuntu 18.04 LTS ("Bionic Beaver") continues to ship Python 2
  packages.  It'll go out of support in April 2028.  For all practical
  purposes, that means Python 2 will have some sort of support for
  another eight years at least.  This seems a little insane to me, but
  Python 2 is really quite mature, so maybe it'll work out?

- Some individuals have infamously claimed to be willing to and capable
  of supporting Python 2 indefinitely by themselves.  Those individuals
  lave largely relented, and ported their software to Python 3.

- There's at least one fork of Python 3 that claims full backwards
  compatibility with Python 2.  I am not telling you its name so as not
  to tempt anyone into actually using it (it's a bit of a kludge).  As
  far as I know, nobody's been crazy enough to try packaging it for
  Debian.

Again, despite plenty of support for Python 2 past 2020 (upstream
notwithstanding), there's basically no reason to write any new code in
it (*), and a lot of reasons to avoid Python libraries that aren't
compatible with Python 3.

*: If I could `from __past__ import division`, I would, and a lot of
   code really doesn't deal well with raw bytes anymore without dumb
   workarounds.  That's basically it.