<Mic92>
to update your declarative pinnings, there could be also a website that prints git ref + hash.
<Mic92>
this a bit less annyoing.
<sphalerite>
oooh and have nur = let result = tryEval (import <nur> { pkgs = self; }); in if result.success then result.value else throw "Please add NUR channel bla bla bla";
<infinisil>
I personally like the idea of using increasing integers to do the pinning, it's a bit unconventional but would be pretty cool
<infinisil>
And seems to be the only way for having NUR properly work in nixpkgs, with pinning support
<Mic92>
infinisil: maybe a web service that redirects a revision number to the git commit?
<Mic92>
this should work because we never change history.
<Mic92>
or we need a svn mirror :)
<infinisil>
Hmm maybe
<infinisil>
But then NUR would rely on that web service to work, which I'm not a fan of
<Mic92>
I am still hoping the webservice is github.
<Mic92>
maybe they have some sort of api for that
<Mic92>
travis could add tags ...
<infinisil>
So how would `nur = ???` look like then in nixpkgs?
<samueldr>
haha, though those discussions might have been held before or during the month of may
<infinisil>
Oh and how about that (not sure if you meant that samueldr): When nixpkgs gets branched off for release, we change the nur definition to `nur = { tag ? "2018-09-01" }: if tag == "2018-09-01" then builtins.fetchTarball { url = ".../${tag}.tar.gz"; sha256 = "..."; } else builtins.fetchTarball "../${tag}.tar.gz";`
<infinisil>
Such that stable releases have a non-master version as default, so people get a stable version automatically
<samueldr>
(and I just blindly trusted the answers of "tags don't scale")
<Mic92>
infinisil: what if we get the tag from the nixpkgs version?
<Mic92>
is this possible?
<infinisil>
OH
<infinisil>
neat
<infinisil>
Much better
<infinisil>
Could even do it automatically based on .version-prefix
<infinisil>
.version-suffix I mean
<Mic92>
also only because nixpkgs and nur are forcely kept in sync does not mean they work together.
<Mic92>
it could be that a later version of nur fixes the evaluation with the current nixpkgs revision.
<Mic92>
That's beeing that, having an option for users to pin a revision they are happy with is a good idea, but not pinning by default might be a sensible default.
<Mic92>
After all I don't see how we could support stable without support from the individual repo maintainers.
<Mic92>
They would need to commit on what they want to support.
<Mic92>
Supporting stable releases is however probably something we need support, if we want to be in nixpkgs.
<Mic92>
or else we would not include nixpkgs in any release.
<Mic92>
An alternative would be to lock the nixpkgs revision in nur instead of the other way around.
<Mic92>
at the price of more expansive evaluation.
<infinisil>
Mic92: Good point
<sphalerite>
actually you know what, I think the status quo is fine :')
<Mic92>
We could also tell users who want to use NUR in stable to import unstable channel as pkgs = source.
<infinisil>
sphalerite: Meh
<Mic92>
I think the tags is something we could add anyway, because there are handy - independently how we use them.
<infinisil>
It would be cool to be able to do `(import <nixpkgs/lib>).nur.paul.foo` to get `nur.repos.paul.lib.foo`
<infinisil>
People could then easily distribute library functions usable in nixos modules
<sphalerite>
that seems confusing. Why not just use (import <nixpkgs>).nur.paul.lib.foo?
<sphalerite>
whoops plus a {}
<infinisil>
sphalerite: Because that won't work with nixos modules and stuff
<infinisil>
Infinite recursion and such
<infinisil>
Ah wait
<infinisil>
Yeah
<tilpner>
Please no dependency on NIX_PATH :/
<Mic92>
there is no dependencies, but you have to supply an additional argument then.