Closed Bug 1694598 Opened 8 months ago Closed 8 months ago

Having Pontoon installable on "standard" Linux Distro


(Webtools Graveyard :: Pontoon, defect)



(Not tracked)



(Reporter: mozilla, Assigned: mozilla)



(2 files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

To allow more people to use Pontoon, it should be easier to install on "standard" Linux distro. This can be achieved by:

  • Having a step-by-step installation documentation,
  • Having Pontoon effectively working with Python and Postgres versions available on those distro.

I noted the Python and Postgres version available on currently supported version of Debian and Ubuntu (with the exception of Debian 9 and Ubuntu 16.04 LTS that are too old):

| Distribution | End of support | Python | Postgres |
| Debian 10 (buster) | → 2024-06 | 3.7 | 11 |
| Debian 11 (bullseye) | → ? | 3.9 | 13 |
| Ubuntu 18.04 LTS (bionic) | → 2023-04 | 3.6, 3.7 | 10 |
| Ubuntu 20.04 LTS (focal) | → 2025-04 | 3.8 | 12 |
| Ubuntu 20.10 (groovy) | → 2021-07 | 3.8, 3.9 | 12 |
| Ubuntu 21.04 (hirsute) | → 2022-01 | 3.9 | 13 |

So it seems that Python 3.7 → 3.9 and PostgreSQL 10 → 13 should be supported by Pontoon to make it installable on most today Linux distro (I think other distro use the same range of version).

I already wrote a Github Actions workflow to test a fresh Pontoon install on a matrix of Python and Postgres version (py37-py39 * pg9-pg13):

Actual results:

Currently, I have the following results:

Expected results:

Pontoon dependencies should be installable with Python 3.7 and db migrations should work on all Postgres version, not only the 11.

Thanks for filing the bug! I'm assigning it to you. :)

Cool work with the GitHub Actions!

Note that importlib-metadata in no longer required for python >= 3.8:

And perhaps this could help with the migration issue:

Assignee: nobody → mozilla
Ever confirmed: true

I've started looking into the migrations issue, and there's a few things I take away so far:

We need to change the way we do migrations. Schema migrations and data migrations need to go into different files, instead of consecutive operations in the same one.

We have a few affected apps right now:

base, checks, homepage, sync, tour.

Checks is easy, we can just "squash" the data migrations into the initial model generation. It's removing data that we added first.

Base is hard. But I have tacky ideas like using consecutive migrations, and moving the schema changes of the second into the first, and the data changes of the first into the second. The initial migration is full of back and forth, so I'm tempted to just apply the first two, and then confuse django into generating a schema migration from scratch. Yuck.

Homepage is "interesting". I think we can avoid the datamigration of adding a default homepage by loading that in the view if there's none set. Otherwise we need to add a second migration (there's currently only one), that only adds a homepage if there's none yet.

Sync is easy if I get permission to do the double-migration hack. It has two migrations, and the second is data-only. Same for Tour. Those are just moving the data parts of the first into the second.

PS: Base has pure data migrations in 4, 5, and 9. Those are OK as is.

PPS: Tour has only data migrations, so it's not part of the migration work I'm doing in 1881.

Re python 3.7, this is probably something we'd fix by running pip-compile on a 3.7 install. I'm not sure if that's a good idea, though. It'd basically mean that we'll need to roll back both development and heroku deployment to 3.7, which is now on 3.8.

I made a PR that adds a Github Actions workflow to check that Pontoon is installable on standard Linux distro.

As we discussed on the chat, I removed Python 3.7 from the matrix, I will make a maintainer patch for my .deb package to support it for Debian 10 and Ubuntu 18.04 LTS :)

Sometimes it takes something really tangible to look at to see the implications. I'm sorry that this is one of those.

We've only looked at Heroku and docker to empower third-party deployments, and docker is already on the back-burner.

Adding native linux deployments is an extension of scope, even more so if it's a matrix of supported versions that are hard to test locally. There's also a ton of subtle changes in OSes that could trigger errors.

Pontoon's development also implies that there's at least four services running (web, db, sync, memcached), which limits the impact a single-machine-install can have.

I checked in with Matjaz, and we agreed that the Pontoon project can't lift the support for a third deployment mechanism.

The exercise here was useful, as it helped us to find problems we'll face when upgrading PostgresQL. That's a good thing, thanks for that.

Accordingly, I'm closing this bug as WONTFIX.

I did spin my head in a few ways. One thing we could've done is going for a native package, and do docker and heroku via installing that package. Sadly, that requires a package registry and build automation dependencies, and that's not something I'd be up to setting up. FTR, GH registry doesn't do linux packages to begin with.
I wonder if snaps would be a way for someone to build packages to install on bare metal. Snaps would take care of a lot of the matrix of dependencies. But I have no idea of services in snaps are a thing to begin with. I stopped that train of thought quickly, too.

Closed: 8 months ago
Resolution: --- → WONTFIX

Thanks for clarifying, Axel.

And sorry for not calling out our 3rd party deployment strategy earlier in the process, Flozz!

I'll close the PR.

Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.