Forge agnosticism

[zeuner]

Question

What's your stance towards becoming agnostic of a specific code forge, and what actual steps towards that goal do you have in mind?

Candidates I'd like to get an answer from

No response

Reminder of the Q&A rules

Please adhere to the Q&A guidelines and rules

[Gabriella439]

This might be a duplicate of #18

[cafkafk]

What's your stance towards becoming agnostic of a specific code forge, and what actual steps towards that goal do you have in mind?

For nixpkgs, and other Nix projects and their CI

Looking at how closely the Forgejo actions syntax and semantics are to GitHub[1], I don't actually think that most of the generic workflows currently in use would be an issue. What's more problematic is over-reliance on GitHub'isms, and it's important that from a top-down perspective, that is taken into consideration when designing systems so said GitHub'isms don't become load-bearing.

Specifically for NixCpp, and flake inputs

It's extremely problematic that we have "first-class" support for GitLab and GitHub in such a deep way, without having it for the other free as in freedom forges. I've often talked about the need for a more generic forge input. With rime, we were able to support rewriting tarball requests to GitHub, Gitlab, Gitea, Forgejo, SourceHut, and even FlakeHub, and it was surprisingly trivial. We even have auto-discovery mechanisms, again, a proof of concept that a generic forge endpoint is very much possible. But this middleware approach just doesn't cut it, it should be a native part of Nix to support all of these, and perhaps we should even create some generic Nix standard for interacting with "forges", in the same way as e.g. OCI has a container registry spec.

A spec and a standard? Not soon. But native support inside of NixCpp for all major forges? Doable, and worth prioritizing.

[1]: As Forgejo itself attests https://forgejo.org/docs/v1.20/user/actions/

[roberth]

We need to be very careful about forge integrations, because the built-in fetcher implementations must guarantee their own reproducibility, and fetching Git sources correctly is actually non-trivial because of the impure features. Especially git archive includes behaviors that are impure, and it tends to be the backend for forge-specific endpoints and fetchers. This is the main reason why the Nix team hasn't managed to complete the stabilization of fetchTree yet, because we haven't addressed all impurities yet.

With fetchTree stability being a prerequisite for Flakes stability, this is one of the reasons we still haven't delivered stable Flakes yet.

[proofconstruction]

This is essentially a duplicate of #18.

I'm in the process of winding down my personal GitHub usage and moving my projects to a self-hosted Forgejo instance. As I answered in #18, I believe we can eventually do something similar for the NixOS org in its entirety, and we should work towards that.