sourceInfo does not tell us whether it's git or not

[roberth]

Is your feature request related to a problem? Please describe.

We'd like to set the configuration revision in NixOS to "dirty" when the repo is dirty, but we have to infer from sourceInfo?submodules whether it's git or not.

• https://github.com/NixOS/nixpkgs/pull/179772/files#r911965312

Describe the solution you'd like

An explicit identification of what type the source is. Perhaps not in the type or _type attr, because those can not represent subtyping hierarchies. A git sourceInfo is a sourceInfo, so tagging it only as type = "git" makes checking for sourceInfo hard.
A marker like isGit = true would be a better design, except I wouldn't want a isGit = false on all non-git sourceInfos. Perhaps an encoding like sourceInfo.git = { rev, ... } with all the git-related attrs inside would be best?

Describe alternatives you've considered

Hope that the submodules attribute remains an accurate signifier of git-ness.

Additional context

• nixos/modules/flake/source-info: new module nixpkgs#179772

[domenkozar]

It would be great to have sourceInfo.uri in style of nixpkgs: github:NixOS/nixpkgs/747927516efcb5e31ba03b7ff32f61f6d47e7d87, like nix flake metadata shows.

[roberth]

uri

I'd prefer to have it as structured data in such a way that it can be passed to fetchTree with a slight modification. This is useful for getting a tree with one or two parameters tweaked. Having uri in addition to that probably doesn't hurt, unless someone goes ahead and modifies the stupid string anyway.

[edolstra]

sourceInfo intentionally does not include the URL to ensure that building the same Git revision from two different locations produces the same result. E.g. nix build git+https://some/repo?rev=X and nix build /some/repo?rev=X should produce the same result.

Even including the type is not ideal, to ensure that building from git and github inputs for the same revision produces the same result. (Currently the availability of revCount does enable making that distinction, which is one more reason to remove revCount...)

I would prefer removing the submodules attribute from sourceInfo, since it's not clear what its use case is.