#nixos

/

      • oida joined the channel
      • digitalmentat
        that postBuild would have to be in a non-deterministic derivation though...
      • no?
      • unless that derivation does indeed change
      • digitalmentat has quit
      • infinisil
        Actually this is a great idea
      • ldlework
        Yours or mine
      • leat joined the channel
      • infinisil
        mine of course xD
      • nah sry,
      • But a derivation needs to be stateless, and not do anything outside $out in a build
      • ldlework
        It doesn't need to do anything outside of $out, unless you're considering the git push
      • infinisil
        my idea is to add a home.extraBuilderCommands, same as with nixos, option, that adds extra commands to the builder package
      • michaelpj
        in particular, if it does anything else it'll fail with sandboxing enabled, which disables network access
      • ldlework
        but it's git-pushing an $out artifact
      • I don't think HM uses any sandboxing
      • infinisil
        and these extraBuilderCommands can put a script in $out/foo that does an additional thing, such as git push itself to github
      • michaelpj
        yes, but one day it'll probably become the default
      • in nix
      • it's just against the nix philosophy, so you're generally going to have a bad time if you try and do that
      • ldlework
        I don't even see what about a build actually changes if you do a git push it in it or not
      • since the build output is not dependent on the push, it shouldn't actually play into this nix philosophy rhetoric
      • But I'm pretty dumb
      • I've been wrong about just about every intuition I've had about nix 🤣
      • michaelpj
        from nix's point of view you're running a program that reaches out into the network - anything could happen. The simple solution is just to ban it, and do any impure stuff you need to do afterwards. That's what the activation stuff is for - actually mutating your host/the world
      • Fare has quit
      • ertes has quit
      • ldlework
        I mean you can say all network operations turn the build impure, but it seems to me that is only true if the build is casually dependent on the outcome of the network operation.
      • riclima has quit
      • If its not, then I've just probably have an ill-conception of what it means for the build to be impure
      • ToxicFrog
        "pure" generally means "without hidden dependencies or side effects", and doing a git push is definitely a side effect
      • ldlework
        Why?
      • infinisil
        what if you're not ldlework and you want to build this derivation
      • ldlework
        The build doesn't actually depend on the git push
      • infinisil
        then you don't have push access and it'll fail
      • ToxicFrog
        Then why is it part of the build?
      • ldlework
        the build output
      • michaelpj
        it's not just the build, it's the action. Nix fundamentally assumes that derivation builds are referentially transparent, but yours isn't. If you ask to build a derivation nix could build that once, multiple times, or no times and that would be fine. Except you'd get a different number of pushes
      • ldlework
        anything that might go into the cryptographic hash
      • is what I mean by depend on
      • it obviously logically depends on the git push
      • python476 joined the channel
      • But not in the techncial sense of build output determinism that you're leaning on
      • infinisil
        That's not the definition of pure though
      • ldlework
        Its totally disjoint from that
      • I don't see how any other definition could matter
      • Its like if you pinged a server in the build, in a try/except case where in all cases you don't depend on the outcome at all
      • Its meaningless to say the build "depends" on this network operation
      • if it fails or succeeds the outcome of the build is the same
      • if you are not the right user or anything else, the same build result takes place
      • wrong auth token? build still succeeds with the same cryptographic output it would have it the right auth was present and the build took place.
      • michaelpj
        ldlework: would you be surprised if you asked to build the derivation and the git push didn't occur? or occurred multiple times?
      • both of those are valid things for nix to do so long as it provides you with the right output at the end
      • ldlework
        I would be surprised if that behavior changed Nix's conception of whether it was cryptographically distinct
      • michaelpj
        the point I'm trying to make is that nix wants assumes referential transparency, not just "no effects that affect the build output". The former is what makes binary-cache substitutability okay, which is pretty critical
      • ldlework
        Yes, but in this cases it is subtitutable
      • leat has quit
      • The determinis is the same, because the network operation has literally zero casual relationship with the rest of the build
      • determinism*
      • Yes, the result on GitHub might not be deterministic
      • But Nix doesn't care about that at all
      • ylwghst has quit
      • michaelpj
        sure, my point is that Nix is going to behave as though it's referentially transparent, and if it let you have effects everywhere that would be *bad for you* because they'd be evaluated in unpredictable ways
      • ldlework
        You get all of the intended guarantees
      • of Nix
      • ris has quit
      • michaelpj
        if you do it in an activation script you have none of these problems
      • everything is predictable and composes nicely
      • riclima joined the channel
      • MichaelRaskin
        Well, if push failure fails the build, it is not referentially transparent.
      • I wonder how much sandboxing is currently the Nix default and when it will increaseÖ
      • ldlework
        Yes, but I went out of my way a few times to say that it isn't
      • MichaelRaskin
        increase…
      • infinisil
      • MichaelRaskin
        I guess Nix already sandboxes enough that the push will fail.
      • ldlework
        infinisil lol damn
      • that would've taken me the rest of the day
      • LnL
        when sandboxing is enabled it would fail yes
      • ldlework
        But the build will be the same
      • LnL
        with sandboxing you won't have any network acess
      • michaelpj
        it's not just about the build
      • ldlework
        you keep saying that
      • but with regards to Nix guarantees, afaict, it is about the build
      • Anything else is something you're adding ontop
      • About being able to also be assured about how Github is mutated
      • If you this in a sandboxed environment where there are no network operations, sure, Github wont be mutated how you expect
      • But as far as Nix can tell, and all those guarantees that come with it, it will be indifferent to the outcome
      • If there's something of import that I'm missing, I genuinely want to understand it. I'm just stating the case as I understand it.
      • michaelpj
        nix is about purely functional software packaging, if it has outside effect it's not pure, no? determinism is a benefit you get from doing this, not the primary goal
      • LnL
        but that would cause the build to fail
      • ldlework
        The package is pure.
      • LnL why would it cause the build to fail?
      • You can in the bash wrap all the git stuff in something that will never fail.
      • LnL
        sure that would work
      • MichaelRaskin
        That requires manually doing omething correctly
      • ldlework
        Which is 👍 for package design imo
      • MichaelRaskin
        Nix guarantees are about minimizing the effects of typical manual errors.
      • ldlework
        s/package/plugin
      • michaelpj
        look - why do we care about purely functional packaging? well, so we can compose things together and they work nicely without effects all over the place. That lets us do all kinds of nice things, and making more deterministic software is *one* of those things, but not the extent. So we ban effects, and that includes your github pushing
      • ldlework
        Actually why would it even cause the build to fail?
      • bash doesn't fail out when a command fails by default
      • So you'd have to go out of your way to make the git failure fail the whole script
      • LnL
        that's the default behaviour for builders
      • ldlework
        I've had the git fail when I had the wrong token, and the build still succeeded
      • I'm using runCommand
      • though if I use infinisil's new thing I wont be
      • but HM's derivation is a mkDerivation package
      • so I assume it is the same
      • michaelpj
        tbh this entire debate is basically "why can't I have benign effects like logging in a pure Haskell function?", so I defer to previous discussion
      • ldlework
        michaelpj that's useful, thank you
      • I'm genuinely interested so I'l at least try to look into that. I don't know haskell though.
      • Also, to keep this real, we're talking about dotfile management.
      • I personally want as much conveneince as possible
      • goodwill joined the channel
      • catern
        use ocaml or sml
      • maigel[m] joined the channel
      • ldlework
        michaelpj if you happen to know any good previous discussions, I'd take a look. logging is a great way to frame it.