Improve Developer Readme

[jmercouris]

In short, do we want to:

1. Seriously refactor the nix section - mention that git cloning with submodules is required, etc. I think you'll agree with that, as the document stands now, few will be able to hack on Nyxt with nix.
2. Drop the section all together. I'm not saying that we should get rid of nyxt/build-scripts/shell.nix. Simply saying this hacking method will not have the "official" status. And I'm not trying to convert you to guixanism either :)

Section "Standard developer's installation" feels a bit odd in the sense that it repeats much of the installation process mentioned in the INSTALL file. Maybe it's purpose is to serve as a more in-depth reference that complements INSTALL and nyxt/documents/SOURCES.org. I think it goes too much in depth nonetheless. For instance, when it describes how to install dependencies such as webkitgtk in different GNU/Linus distributions. Package maintainers need to know the build of materials, and the rest they can figure out.

I think we should erase all references to quicklisp. We already mention that relying on it is discouraged. The git submodules render quicklisp useless. Since it's a tool that CL programmers tend to use, I think a single note somewhere mentioning why we don't rely on it suffices.

Structure-wise, the first-level contents should be (in order):

1. Developer's installation guide
2. Developer's environment guide (what we now call "Hacking")
3. Merge "Contributing" and "Help & Community"

Maybe 1. and 2. should be swapped.

I suggest getting rid of "Run Nyxt in a security sandbox". nyxt.scm already mentions how to run in a container already. Does anyone actually use Firejail?

[hgluka]

Just to add on to this, if we end up removing sections like the Nix installation guide, security sandbox, and shortening others, that could make room to expand on things in other places.

Particularly, I'm not a huge fan of linking to build-scripts/nyxt.scm for installation instructions. An org file is much clearer and easier to read than a comment. What do you think?

[aadcg]

Particularly, I'm not a huge fan of linking to build-scripts/nyxt.scm for installation instructions. An org file is much clearer and easier to read than a comment. What do you think?

If I understood it correctly, you suggest keeping build-scripts/nyxt.scm as is (the instructions at the top) but expanding on this subject in the org file. Seem sensible to me.

Or are you saying that we should have no instructions at the top of the .scm file?

[hgluka]

You understood correctly. The .scm file should stay as is, but the .org file should also have the basic instructions and only refer to the .scm file for more complex use cases (e.g. running in a container).

[jmercouris]

@hgluka shall I assign you, or shall I do this?

[hgluka]

Let me just check first. The idea is this:

• Developer's installation guide (with Guix and maybe a more streamlined version of the "Standard developer's installation")
• Developer's environment guide (what I wrote in documents/README: add section for beginners #3065)
• Merge Contributing and Help & Community

If I'm not missing anything, then yeah, I can do it.

[jmercouris]

OK, great :-)

[aadcg]

with Guix and maybe a more streamlined version of the "Standard developer's installation"

Here's a thought. The target audience of developer's installation are package managers maintainers. Guix users can install Nyxt via the first instruction available at nyxt.scm but that's a rather niche case. Most Guix users will issue guix install nyxt. In that sense, I'd say that we should describe a general installation guide that fits the bill for most GNU/Linux distributions suffices. Use your judgement. You're the newcomer, so you're less formatted than us :)

[aartaka]

Regarding "Contributing": this one should rather be a CONTRIBUTING file at the repository root, so that we conform to the established norms set by other projects, and so that Github suggests our contributors read this.

Moving "Programming conventions" there feels like a right move too.

[marek22k]

I suggest getting rid of "Run Nyxt in a security sandbox". nyxt.scm already mentions how to run in a container already. Does anyone actually use Firejail?

Yes, but unfortunately Nyxt does not work with firejail :-(