<pierron>
peti: it fixes the pythonPackages / haskellPackages, by inserting a new "b" in the set which is below the "self" argument, which would be bound to the attribute, before going through Nixpkgs fix-point.
<pierron>
peti: After the overlays provided by the user, I will add a new phase which looks for these functions, and bind them to the result of the binding: self: super: { pythonPackages = super.pythonPackages.setFun self.pythonPackages; }
<pierron>
setFun is defined in { _type = "scope"; setFun = self: …; }
<pierron>
and the >: operator will appear under the setFun function.
<pierron>
zimbatm: Should I do anything special to the ~20 review request for the default.nix files?
<globin>
did anyone flag the @nixborg account?
<globin>
I was using that to test the nixbot and apparently someone has flagged it and it cannot comment anymore
<Mic92>
globin: maybe an automatic mechanism?
<globin>
Mic92: might be because I deleted some of his comments, I've written to GH support..
<pstn>
If you need a sh to call in nixpkgs: Is it reccomended to use bash or dash? dash is smaller but bash is installed anyway. Is there a convention?
<zimbatm>
pierron: it's possible that you might have to approve them to unblock the merges
<zimbatm>
pierron: actually no you can just unsubscribe to all of them it should be fine
<pstn>
Of course there is a more than ten year debate going on about bash vs dash. What was I expecting. Looking into dash might actually be beneficiarry though. The common tale is that it starts faster and all those little wrapper scripts everywhere basically just start up.
<pstn>
Oh, it's way less than I thought. Probably not worth to touch anything.
<MoreTea>
gchristensen globin, have you checked out https://bors.tech/ as well?
<MoreTea>
I'm probably going to start implementing this at a client this week.
<peti>
pierron: I thought //< is *recursive*. Is it not going to recurse into the value of the 'a' attribute on the left hand-side?
<globin>
MoreTea: Yes, a lot of the nixbot is inspired by it
jtojnar has joined joined #nixos-dev
Profpatsch has quit [(Quit: WeeChat 0.4.3)]
Profpatsch has joined joined #nixos-dev
<zimbatm>
bors is awesome
<globin>
but sadly doesn't fit our architecture
<zimbatm>
I deployed it on heroku in like 10 minutes and it just works(TM)
<zimbatm>
yeah, too bad
<zimbatm>
MoreTea: I recommend that you deploy it on Heroku though, it's not really tested elsewhere
<zimbatm>
cost: 7 USD / month
<MoreTea>
yeah, so the issue is that this client uses a self-hosted bitbucket :P
<MoreTea>
And given that it's for the british government, it should probably run in the london region of AWS.
<zimbatm>
in that case you will need a bit of knowledge in running Erlang and Elixir
<copumpkin>
speakng AWS regions, the direct connect gizmo they released yesterday is pretty cool
<MoreTea>
zimbatm: I'll learn then ;)
goibhniu has quit [(Remote host closed the connection)]
goibhniu has joined joined #nixos-dev
<pierron>
zimbatm: I don't think we these reviews are blocking merging yet.
<pierron>
peti: //< is recursive, but it does not distribute the result, it zip the lhs and the rhs.
<pierron>
peti: the fix-point comes from the Nixpkgs fix-point, which bind the argument of the { _type = "scope"; setFun = self: …; } attribute set "setFun" function before going through the end of the fix-point.
<pierron>
peti: thus making sure that the self argument see the overriden value.
jtojnar has quit [(Quit: jtojnar)]
infinisil has quit [(Quit: ZNC 1.6.5 - http://znc.in)]
tv has quit [(Ping timeout: 248 seconds)]
infinisil has joined joined #nixos-dev
tv has joined joined #nixos-dev
<peti>
pierron: In that case, I the name "recursive update operator" feels a bit of a misnomer. I think of that functionality more in terms of a "nested update" or something.
orivej has joined joined #nixos-dev
<pierron>
peti: the recursiveUpdate function works the same way, it recurses on both operands.
<peti>
pierron: Hmm. I see. Then I think that function doesn't have a good name either. :-) It's subjective, I realize, but it goes against my intuition of what a recursive traversal of an attribute set would mean.
<peti>
pierron: Anyhow, I've created an implementation of //< in Maude. Unfortunately, I assumed incorrect semantics. Fortunately, the correct semantics are actually simpler than what I assumed. :-)
<peti>
pierron: Now I'll try to extend the RewritePattern type beyond normal attribute sets to support >:.
<pierron>
peti: Great, I will get back to the RFC over the weekend.
<peti>
pierron: I understand the purpose of ">@old:", but I don't understand ">:". The purpose of that operator is to stop the recursion, right? So x //> { a = >: { b = "foo" } } does *not* merge {b="foo"} into x, but rather replaces any "b" attribue in there outright, like // would.
<pierron>
peti: this is to have a parallel with >@name:
<peti>
pierron: But is there any occasion where use of >: would ever make sense outside of "b = >: {attrset}"?
<peti>
pierron: In particular, what is the purpose of a rewrite pattern like "a: >: a + 1", like you've used in your examples?
<pierron>
peti: { b = x: >: …; }
<pierron>
peti: the purpose is to highlight that one can do a nested update, beyond the arguments.
<pierron>
peti: this would also be useful once we add the strictly(-implicitly)-dynamically-scoped with construct that is suggested in SOS
goibhniu has quit [(Remote host closed the connection)]
goibhniu has joined joined #nixos-dev
<niksnut>
copumpkin: yes, I think that was backward compatibility with some older aws-sdk-cpp version
<niksnut>
might not be relevant anymore
<copumpkin>
oh okay
<copumpkin>
yeah, the FIXME wasn't very self-documenting :)
<copumpkin>
but I can take it out in my PR if you'd like. For both 403 and 404
<LnL>
niksnut: have you seen https://github.com/NixOS/nix/pull/1651? I would prefer to have it reviewed/merged before we start adding changes with the attribute in nixpkgs
<niksnut>
looks good to me, though maybe it doesn't need to be an attribute?
<copumpkin>
what would it be instead?
<niksnut>
just allow getpwuid
<LnL>
we could always allow it, but we don't have namespacing like linux so it does potentially leak the build user ids
<niksnut>
isn't the uid already visible?
<copumpkin>
yeah, would be nice to maximize purity wherever possible
<copumpkin>
well, won't getpwuid reveal more info than just uid?
<niksnut>
it will reveal nixbld*
<copumpkin>
hmm fair enough
<copumpkin>
I don't feel strongly either way then
<copumpkin>
assuming we ever get multi-user back on macOS :D
<LnL>
about that, could (allow signal (target same-sandbox)) maybe help?
<LnL>
or does that part not happen inside of the sandbox
<copumpkin>
I dunno, we could test sandboxng on 10.13
<copumpkin>
I assumed it wouldn't help but it might!
<LnL>
nope :(
<copumpkin>
it doesn't help?
<LnL>
yeah, just tried the syscall in a profile with only same-sandbox
<copumpkin>
ah
<copumpkin>
niksnut: if an S3 upload fails are you careful about not putting .narinfo files up without their corresponding .nars? or might I end up in a situation where I get one without the other
<rycee>
Quick question. Anybody know why there is no `doConfigure` (or `dontConfigure`)? All the other phases seem to have something like it.
<LnL>
there isnt?
<rycee>
Searching Nixpkgs actually show some packages attempting to use `doConfigure` and `dontConfigure` but from what I can tell it doesn't actually do anything.