search

bootlin / elixir

The Elixir Cross Referencer
GNU Affero General Public License v3.0
937 stars 138 forks source link

cgi and cgitb dependencies are deprecated #297

Open fstachura opened 2 weeks ago

fstachura commented 2 weeks ago

Some tests (t/400-web.t) fail because this is printed into stderr:

stderr/usr/local/elixir/http/web.py:31: DeprecationWarning: 'cgitb' is deprecated and slated for removal in Python 3.13
  import cgitb
/usr/local/elixir/http/web.py:32: DeprecationWarning: 'cgi' is deprecated and slated for removal in Python 3.13
  import cgi

cgi and cgitb were indeed deprecated back in 2019: https://peps.python.org/pep-0594/#cgi Right now, we could move to legacy-cgi. This should get rid of the warnings.

While I think this is okay as a short-term solution, I'm wondering if we shouldn't move to wsgi/uwsgi in the long-term. The cgi model is pretty old and is not popular anymore, because starting a process for every request is not very efficient. On the other hand, I'm not sure if we can gain much from this, since the request handling process is only one of many processes Elixir starts for a typical request. (and since the main Elixir instance uses a cache).

Another potential upside of wsgi is that we could easily replace some code (like for example request path handling) with cleaner solutions offered by modern web frameworks.

tleb commented 2 weeks ago

Updated the title to make it more straight forward to understand.

That switch to legacy-cgi could be a quick fix. We need to make sure the maintainer of that is trustworthy, it is done being handled as part of the CPython project anymore.

I also agree with your analysis. The gain from avoiding a process per request is not that evident in our case. It might be, or it might not.

Also, this is not really urgent: it has worked for years (dozens of years?) and we don't need to run after "modern" and "clean" solutions. We have faced some performance issues from time to time in the past, related to web, but I have no data to be able to say where it came from.

Small incremental changes to improve the HTTP code would benefit the project anyway. Ideally when doing those we keep in mind that we might want to switch APIs. That way the potential future switch away from CGI is not a 100% rewrite of the code.