Should I continue modifying srcs to use fetchFromSourcehut instead of fetchurl?

One quick question: is the sourcehut url format stable? If yes, never mind, but if it isn't, maybe we should be able to override the function that generates the url!

I think the domain should be able to change, as far as I know you can host your own instance.

Besides that, we need to get the base approved, with how fetchFromSourcehut works, before any more are changed (I would say. Maybe @worldofpeace can help on this?

Also tagging @SuperSandro2000 and @mweinelt as they seemed interested in this!

is the sourcehut url format stable

I hope!

IIRC Drew has said that the ~ is not going to change so the URL is stable (if that's what that refers to?) but as mentioned before you can host SourceHut yourself and so it could be git.your.domain. Perhaps an FQDN override (or something better named since your.domain isn't fully qualified, it's missing the git giving git.your.domain).

One more thing to note, whereas with GitHub the owner can refer to a person or org on SourceHut the discussion is ongoing on what the organisation (user group) prefix will be. Examples in the air are say ^. So there'd need to be some distinction between an organisation-equivalent (user group) and a person (single user). Here is the discussion thread relevant to that: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CC0L8LGIM0C2I.3O209D1TSO6M3%40homura%3E

Perhaps an FQDN override

This is already implemented: domain ? "sr.ht". domain may not be the best name for it, but it's called like that in the gitlab fetcher.

on SourceHut the discussion is ongoing on what the organisation (user group) prefix will be

Thanks for the information!
I think there are two solutions to that.

• we add group ? false to the args and swap ~ to whatever it will be (like + or ^) if group is true.
  Usage example with git.sr.ht/^sourcehut/core.sr.ht (or git.sr.ht/+sourcehut/core.sr.ht):

src = fetchFromSourcehut {
  owner = "sourcehut";
  group = true;
  repo = "core.sr.ht";
  rev = ...;
  sha256 = ...;
};

• we default owner and group to null and use the one that is not null with the correct prefix.

src = fetchFromSourcehut {
  group = "sourcehut";
  repo = "core.sr.ht";
  rev = ...;
  sha256 = ...;
};

Usage example with git.sr.ht/~sourcehut/core.sr.ht in both cases:

src = fetchFromSourcehut {
  owner = "sourcehut";
  repo = "core.sr.ht";
  rev = ...;
  sha256 = ...;
};

Wouldn't it be easer to use one attribute for users and one for groups?

src = fetchFromSourcehut {
  user = "sourcehut";
  repo = "core.sr.ht";
  rev = ...;
  sha256 = ...;
};

src = fetchFromSourcehut {
  group = "sourcehuters";
  repo = "core.sr.ht";
  rev = ...;
  sha256 = ...;
};

Wouldn't it be easer to use one attribute for users and one for groups?

Might be a better option, although it would make the code more complicated. And also it might end up more confusing if people read the code of the fetchFromSourceHut function.
A flag is less complex to understand and adds little overhead IMO.

Wouldn't it be easer to use one attribute for users and one for groups?

I think we should keep the owner naming for what you are referring as user, even if a group is technically an owner, because that's how the other fetchers are naming it.

A flag is less complex to understand and adds little overhead IMO.

having to set a flag if I want to download things from a group is not very intuitiv for people coming from GitHub, GitLab or Gitea because they all don't have that difference.

I think we should keep the owner naming for what you are referring as user, even if a group is technically an owner, because that's how the other fetchers are naming it.

Didn't you come to the conclusion that groups on sourcehut are a bit different from all other platforms? Than the fetcher can also be a bit different.

The fetcher is new and we are not breaking anything so we can do it right the first time.

And if users are confused we can throw an explanation if they pass owner into the fetcher.

Didn't you come to the conclusion that groups on sourcehut are a bit different from all other platforms?

I don't know how they work on github and gitlab, so I can't tell if it is different.

And if users are confused we can throw an explanation if they pass owner into the fetcher.

That could be a solution, but we are all used to give owner, repo, rev and sha256 to fetchers. I think it would be annoying to have a fetcher that uses a different naming for one thing, and I would see myself mixing up owner and user.
It would not be a big deal, especially if it throws a good error, but I see it being annoying.

But if other people think too it should be user and group, I'm not against it, I just think there are drawbacks.

I don't know how they work on github and gitlab, so I can't tell if it is different.

the URL scheme is just the same. github.com/NixOS could be a group or a user.

But if other people think too it should be user and group, I'm not against it, I just think there are drawbacks.

Or the owner is prefixed with ~ or something else but adding a flag isGroup = true is the most inconvenient solution.

Can you please fix the merge conflict?

I don't want to bikeshed, but by analogy with fetchFromGitHub, I would have expected this to be called fetchFromSourceHut.

I don't want to bikeshed

We are already in a bikeshed problem :P

by analogy with fetchFromGitHub, I would have expected this to be called fetchFromSourceHut.

IDK, because it's GitHub, GitLab and SourceForge, but it's sourcehut or Sourcehut, they chose to not capitalize it for some reason.

We still need someone to decide the best solution for the group/user/owner/flag problem.

That's fair, I'm just catching up with the rest of the thread now. What if we just sidestep the owner/group thing altogether, and just say owner = "~sircmpwn";? And if group support is added further down the line with some other sigil, we can just do owner = "^group", without having to change the fetcher code? You could still have a shorthand as follows:

{ user ? null
, owner ? "~${user}"
}

And if/when they make up their mind about what sigil to use, you could update that to:

{ user ? null
, group ? null
, owner ? if !isNull group then "^${group}" else "~${user}"
}

But in any case there's no reason for this PR to be blocked on that.

Thanks, this is a great solution!

@SuperSandro2000 what do you think?

Thanks, this is a great solution!

@SuperSandro2000 what do you think?

sounds go to me.

I start to see programs hosted on sourcehut, so I think adding a fetcher will be helpful.

Just in case:

$ egrep -ir --include="*.nix" "url.*=.*sr.ht" nixpkgs/ | wc -l
29

I lost track of this since my last comment but I intend to give it a final review tomorrow and hopefully merge it (so that we can also properly fix #115397), so please let me know if there are any important objections (likely not but just to be sure). And if someone else reviews/merges it before that that's obviously fine as well :)