Alternative Editor Docs

[Aliervo]

Recently tried out gramps-web and I would love to contribute, but I'm not entirely sure how to set up my dev environment because I do not use VS Code. I am a neovim user myself, so I think there is a way to get VS Code based devcontainers working; I haven't needed to do so yet, so I'll have to do more research in this area.

I did, however, browse through the git history of the frontend setup page and found reference to the docker-compose based dev setup. Is this still a working/supported method, or should I go through the process of figuring out how to get devcontainers working with neovim?

Happy to help update the docs with whichever way gets me a working setup, just curious which way I should attempt to go first.

[DavidMStraub]

One of the main reasons for switching to VS Code + dev containers (apart from using it myself) is to simplify development docs and reduce the need to debug development environment issues (such as the ones the old setup was causing regularly).

That's why my approach would be: you are very welcome to use an alternative environment, but please don't raise issues for it and please don't add it to the official documentation.

You are very welcome however to document a working setup (once you've found one) somewhere else, as other people might find it useful.

To get started in finding out how to do this, I suggest to simply look at the Dockerfiles and task definitions of the two dev containers - they are just containerized Ubuntus after all.

[Aliervo]

Copy that. I'll mess around with it a bit this week and report back if I manage to figure out anything useful. Leaving this open for now in case someone else comes looking.

[Aliervo]

A little update, I managed to get an environment up and running using devenv. It needs a bit of cleaning up and testing, but I should be able to push it to a branch on my fork soon.

I did try one thing that might be useful for the primary setup. I added the backend repo to my gramps-web repo as a git submodule. This let me write scripts to launch the entire stack from the one spot and, if implemented, would make the frontend setup documentation almost identical to that of the backend, we would just need to specify that the submodule needs to be initialized when cloning the repo by either using git clone --recursive or cloning and running git submodule init. (Or maybe we could even script that bit, I haven't tried yet.)

Happy to hear thoughts on any of this and happy to open PRs if you'd like to implement parts of it, otherwise I'll close this issue once I get my new devenv setup cleaned up and pushed to my fork and we can just link people there if this comes up again!

[Aliervo]

Got my setup working and pushed to my branch. I ended up liking the result so much that I opened an issue about adopting it for the whole project.

This issue should probably remain open until that one is closed as it has implications on the support status of non-VSCode editors. Once that is adopted or rejected, we can figure out the best way to make my new setup knowledge accessible without implying full support.

[DavidMStraub]

This issue should probably remain open until that one is closed as it has implications on the support status of non-VSCode editors. Once that is adopted or rejected, we can figure out the best way to make my new setup knowledge accessible without implying full support.

Thanks again for your efforts - that I'm closing the issues does not mean that I think the documented environment is better that what you came up with, but I want to leave it as it is for now.

I would be fine with adding this to the official docs at www.grampsweb.org as an alternative environmet if you volunteer to maintain the docs and if no changes to the code repos are required.

[Aliervo]

I'm going to respond to multiple things here to save us both a little notification pinging.

Starting with this issue:

Totally happy to maintain the docs for my alternate environment. I can extract it into its own repo and then we'll have an easy place to link and a separate space for issues.

Regarding podman:

I would recommend adding a note that rootless isn't supported where the docs mention requiring Docker, this would cover both rootless docker and podman. I still think it is worth supporting rootless mode/podman, mainly because Fedora and it's derivatives are not uncommon and ship with podman by default, but I do understand that it's much less of a priority than working on things like fixing actual bugs or adding features.

About devenv adoption:

I think I might have misspoken in the issue. I wasn't trying to suggest we add devenv as a supported development environment, but rather maintain/enchance the current devcontainer based environment by replacing the dockerfile based setup with devenv. The officially supported environment would still be only the devcontainers, we would just get the other setups that come from devenv as a happy side effect. Maybe I should have called the issue, "Improve official devcontainer by building it with devenv".

Bringing it all together:

The reason I called this issue dependent on the devenv issue is that the devenv setup contains some scripting that simplifies the frontend setup. As I understand it, the current officially supported way to start working on the frontend is:

1. Clone the backend repo
2. Open in VS Code and let it build the container
3. Run the task to start the celery worker
4. Run the task to serve the API
5. Clone the fontend repo
6. Open in VS Code and let it build the container
7. Run the task to serve the frontend

With the devenv based devcontainer the steps become:

1. Clone the fontend repo
2. Open in VS Code and let it build the container
3. Run the task that starts the whole dev stack

It is worth noting that lot of the simplification actually comes from the git submodule, which should technically be its own issue, I just didn't open one yesterday because I felt like I had hit the repos hard enough already 😆.

So with all of that said, I would ask that you give the devenv issue a second glance. Clone my branch and test it as if I had rewritten the Dockerfiles to fix the podman issue, try out the new task to make sure it can pull up a full gramps-web dev stack, then open the devenv.nix file and ask yourself if it seems like a viable replacement to the previous dockerfile(s). If you try it out and it doesn't work or you just don't like it, no big deal; I'll pull it into its own repo and write some docs on how to use it.

Thanks for the great project and all the time you've already given to my issues, I promise some actual contributions are coming now that I have a working dev environment!

[DavidMStraub]

Thanks for the great project and all the time you've already given to my issues, I promise some actual contributions are coming now that I have a working dev environment!

Looking forward to it!

Exactly since setting up a dev environment can be a time consuming process, forgive me if I won't realistically be able to try out your new one in the next couple of weeks. But I'll put it on my list of fun things to do when I have time... and happy to hear other dev's feedback which setup they prefer.