search

NixOS / SC-election-2024

2024 Election for the Steering Committee
32 stars 75 forks source link

Forge agnosticism #120

Open zeuner opened 1 month ago

zeuner commented 1 month ago

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 commented 1 month ago

This might be a duplicate of https://github.com/NixOS/SC-election-2024/issues/18

cafkafk commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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.