Open NobbZ opened 2 years ago
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.
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.
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)
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.
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
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
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
some notion of a package repository that we don't have.
Isn't the central flake registry repo like a package repository?
brief problem statement
Currently using non-default hosts for
gitlab:
andsourcehut:
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
togitlab://example.com/owner/repo
. This would be much more natural to read, and at the same timegitlab:owner/repo
with an assumed authority ofgitlab.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+*
orgithub
).gitlab:owner/repo/branch
would then becomegitlab:owner/repo?rev=branch
and could not get confused anymore withgitlab: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.