overview: Stable project urls

[erictapen]

Closes #505

Beware that this currently mixes the names of projects/ and projects-old/, even though the names in projects-old/ are actually grant names, which we don't want to use. As NGIpkgs is experimental and the overview isn't even hosted in it's designated place yet, I didn't care yet to write logic to only use names from projects/.

Currently this uses the following URL format for the URL of e.g. the Canaille project: https://ngi.nixos.org/Canaille

[fricklerhandwerk]

Nice!

[fricklerhandwerk]

Suggested change

	<a href="${name}">${name}</a>
	<a href="project/${name}">${name}</a>

The issue discussed namespacing for better extensibility, and I agree with that.

[erictapen]

Yeah agree, going for extensibility would be the safer bet here.

[eljamm]

Well done! This works great when using a HTTP server and it looks and behaves just as expected:

$ nix build .#overview
$ nix-shell -p httplz --run 'httplz ./result/'

That said, this isn't the case when opening the overview file directly:

$ xdg-open ./result/index.html

• When I click on a project link, it doesn't take me directly to its page, but rather:

Then I'd have to click on index.html to be taken there.

• In the project page, the arrows look a bit out of place:

[eljamm]

We can make the page link take us directly to the project page (see #570 (comment)):

Suggested change

	<a href="${name}">${name}</a>
	<a href="${name}/index.html">${name}</a>

[erictapen]

Thanks, I'll respond to your review here. Opening the pages as file:// in the browser doesn't work and I think it's reasonable to require contributors to use some kind of minimal webserver (e.g. I use darkhttpd). Opening as file:// also brings the disadvantage of not allowing AJAX and even is inconsistently implemented in different browsers.
On a different note, I'd rather not have index.html fragments in URLS. These are implementation details and shouldn't be visible to the user (and they make the URL longer).

[eljamm]

Alright, that seems reasonable to me. Then what do you think about adding another package that runs a HTTP server on the overview? Something like overview-preview that users can run to see how it would look in production.

We could alternatively rename overview to overview-static and have overview be the package that starts the server.

[erictapen]

Mh how about we just add darkhttpd to devShells.default and document how to build the overview and run the server?

[eljamm]

Sure, would that be better for reloading changes faster?