<gchristensen>
and then I think maybe in the install script, run the `nix upgrade-nix` command, so then the fitness tests of the install run against the upgraded version. does that make sense?
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
jtojnar has quit [Client Quit]
<LnL>
oh yeah
<LnL>
also the info/doctor command I'm playing with could try to detect profiles without a root
goibhniu has quit [Ping timeout: 244 seconds]
init_6 has quit []
<gchristensen>
LnL: if you want help with the test setup or running or the whole thing, let me know :) happy to help. the whole project is still very nascent
jtojnar has joined #nixos-dev
xeji has joined #nixos-dev
orivej has joined #nixos-dev
xeji has quit [Quit: WeeChat 2.1]
xeji has joined #nixos-dev
drakonis has joined #nixos-dev
pxc has joined #nixos-dev
<samueldr>
infinisil: since you thumbed-up my comment, just checking you're fine with the message here being still opinionated? (hovering on the merge button) https://github.com/NixOS/nixpkgs/pull/45571
<{^_^}>
#45571 (by jtojnar, 1 day ago, open): gnome3.gconf: re-add as a pointer to the removal PR
<gchristensen>
samueldr: I'm commenting
<infinisil>
samueldr: Oh, the warning is still the same, I was hoping jtojnar would change it
<samueldr>
(I was too)
* samueldr
moved cursor away
* samueldr
spies new thumbs up
<LnL>
:p
<LnL>
I thought the exact same thing when first seeing it, neither the original commit message or the error message are useful to anybody
<samueldr>
the instructions were added to the linked issue though; throws aren't the best location for instructions for changes
<samueldr>
(but yeah, the changes are small enough that in this case they could fit fine)
<LnL>
doesn't have to be full instructions, but it should contain some kind of pointer where to look IMHO
<samueldr>
the linked PR in the throw message has instructions, albeit short
<LnL>
oh whoops, let me not keep that thing commented
Lisanna has joined #nixos-dev
goibhniu has joined #nixos-dev
<samueldr>
jtojnar: about #45571 re: moving to top-level, I think this largely depends on whether Nixpkgs should keep renamed attributes around when deprecating or removing them... which is not the issue being discussed in #45571
<samueldr>
you're faster, but yeah, the situation I believe needs a clear guideline
<infinisil>
Yeah
<samueldr>
before implementing anything about that, otherwise it'll become a bikeshed :/
<infinisil>
I'd go for a simple `foo = deprecated "18.09" "foo has been deprecated, use bar instead" "foo"`
<samueldr>
so if anybody has precendents about actual decisions about this going into nixpkgs, it'd be interesting to collect them to draft an RFC (yes I still believe in their value)
<samueldr>
infinisil: not even thinking about that, one step prior: do we deprecate and remove, or do we keep aliases forever?
<samueldr>
makes no sense to *then* work on a deprecation guideline if the idea is to keep aliases
<LnL>
^^
<infinisil>
samueldr: deprecate and remove imo, we can't keep amounting stuff without ever removing
<infinisil>
Especially with keeping older versions around
Lisanna has quit [Quit: Lisanna]
<infinisil>
Because those need to constantly be built as well and all deps kept around
<samueldr>
yeah, in your opinion, but it's been a bit of a contentious point lately and I really have no idea what to do about that
<samueldr>
(I really am firmly sat on the fence here)
<infinisil>
Another argument is that with nixpkgs it's trivial to use older versions by pinning an older nixpkgs
<samueldr>
oh, I do think I grasp the situation from both sides, what I think is needed is a guideline :/
<infinisil>
Ah right, aliases don't really matter much
<infinisil>
I'm more worried about other things
<samueldr>
because I have seen (no citations) important contributors argue on both side of the issue, which makes this a prime example of "the nixos indecision problem"
<infinisil>
samueldr: While I think it's debatable which things require deprecation or can be left alone, there definitely should be a standard way to deprecate things in general, agree?
<samueldr>
it may cmoe that we need to operate on a "royal decrees" or "dogma" process :/
<samueldr>
infinisil: yes, that's kind of orthogonal to the aliasing renames issue
<samueldr>
and yes, there should be a process for deprecation
<samueldr>
(see nix-repl, nix 1.11)
<samueldr>
(nix 1.11 itself may not be to be dropped, but 1.11 specifics in a nix 2.x nixpkgs would)
<infinisil>
Would probably be good to have a guideline first before introducing a standard deprecate function, people start throwing it all over the place
<samueldr>
exactly!
<infinisil>
samueldr: I think the Nix minimum version (lib/minver.nix) issue is somewhat orthogonal to other deprecations too
<infinisil>
It's like meta-deprecation
<infinisil>
:P
<samueldr>
yep, it's hard talking about "just deprecations" without tripping on the carpet mentioning other issues
<infinisil>
samueldr: Wanna work on a guideline together?
<samueldr>
*extremely full hands voice* you do know RFCs have co-authors?
<infinisil>
Heh, I never looked much into RFC's, so nope
<samueldr>
;) I wouldn't be against it, but the stack protector is activating and dropping your request :)
<infinisil>
samueldr: You already got started with it?
<samueldr>
ah, no, nothing yet
<infinisil>
samueldr: (I didn't quiet get that joke/reference there btw)
<samueldr>
my stack of projects is full
<infinisil>
Ahh!
<infinisil>
Well then maybe I'll start working on it
<samueldr>
trying to do another new thing is probably bound to cause bad undefined behaviour :)
<infinisil>
I have a lot of time for the next 3 weeks
<infinisil>
(I do have a lot of things I *want* to do too, but nothing that *needs* to be done)
<samueldr>
infinisil: then when you have something, if you ping me and it's a bit less hectic or well-defined, the work of co-author is much easier :)
<infinisil>
Will do
<timokau[m]>
niksnut: regarding a RFC for your "nix language changes" document: I think an RFC (or even just a document in a regular git repo) would be better even if there still needs much work to be done. It would make it more discoverable, easier to subscribe to discussion and easier to discuss individual points.
<infinisil>
samueldr: I have started writing an RFC for a deprecation guideline
<samueldr>
infinisil: I found out a good way to write the actual RFC is also look at how the others are structured, which kind of argument they put forward in which section
<infinisil>
Yeah I should do that a bit more probably
<samueldr>
but I first wrote a list of concerns, and a couple paragraphs freely before going through the template
<samueldr>
made sure the phrasing and ideas were mine and how I wanted
<infinisil>
Should I first finish the first draft before opening a PR? Right now it's just like a third done
<samueldr>
I don't really know, having only written one, and bein only one person, but I made sure I had everything I had in mind in a document before writing the PR
<samueldr>
including left-over questions
<infinisil>
Alright, will wait then
<samueldr>
I think my notes document is longer than the RFC
<infinisil>
samueldr: Want to take a look at it and maybe decide to become co-author?
<samueldr>
(but has really opinionated personal notes)
<samueldr>
let's wait until you have the RF drafted :)
<infinisil>
Alright :)
<infinisil>
I'm actually feeling really good right now, because I think I finally learned when to stop coding and say "That's enough for today, even though I'm not finished yet"
<infinisil>
(coding being writing the rfc in this case)