Leverage the "uniform" in URLs for flake refs more

[NobbZ]

brief problem statement

Currently using non-default hosts for gitlab: and sourcehut: schema feels foreign and backwards. It requires manual intervention and reordering components of the repositories URL when adding them to a flakes input set via copy and paste.

Also nested groups in GitLab cause confusion in URL notation.

prefered solution

Instead of passing the host via a "query parameter" we could use the URL format better and more efficient.

Section 3 of RFC 3986 has a complicated way to say that the "authority" (combined user/host) is optional.

So after reading this, we could use the optionality of the authority to make gitlab:owner/repo?host=example.com to gitlab://example.com/owner/repo. This would be much more natural to read, and at the same time gitlab:owner/repo with an assumed authority of gitlab.com would remain as valid.

To also further reduce confusion of branch/tag names or commit SHAs vs. nested GitLab groups the commit ID should be completely removed from the URLs path and instead a query parameter should be used (among all schemas supporting a similar feature, including but not limited to git+* or github). gitlab:owner/repo/branch would then become gitlab:owner/repo?rev=branch and could not get confused anymore with gitlab:org/group/repo.

We might consider allowing an alternative character for starting the query string to avoid having to escape it on the terminal.

alternatives

Continue confusing and Non-uniform Resource Locators.

additional context

I considered going through the RFC process for a moment, but decided not to, as to my understanding the flakes itself haven't yet passed the process.

Though if this suggestion requires to go through the process, I am happy to continue there.

[DavHau]

There is purl-spec which might be worth looking into.
github: https://github.com/package-url/purl-spec
fosdem presentation: https://archive.fosdem.org/2018/schedule/event/purl/

It's standardizing how to reference package resources. It already looks pretty similar to what is used in flakes. Maybe it makes sense to adopt an emerging standard instead of inventing yet another one.

There are already implementations of it in several languages which might reduce the maintenance effort for nix devs and allow for better interoperability between nix and other tools handling that format.

With dream2nix for example I ended up re-implementing flake-style resource referencing. This would not be necessary if nix followed a standard which is supported by libraries.

[edolstra]

So after reading this, we could use the optionality of the authority to make gitlab:owner/repo?host=example.com to gitlab://example.com/owner/repo.

That sounds good to me.

Regarding purl: I'm not sure whether that would gain us a lot. It would make flakerefs more verbose (they all would have to start with pkg:flake/), and they assume some notion of a package repository that we don't have. In terms of implementation, it wouldn't really simplify things, since URL parsers are also available for every language.

[NobbZ]

I also prefer the regular URL way.

It is something that people know to read in a way. Something people see every day. PURL reads nice on first glance, though it would be just another notation to learn…

Either way, purl or optional authority instead of the host query param, the change should happen before 3.0 with some deprecation warning for the old way of specifying hosts and branches (if the latter proposal gets accepted as well)

[tomberek]

The optional authority seems to be an excellent approach and is already used by the git+ scheme. (eg: git+ssh://git@github.com/org/repo and git+file:/some/path). It also seems this is the expected location for hosts.

Independently, support for the overall purl standard would be possible and not interfere with the existing syntax. Recommend supporting the optional authority component and leaving purl as a separate topic.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-flake-gitlab-http-404-error/19006/3

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-flake-gitlab-http-404-error/19006/4

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/what-would-you-change-in-nix-or-nixos/21086/12

[roberth]

some notion of a package repository that we don't have.

Isn't the central flake registry repo like a package repository?

[Ericson2314]

This sounds good to me!

[xokdvium]

This is in-line with the URL logic cleanup in #9603. I suspect that we'd have to normalize the optional authority to the host query parameter to make lock files backwards compatible though (but it's debatable).