On Tue, 30 Mar 2021, Ben Sturmfels wrote: > On Fri, 19 Mar 2021, Ben Sturmfels wrote:
>> 8. Either package RabbitMQ (probably hard) or rewrite MediaGoblin's >> processing backend from Celery/RabbitMQ to RQ/Redis. Celery has been >> implicated in many bugs anyway, so there may benefits to the project to >> doing this anyway. > > I learnt that Celery has a Redis backend, so maybe we don't need to > rewrite just yet. It turns out that MediaGoblin's Celery-based media processing backend work out of the box by simply configuring: [celery] BROKER_URL = "redis://" (There seems to be an unrelated bug where media is marked as failed after restarting Celery, possibly tied to sqlite. We've had reports of this with a RabbitMQ broker too though.) This means our shorter to-do list is now: 1. Upstream our new python-soundfile Guix package from guix-env.scm when core-updates is merged. 2. Upstream our upgraded python-wtforms package. 6. Convert MediaGoblin's jQuery-based JavaScript to use vanilla JS. Video and audio are essentially functional without the NPM installed players. Some later refinements perhaps. 4. Package MediaGoblin itself. The build process is ./configure/make which is a bit weird for a Python project. 5. Get a basic Guix service working, with sqlite3 and without the offloaded media transcoding currently using Celery task queue with a Redis broker. 7. Work out why H264 support is missing. 8. Figure out how to deal with translations. 9. Add a PostgreSQL database to the Guix service instead of sqlite3. Regards, Ben
