PgAdmin4 for Flatpak (RM #6523)

[dpage]

Issue migrated from Redmine: https://redmine.postgresql.org/issues/6523 Originally created by Karsten Lenz at 2021-06-09 10:25:44 UTC.

It would be helpful to have PgAdmin available for Flatpak, this will also include the Arch Linux based community where PgAdmin is a nightmare. On Arch the lates working version is 4.30, there is a non working 5.25 ARU Package which whill not compile.

With Flatpak it is possible add many Distributions with just one Flatpak package.

The Hardware support from for example Manjaro is fantastic comparing to other Distributions.

Regards

[dpage]

Comment migrated from Redmine: https://redmine.postgresql.org/issues/6523#note-1 Originally created by Rahul Shirsat at 2021-06-25 10:58:14 UTC.

Hi Dave,

Any thoughts on this?

Redmine ticket header update:

Name	Old Value	New Value
Assigned To changed		Dave Page

[dpage]

Comment migrated from Redmine: https://redmine.postgresql.org/issues/6523#note-2 Originally created by Aditya Toshniwal at 2021-07-02 11:34:59 UTC.

Redmine ticket header update:

Name	Old Value	New Value
Sprint changed		Ready
Priority changed	Normal	Low
Assigned To changed	Dave Page

[dpage]

Comment migrated from Redmine: https://redmine.postgresql.org/issues/6523#note-3 Originally created by Raimund Sacherer at 2021-08-13 13:22:22 UTC.

I am also eagerly awaiting a flatpak for pgadmin

[dpage]

Comment migrated from Redmine: https://redmine.postgresql.org/issues/6523#note-4 Originally created by Ludwid Reyes at 2022-04-07 05:59:54 UTC.

A flatpak would also greatly help Gentoo.

I'm not going to pretend to be an expert, so I hope I'm being accurate: it seems to me that there is an objection by Linux Distros of the inclusion of FEATURES="-network-sandbox" in order to compile newer versions of PGAdmin4 (6.7), so we're stuck on 4.30 which is dependent on flask-1 and not flask-2 which prevents the system from upgrading other packages.

The current solution that worked for me was using the Anaconda distribution of python to install it with pip, but it should work on any python virtual environment is my assumption.

Anaconda Installation: https://docs.anaconda.com/anaconda/install/linux/

upgraded anaconda : conda update --all

downgrade Jinja2 to 3.0.0 pip install jinja2==3.0.0

Install pgadmin4: pip install pgadmin4==6.7

edit config file: ~/anaconda3/lib/python3.9/site-packages/pgadmin4/config.py Change the paths for LOG_FILE,SQLITE_PATH,SESSION_DB_PATH, and STORAGE_DIR to somewhere in your home directory.

Then when you launch pgadmin4 it will prompt you for a username and password, and then you can point your browser to http://127.0.0.1:5050 while it's running.

To uninstall Anaconda (would also remove pgadmin4) if you ever wanted to: https://docs.anaconda.com/anaconda/install/uninstall/

[lestcape]

I don't know the state of this, but should probably be revisited. Rolling release distros are not included on the build system and pip is now blocked by some distros: https://github.com/python/cpython/issues/102134#issuecomment-1445428402 While the restriction can be avoided, I think that this is already too much and the need for a solution that covers all Linux environments is becoming evident. If for some reason it's not flatpak, could it be snap or could be an appimage? I have not real preference, but at less one:

https://snapcraft.io/ https://appimage.org/

[albertoridolfi]

Offering the software as a flatpak would lower the burden on developers and would broaden the distros in which the app will run. Instead of the devs needing to create multiple packages for multiple distributions and their multiple versions, devs would need to make just one package, and it will run everywhere. I was even thinking of volunteering myself to create a flatpak for pgAdmin4 but its stack seem complicated to me since I don't work with nodejs nor with the web front-end tech stuff that pgAdmin4 uses. But for pgAdmin4 devs, creating a flatpak would be a no-brainer. A lot easier than maintaining multiple builds for multiple versions of multiple distros.

https://docs.flatpak.org/en/latest/first-build.html

[faveoled]

I wrote the build files: org.pgadmin.pgadmin4.zip

If someone is interested they should provide an AppStream metadata file for the store. E.g. using this UI: https://www.freedesktop.org/software/appstream/metainfocreator/#/guiapp

Flatpak can be tested locally this way:

flatpak run org.flatpak.Builder --force-clean --sandbox --user --install --ccache builddir org.pgadmin.pgadmin4.yaml
flatpak run org.pgadmin.pgadmin4

[razzeee]

Should hopefully be pretty easy with https://www.freedesktop.org/software/appstream/metainfocreator/#/

[razzeee]

So I've added some metadata here https://github.com/razzeee/org.pgadmin.pgadmin4 and tested if it builds / did some cleanup.

It's basically good enought to be send to flathub, but there are two things:

1. I colud not get the regen-pip.sh script to work
2. It would be nice to update it to the latest version
3. It would be really great to have look into some more x data checker config https://github.com/flathub-infra/flatpak-external-data-checker/

[razzeee]

I guess it would also be nice to ship some versin of pg_dump etc, but I guess you can also change the sandbox and just use those from the host system. So it should still work fine.

[razzeee]

Started the process over at https://github.com/flathub/flathub/pull/5105

Takeaways so far:

• Metainfo should be upstream if possible, I've created this for now https://github.com/pgadmin-org/pgadmin4/pull/7333
• Can we get rid of the sed changes, remapping stuff
• Can we build from source and not the deb and can we enable arm builds then?

[faveoled]

Can we build from source and not the deb and can we enable arm builds then?

Doesn't look like ARM64 Linux is supported in NW.js (desktop app is based on it): https://github.com/nwjs/nw.js/issues/1151

[razzeee]

That's a shame, but then we can just skip arm - building from source still would be cool

[razzeee]

We have a first version on https://flathub.org/apps/org.pgadmin.pgadmin4

There are still some things we can improve, especially about the metadata

[adityatoshniwal]

That's a shame, but then we can just skip arm - building from source still would be cool

We moved from NW.js to Electron since many versions.