libfetchers: add darcs

[n3gative1]

Is your feature request related to a problem? Please describe. darcs is not dead. i would like to use darcs+�:// for flake inputs just like git, mercurial, + attempts @ fossil.

Describe the solution you'd like touch src/libfetchers/darcs.cc + related files

Describe alternatives you've considered tarball+�:// can work, but darcsden & other forges aren’t allowing a tar option against a tag, only latest

Additional context awk -F ':' '{print $2}' _darcs/tentative_pristine prints a hash that seems like it could be used for tracking that the state of the repo even if patch theory communicates that patch order doesn’t matter--only the output. patches can be referenced by their hash or patch name according to the docs. tags offer markers that aren’t supposed to be rewritten. one should be able to reference this pristine hash to verify that the output is good regardless of underlying patch order.

Priorities

Add :+1: to issues you find important.

[Ericson2314]

I doubt we want to add more fetchers at this moment or any time soon. We are working on stabilizing fetchTree and making improvements to the existing ones. And adding more is not very maintainable at all. Just use fixed-output derivation for niche things like Darcs.

[n3gative1]

niche things like Darcs

by what metric? is it more niche than mercurial? from my understanding the “fixed-output derivation” are often referring the ${LANG}2nix brand of output. darcs is an dvcs like git, hg, or pijul, not a package manager like cargo, npm, etc. why should git get special first-class treatment unless we want to see hegemony?

if i put in the effort and/or found help to build darcs support, would you merge it?

[Ericson2314]

By fixed output derivation I mean the fetch* in Nixpkgs. Those are not the same as the lang2nix things.

if i put in the effort and/or found help to build darcs support, would you merge it?

I would rather not, because the initial effort is just one part of it. There is also maintaining it.

When I got the github notification I thought it was a PR and was filled with dread, and then I was relieved to see it was just an issue.

why should git get special first-class treatment unless we want to see hegemony?

I actually agree; I think creating libfetchers with a few popular things was opening Pandora's box, and broke with the spirit of Nix providing neutral building blocks and not providing ad-hoc solutions. I think its too late to turn back right now (there are stable builtins already) but I regret going down this road and wish to go down it no further.

[n3gative1]

i would agree that libfetchers seems weird… like why a specific one towards github?

nixpkgs does have fetchdarcs (or something named similar). the big, bad annoyance tho is that i don’t get a good experience for flake inputs. is there a way or some mapping from flake input to fetch� and still get something that ⓐ feels nice + ⓑ works with nix flake lock --update-input (’cause the alternative of finding a hash/patch to grab onto & then the sha256 for nix is bad ergonomics)

[Ericson2314]

Yeah that's a good point; ideally the lockfile format would extensible for user-defined things. This is a great point for us to consider during the flakes stabilization process. (We might not be able to add such a large greenfield new feature, but we could e.g. try to "leave room" for it when e.g. stabilizing the lockfile format.)

CC @roberth

[n3gative1]

ideally there would be a mirror option for flake inputs too for resilience. fetchers from nixpkgs have this feature.

[Ericson2314]

I hope fetchers can eventually merge with substituters which will help with mirroring.

[cognivore]

Hi, long-time nix user here. Just to clarify the policy — if this feature request was, instead, a pull request, it wouldn't have been merged either?