fetchFromRadicle: init

[Defelo]

Add a fetcher for projects hosted on Radicle.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[matthiasbeyer]

Only a small documentation suggestion, everything else looks fine to me.

Do we need docs somewhere for this? Probably?

[lorenzleutgeb]

I'd appreciate if you could wait for my review here. The reason is that Radicle 1.3 now supports Canonical References, which means that one will not have to access tags via a particular namespace anymore in the future. In the next weeks, probably all of the Radicle-hosted packages will switch to Canonical References.

However, such a fetcher should still allow fetching from a particular namespace, in my opinion.

I would like to read through the suggested changes here with a fresh brain, and the implications of Canonical References in mind.

[lorenzleutgeb]

I have implemented something similar before, just for reference: https://github.com/radicle-nix/radicle-nix/blob/main/pkg/fetchFromRadicleBridge/package.nix

Fetching via radicle-httpd as is done here isn't a true fetchFromRadicle in my opinion. That's why I called it "bridge".

What would deserve the name fetchFromRadicle IMO is something like this: https://github.com/radicle-nix/radicle-nix/blob/main/pkg/fetchFromRadicle/package.nix

[lorenzleutgeb]

OK, from what I understand, just omitting the node argument would work nicely with Canonical References. I just made a minor suggestion.

Please think about the name once more, maybe this should be called something like:

• fetchFromRadicleHttpd (for now, radicle-httpd is really the only server compatible with this)
• fetchFromRadicleBridge as we're using the given seed as a "bridge" to the Radicle network. Maybe even rename the seed argument to bridge.
• fetchFromRadicleHttp
• fetchFromRadicleSeed as this will rely on a particular seed being available.

[Defelo]

Hey @lorenzleutgeb, thanks for the feedback! I applied the change you suggested and removed the default value for seed.

Regarding the name, let's assume we eventually want to add another implementation which starts a node itself and thus doesn't require a seed. I think we could simply use the same fetchFromRadicle fetcher in both cases: If the seed parameter is set, the fetchgit implementation is used to fetch the repo via the radicle-httpd instance on the specified seed. And if seed is null (which could also be the default value), the implementation using radicle-node is used. This would be similar to what other fetchers like fetchFromGitHub do, which use different implementations (fetchgit vs. fetchzip) depending on their arguments. That's just an idea though, I will of course change the name of this fetcher implementation, if we decide not to do that.

[Defelo]

Do we need docs somewhere for this? Probably?

Added some documentation to the fetchers section

[matthiasbeyer]

Is the .git suffix always true?

[Defelo]

I think so. @lorenzleutgeb was doing the same in https://github.com/radicle-nix/radicle-nix/blob/22f8a86021b088c385cf3d2913e8ef3fac0ec619/pkg/fetchFromRadicleBridge/package.nix#L16

[matthiasbeyer]

Besides the one (non-blocking) comment, 👍

[Defelo]

Rebased onto master, changed radicle-tui to use fetchFromRadicle, and simplified its update script.

I checked all FODs again using nix build -f. radicle-node.src radicle-httpd.src radicle-explorer.src radicle-tui.src --rebuild and tested radicle-tui's update script again.

Are there any blockers remaining?

[nixpkgs-ci]

Backport failed for release-25.05, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release-25.05
git worktree add -d .worktree/backport-434360-to-release-25.05 origin/release-25.05
cd .worktree/backport-434360-to-release-25.05
git switch --create backport-434360-to-release-25.05
git cherry-pick -x 5e2cc452717a454ca3517caf85eba3ede38d71f3 0f4642c7961dfc1348b607f47ff8c9a8cf6b3656 036be6edbae5f37143def9dba764ceb8b387b5e5 1ddbbb16715d268ff003ab7b11821cd04bb0b4e2 914c4f23461c546d580675742b0c5bd4f04b4796