Note that many pip-based installations also have the tarball too. Example, in the source distribution: gramps-web-desktop · PyPI
I’m interested in this thread also! The Docker method seems to assume that is the only app that will be running on the server and that is not usually the case. Most servers host multiple websites.
If you wish, you can follow my progress or help out at: GitHub - ahs3/gramps-web-pkg: experimental packaging for the gramps-web project, instead of using containers
I’m concentrating on Fedora for now (Debian-based distros later on), and the web API to start. I’m finding a bunch of subsidiary modules need packaging, too (Fedora COPR is here – Packages for ahs3/gramps-web), as either outdated or not provided in the latest Fedora work.
The goal is to get to a simple:
$ sudo dnf install gramps-web
or:
$ sudo apt-get install gramps-web
followed by a configuration script, if needed.
We’ll see how far I get :-).
Okay, I’ve gotten as far as the script posted previously with the packaging. On a Fedora system (f41 or rawhide), you can
try the web api with this:
$ sudo dnf copr enable ahs3/gramps-web
$ sudo dnf install python3-gramps-webapi
Next step is the front-end, then helper scripts for configuration.
I will need to investigate testing more deeply but I will defer that for a bit. I prefer to have packages invoke some sort of self-tests and I’m still puzzling out how to get the test cases to run properly – there seems to be some bit rot here and there, some very old modules being used, and the quality of the tests are just all over the place, as one would expect with such a large ecosystem. And, those sorts of changes should go upstream first.
There is now a package for the frontend package; not sure if it’s correct at all (all this nodejs/javascript stuff is a bit convoluted for this ol’ kernel hacker :). You can install it with:
$ sudo dnf copr enable ahs3/gramps-web
$ sudo dnf install nodejs-gramps-web
About half-way through with a meta-package to install both the webapi and the frontend, then configure it all.
I am following this thread, as I am setting up my system with Gramps/Web/Postgresql. I am running Debian 12 bookworm, and plan to attempt to build Gramps Web from Source.
I am a web-developer and have a few years experience setting up web/database servers for various applications in small office networks.
I know the OP is over a year old, but my experience is that frequently a white screen after setting up a web-app is a permissions issue. On debian I would do:
sudo chown -R www-data:www-data /directory-of-web-app/
Just installed Zoneminder on a system and had to re-set the permissions on several different directories after getting first a white-screen, then a screen with no css applied, then login not working. Permissions fixed all the above.
I am following this thread, as I am setting up my system with Gramps/Web/Postgresql. I am running Debian 12 bookworm, and plan to attempt to build Gramps Web from Source.
I am a web-developer and have a few years experience setting up web/database servers for various applications in small office networks.
Fair warning: this ended up a lot longer than I thought it would;
I did’t really have a lot of time to edit it and make it shorter.
I’ve unfortunately been distracted by Real Life 
recently, but I
have gotten as far as packaging up the API, and maybe have some sort
of gramps-web package working for Fedora (maybe – it builds but I
have not tested it at all due to circumstances). My inexperience with
web stuff is the hurdle to get over at this point. The ins-and-outs of
NPM and node.js and the like I’m finding very confusing (I prefer
Linux kernel code, I’m afraid :).
I can learn but what would really help is some basic pointers on how
apps like Gramps-web get packaged. A decent tutorial, or even better,
some good example packages would be much appreciated (I’m a Debian
Developer Emeritus as well as a Fedora Packager so either distro would
be fine for examples). I keep trying to understand why things need
to happen the way they do but it’s a pretty alien world to me, and
there is so much info available, it’s hard to tell what’s useful and
what it not.
On another topic, one of the things that make the Docker components
easier is that they can make all sorts of assumptions about their
run-time environment. For this first pass, I’d like to make some
of the same assumptions, and maybe a couple more:
-- the gramps API runs on the installation host, at HTTP port 5555
(maybe that should be 5000 ....)
-- the gramps web frontend runs on the installation host, at HTTP
port 8000
-- nginx is the only web server supported (for now) and it is to
be used as a reverse proxy; I'd like to assume gramps-web is
the only thing running but that seems impractical; instead, if
the webserver is at "example.com", it seems reasonable to locate
gramps-web at "gramps.example.com."
-- sqlite is the go-to data base for now.
-- email is outside our purview; we will assume it works on the
installation host.
-- systemd services will be used to start/restart components
I’ve also split this problem into three: a package for the API, a
package for the web frontend, and a meta-package that installs both
and does basic configuration. I’ve tried a couple of approaches:
-- interactive bash script: seems like overkill but workable,
but not always amenable to being done during package install
and would an after-installation step
-- non-interactive bash script: easiest for packages, but initial
startup of the front-end I'm still parsing through to see what
else it assumes to see if it's possible
-- ansible playbooks: again, seems like overkill (but a fan
favorite for my part), and definitely requires a post-install
step
So my questions are:
-- are there specific things that should not be assumed? The
more assumptions possible, the more straightforward the package,
generally speaking.
-- is this package structure (API, frontend and meta-package) okay?
It could be turned into one massive package but that would make
maintenance harder, and regardless, it would still be an install
with 'apt-get install gramps-web' or 'dnf install gramps-web';
the dependent packages would still be brought in.
-- is a post-install configuration step preferred to setting very
simplistic defaults?
Sorry this is so long, but feedback would be greatly appreciated and
somehow I ended up with being puzzled about the “right” course quite
a lot 
… thanks for hanging in there to get this far …
Out of curiosity, have you managed to successfully install Gramps Web from source? do you have working functional Gramps Web running?
I am only just now starting to set things up, so it might take me a bit to work through all the things.
Sort of? The API seems to be fairly straightforward – I’ve put some scripts that I’ve been playing with in GitHub - ahs3/gramps-web-pkg: experimental packaging for the gramps-web project, instead of using containers. Feel free to play with them. The frontend sort of works, too, using these scripts. But, they’re mostly there for me to try to understand what I’m doing and play with whatever the packages installed. I have been able to get as far as attempting to sync with a Gramps Web server that I’ve installed but, packages that work and packages that are done properly for the distro are not always the same thing :-).
I spent a couple hours studying Gramps, and ultimately decided it is a bit too kludgy for me.
Currently I have Webtrees installed and it seems to be working nicely. It took me all of 10 minutes to have it running on my webserver and another half hour to read up on customizing. The database for Webtrees is MySQL and uses a sensible data-structure. I think I am going to back out of Gramps for a bit.
I hate to do this, I really do.
At this stage, I have run into close to 20 dependencies that have not been packaged before, either in Debian or Fedora, and there are parts of the dependency tree I still haven’t completely tracked down. This is just for the API, and doesn’t even include some of the dependencies needed for testing these packages at build time. This is just far too complex a set for me to maintain; creating the packages I could eventually get to, but the long term maintenance effort looks like far more than I can contribute at this point in my life. It’s not that it cannot be done, it’s that I can’t make the commitment to do it properly.
Using pip in docker makes much more sense, honestly, since such a significant portion of the modules in pip have never been packaged for a distro. It pains me to say that, but I have to be realistic.
I’ll leave what I’ve done in github if someone else wants to give it a go.
No worries. I feel your pain, and hope to help simplify the system so that it can be installed in more flexible ways.
Just for the record in order not confuse people trying to set up Gramps Web following the documentation:
The Docker method seems to assume that is the only app that will be running on the server and that is not usually the case. Most servers host multiple websites.
This is simply wrong. I am personlly running multiple apps (including Gramps Web) on a Raspberry Pi. In fact, the opposite is true - when deploying multiple applications, containerization makes it much easier to isolate them.
If anyone wants to run Gramps Web without docker, it’s actually very simple – if you are willing to read the documentation of the underlying libraries, Flask and Celery. Gramps Web is a Flask app using Celery as background task queue, with a pip-installable backend and a static frontend.
Steps required:
pip install gramps_webapi(ideally, in a virtual environment…)- Download the latest release of the frontend and extract it somewhere
- Create a config file for Gramps Web API, setting all the necessary options including
STATIC_PATHthat should point to the extracted frontend - Set up the services for the flask app and for celery. If you want to use
gunicorn, you could use a command like in the default Docker file, but there are countless options. See the Flask docs. For Celery, our docker compose examples usecelery -A gramps_webapi.celery worker --loglevel=INFO --concurrency=2, but again, you can check the Celery docs for details.
Thank you for the clarifications, David. My apologies for any confusion
I may have caused.
And pip is the reason this works well; it handles all the dependencies
very nicely since they’re all available via pip – which is where I ran
into complications since so many dependencies were in pip but not in
distro packages.
My apologies, I made that statement and was definitely my lack of understanding Docker. I just use a web server and IIS without NGinx and I use Virtualmin to keep up with my multiple websites. Trying to throw Docker in was a little challenging and foreign to me.