olejorgenb[m] has quit [Ping timeout: 256 seconds]
hl has quit [Ping timeout: 256 seconds]
peterhoeg has quit [Ping timeout: 240 seconds]
nocent has quit [Ping timeout: 255 seconds]
grahamc has quit [Ping timeout: 248 seconds]
stites[m] has quit [Ping timeout: 255 seconds]
teh[m] has quit [Ping timeout: 255 seconds]
rycee has quit [Ping timeout: 255 seconds]
dtz has quit [Ping timeout: 255 seconds]
regnat[m] has quit [Ping timeout: 240 seconds]
sphalerite has quit [Ping timeout: 240 seconds]
copumpkin has quit [Ping timeout: 256 seconds]
pstn has quit [Ping timeout: 265 seconds]
primeos[m] has quit [Ping timeout: 265 seconds]
adisbladis[m] has quit [Ping timeout: 256 seconds]
moredread[m] has quit [Ping timeout: 276 seconds]
hedning[m] has quit [Ping timeout: 276 seconds]
florianjacob has quit [Ping timeout: 276 seconds]
infinisil has quit [Ping timeout: 240 seconds]
mbrgm has quit [Ping timeout: 260 seconds]
infinisil has joined #nixos-dev
mbrgm has joined #nixos-dev
<Dezgeg> maybe we should make the i686 ISO part of the tested job if in practice it's required for the channel to pass
florianjacob has joined #nixos-dev
Sonarpulse has quit [Ping timeout: 256 seconds]
pie_ has joined #nixos-dev
<shlevy> LnL: Just reference it
<shlevy> LnL: What specifically do you want to do?
<shlevy> Oh, sorry, there's a special builtin to make it not depend on the outputs...
<shlevy> LnL: unsafeDiscardOutputDependency
adisbladis[m] has joined #nixos-dev
pstn has joined #nixos-dev
grahamc has joined #nixos-dev
regnat[m] has joined #nixos-dev
sphalerite has joined #nixos-dev
olejorgenb[m] has joined #nixos-dev
nocent has joined #nixos-dev
dtz has joined #nixos-dev
stites[m] has joined #nixos-dev
primeos[m] has joined #nixos-dev
hedning[m] has joined #nixos-dev
copumpkin has joined #nixos-dev
hl has joined #nixos-dev
peterhoeg has joined #nixos-dev
teh[m] has joined #nixos-dev
rycee has joined #nixos-dev
moredread[m] has joined #nixos-dev
mbrgm has quit [Ping timeout: 264 seconds]
mbrgm has joined #nixos-dev
moredread[m] has quit [Ping timeout: 255 seconds]
primeos[m] has quit [Ping timeout: 252 seconds]
hedning[m] has quit [Ping timeout: 255 seconds]
regnat[m] has quit [Ping timeout: 255 seconds]
dtz has quit [Ping timeout: 255 seconds]
grahamc has quit [Ping timeout: 255 seconds]
olejorgenb[m] has quit [Ping timeout: 255 seconds]
teh[m] has quit [Ping timeout: 256 seconds]
stites[m] has quit [Ping timeout: 260 seconds]
adisbladis[m] has quit [Ping timeout: 277 seconds]
peterhoeg has quit [Ping timeout: 240 seconds]
nocent has quit [Ping timeout: 255 seconds]
sphalerite has quit [Ping timeout: 255 seconds]
copumpkin has quit [Ping timeout: 256 seconds]
hl has quit [Ping timeout: 256 seconds]
pstn has quit [Ping timeout: 256 seconds]
rycee has quit [Ping timeout: 276 seconds]
florianjacob has quit [Ping timeout: 276 seconds]
LnL has quit [Ping timeout: 260 seconds]
kgz has quit [Ping timeout: 248 seconds]
kgz has joined #nixos-dev
orivej has quit [Ping timeout: 276 seconds]
Sonarpulse has joined #nixos-dev
LnL has joined #nixos-dev
orivej has joined #nixos-dev
ma27 has joined #nixos-dev
pstn has joined #nixos-dev
grahamc has joined #nixos-dev
ma27 has quit [Ping timeout: 255 seconds]
primeos[m] has joined #nixos-dev
hedning[m] has joined #nixos-dev
peterhoeg has joined #nixos-dev
moredread[m] has joined #nixos-dev
teh[m] has joined #nixos-dev
adisbladis[m] has joined #nixos-dev
rycee has joined #nixos-dev
florianjacob has joined #nixos-dev
stites[m] has joined #nixos-dev
copumpkin has joined #nixos-dev
sphalerite has joined #nixos-dev
olejorgenb[m] has joined #nixos-dev
regnat[m] has joined #nixos-dev
hl has joined #nixos-dev
nocent has joined #nixos-dev
dtz has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
<LnL> shlevy: ah! that sounds perfect
ma27 has joined #nixos-dev
goibhniu has joined #nixos-dev
ma27 has quit [Ping timeout: 276 seconds]
orivej has joined #nixos-dev
<peti> shlevy: Yeah, pushing it to haskell-updates would probably be a good idea so that it gets tested.
alunduil has quit [Ping timeout: 260 seconds]
<gchristensen> Dezgeg: I agree
orivej has quit [Ping timeout: 240 seconds]
<gchristensen> niksnut: your nixops-on-dynamodb work might have gotten easier with #865
<LnL> is there a way to get the outputHash of a path literal?
ma27 has joined #nixos-dev
ciil has quit [Quit: leaving]
ciil has joined #nixos-dev
orivej has joined #nixos-dev
alunduil has joined #nixos-dev
JosW has joined #nixos-dev
<copumpkin> niksnut: is there any way to get a path reference to match hash with a FO derivation of the same contents? I sort of need that
<copumpkin> I think not, right? because of what goes into the store path?
<niksnut> no
<copumpkin> can we add some sort of builtin to make it so? I'm not sure what, but it's a useful property to have to support monorepo-style development
<copumpkin> (where you want both local code references and don't want to deploy the entire source tree to prod)
<shlevy> Maybe added to builtins.path
<copumpkin> that's what made me think of it, yeah
<copumpkin> there's no fundamental reason the hashing scheme needs to be different, right?
<copumpkin> it'd just be a massive pain to change now?
<shlevy> It needs to be different for flat vs recursive
<copumpkin> yeah
<copumpkin> also, maybe builtins.path is sufficient for my needs
<shlevy> Otherwise nix wouldn't be able to distinguish a recursive path from a flat nar of that path
<copumpkin> since to "freeze" for deployment I just need to inject the expected hash
<shlevy> But yeah, whether it came from a fixed output derivation or a path added to the store shouldn't matter for the output path
<copumpkin> and that'll get substituted, right?
<shlevy> Hmm not currently, but we could do that
<copumpkin> well, maybe it doesn't even need to get substituted
<shlevy> Currently with a hash, if it already exists it won't get added again but it doesn't check caches
<gchristensen> let's be cautious not to be overly generous in what gets in to 2.0, 2.1 can come soon after
<copumpkin> yeah, it doesn't actually need to get substituted
<copumpkin> I just need the overall hash to be computed in the same way, whether or not the files are present locally
<copumpkin> which I think is true
<shlevy> Yeah
<copumpkin> e.g., I have
<copumpkin> mkDerivation { src = thing; name = "haha"; }
<copumpkin> let thing = if dev then ./path else builtins.path { sha256 = <injected by deployment process>; } in
<copumpkin> now my mkDerivation will have the same hash in prod, even though the source code isn't there
<copumpkin> (but it's fine because it's in my binary cache)
<copumpkin> and I never actually need src in the deployed scenario, I just need to know its hash to compute the hash of the "haha" derivation
<shlevy> I think currently builtins.path will fail if the source isn't there is my point
<shlevy> But a test verifying that would be nice :)
<copumpkin> ah
<copumpkin> can we make it not, if the source isn't needed?
<copumpkin> I mean, is it fundamental
<copumpkin> this would resolve a long-standing annoyance I've had with nix for internal deployment
<shlevy> We can relatively easily make it not fail if it's in the cache, would take some thinking but maybe there's a nice way to make it only fail at derivation build time
<copumpkin> yeah, I guess in some way it makes path references into invisible .drvs
<copumpkin> which might not be desirable in all situations
<shlevy> Yeah no with the current model there's no way to do it nicely directly with idiomatic nix usage. We could make it so --readonly-mode succeeds, and then you can do a readonly instantiate of the outPath and nix-store -r that
<shlevy> But we can't add a drv to the store that depends on a path you don't have
<copumpkin> yeah
<shlevy> Unless we added a "fixed-output" flag or similar to builtins.path that made it behave like afixed output drv :)
<copumpkin> hmm
<copumpkin> fffuuu :)
<copumpkin> well, then the hash changes again, right?
<copumpkin> or we'd make it behave like one, but not be hashed like one
<copumpkin> could give it a new type of builtin: builder
<copumpkin> like fetchurl got
<shlevy> Bleh
<shlevy> Yeah, it would need that, but it's not pleasant
<shlevy> Actually, it's worse than not pleasant, not doable in the current model IMO
<copumpkin> it's awkward
<shlevy> Since the path should be read in *as the eval user*, but as a builtin it will be read *as the daemon user*
<copumpkin> do you see what I'm going for though when I say monorepo deployment?
<shlevy> I don't want nix daemon reading my $HOME
<shlevy> Can't you just give the final out path to your deployment box somehow?
<shlevy> That's how e.g. hail works
<copumpkin> I guess I should just state my actual goal in an issue rather than trying to co-opt builtins.path for it :)
<copumpkin> well, I want it to behave like a channel
<copumpkin> but a channel of my internal company stuff
<shlevy> Sure, you can still do that
<shlevy> your channel just has foo = { outPath = builtins.storePath /nix/store/whatever; }
<copumpkin> how do I smoothly deploy when the .nix files manage local builds and deployment?
<shlevy> Maybe an issue would help :D
<copumpkin> the storePath thing I guess could be conditional on platform
<copumpkin> but I have multiple platforms at play here
<copumpkin> maybe not awful, but definitely not pleasant
<copumpkin> I wrote about it on nix-dev a bajillion years ago
<copumpkin> I can flesh that out into an issue
<copumpkin> the nix-copy-closure advice people gave isn't sufficient for me, partly because I have autonomous systems for deployment (think an ASG in EC2)
<copumpkin> and partly because developer boxes want some of the software too
orivej has quit [Ping timeout: 248 seconds]
<manveru> anyone has used that?
Sonarpulse has quit [Ping timeout: 255 seconds]
<cransom> i have. it works as advertised, but i'm not sure what the big draw is compared to a `nixos-rebuild switch --target-host foo` unless it just works slightly better on a non nixos machine
<gchristensen> I agree, cransom, I suspect people just don't realize nixos-rebuild has that magic
<cransom> oh, i don't recall if nixos-rebuild borrows sudo. that might be the only other difference i've noticed.
<manveru> yeah, can't say i've heard of that before, thanks :)
<gchristensen> it can also be used to perform remote builds without the node being setup as a remote builder
<cransom> yeah. i used --build-host and --target-host a lot on laptops with cpu power equivalent to a ritz cracker and it made life much faster and less leg burnier.
Sonarpulse has joined #nixos-dev
<Sonarpulse> so no new features for 1.12 is good
<Sonarpulse> but....
<Sonarpulse> attrs paths in --arg and --argstr
<Sonarpulse> would really help cross Ux
<Sonarpulse> shlevy dtz ^
goibhniu has quit [Ping timeout: 240 seconds]
<shlevy> Sonarpulse: Patches welcome ;) Hopefully 2.1 will be quickly after 2.0
<Sonarpulse> shlevy: can't argue with that!
<dtz> Sonarpulse: my brain is flooded with my work context :P; what do you mean "attrs paths in --arg and --argstr"?
<Sonarpulse> dtz: --arg foo.bar.baz 'expr'
<dtz> oh! like --argstr crossSystem.config "blahblah"?
<Sonarpulse> so we can do -argstr crossSystem.config x86_64-unknown-linux-misp
<dtz> :D yeah!
<dtz> okay great
<gchristensen> in order for that to work, shouldn't we first make `.` an illegal character in attribute names?
<Sonarpulse> gchristensen: we already have that ambiguity with -A, right?
<shlevy> gchristensen: Yeah, this ambiguity already exists and we accept it
<gchristensen> arg
<gchristensen> in order for this to be sane, could we start warning on `.`s in attribute names? :P
<Sonarpulse> right now invalid --arg are just ignored
<Sonarpulse> which sucks
<Sonarpulse> but relates to the thing that clever found where
<Sonarpulse> --arg tried along every attr of the -A path
<Sonarpulse> (e.g. if you have { foo }: { bar = { foo }: { bar = ...; }; }, `--arg foo ... -A bar.bar` will work
<dtz> (thanks!)
orivej has joined #nixos-dev
<shlevy> Hmm, actually I think you can't have arguments with .s in the name, can you?
<shlevy> Nope
<shlevy> gchristensen: ^
<shlevy> Oh, well if we're nesting sets I guess you can
<shlevy> IMO if you want to set a nested value with a . in the name you should just pass a nix expression :P
<gchristensen> I'm not referring to passing them in via the CLI, but warning / prohibiting them always
<pie_> is it possible to blacklist pakages?
<pie_> blacklist/whitelist
<gchristensen> what for?
<pie_> just wondering
<shlevy> gchristensen: Eh, they're permitted for good reason IMO
<gchristensen> you could possibly use something like allowUnfreePredicate, pie_, https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/check-meta.nix#L47 but maybe not exactly what you need
<gchristensen> shlevy: yeah, it would be a nightmare if it was prohibited
<pie_> ah hm
<niksnut> doesn't mean we have to support them in --arg / --argstr though
orivej has quit [Ping timeout: 276 seconds]
<shlevy> Agreed
<shlevy> Running the nix test suite in a nix build fails because nix thinks it's recursive nix, which it kind of is 😂
<dtz> lmao
<dtz> ITS_OKAY_THIS_ONE_TIME=1
<dtz> :P
<dtz> although presumably they're using different daemons, right? Which should be okay? O:)
<dtz> jk I get test failures in nix-shell now because in restricted mode? haha
<dtz> (don't worry until other issues are solved....)
orivej has joined #nixos-dev
JosW has quit [Quit: Konversation terminated!]
ma27 has quit [Ping timeout: 256 seconds]
<Profpatsch> What’s the current stance on eval-time dependency file conversion?
<Profpatsch> e.g. converting a lock file into a nix dependency file on-the-fly (pure transformation) and then use that to build the project?
<Profpatsch> Instead of commiting the generated nix file into nixpkgs.
<Profpatsch> It probably depends on how the evaluator on hydra works and whether that blocks evaluation, right?
<dtz> would the lock file be committed instead? or do you mean some sort of IFD (project source being result of a derivation)?
<Profpatsch> dtz: No, the lock file would be in the project source code, commited by the project authors.
<Profpatsch> If there’s no upstream lock, it makes more sense to commit the generated nix files into nixpkgs.
<pie_> <pie_> error: syntax error, unexpected $undefined, at /mnt/data/gscan/nixpkgs/pkgs/tools/graphics/gscan2pdf/default.nix:39:14
<pie_> <pie_> preBuild = ``perl Makefile.PL``
<pie_> <pie_> thats a weirdass error for missing a semicolon
<pie_> would it be fair to request a better error message?
<pie_> * the problem isnt the semicolon its accidentally using backticks
<dtz> Profpatsch: if we're talking about nixpkgs, I don't think you can make the build depend on a transformed version of a file not part of nixpkgs (without invoking import-from-derivation, IFD)-- which breaks "nix-env -qa" and is definitely forbidden in nixpkgs.
<dtz> (since presumably the whole point of transforming it is to make dependencies/etc visible at the nix layer...)
<Profpatsch> Right, I assumed that much.
<dtz> a related problem is when the transformation is "identity" ;) and the file upstream is a default.nix.... in other words, annoying duplication of information in the "best" case where upstream uses nix already
<dtz> which always makes me slightly sad. My projects that have nix build support are the most annoying to handle in nixpkgs-like trees xD :(
<Profpatsch> It’s an inherent problem.
<Profpatsch> Either the information is local or it’s not, so unless we have a global monorepo of every source on this planet (which we should totally do!), tough luck.
<dtz> yeah :(. "annoying" is unfair, agreed.
<dtz> hehe yes, answer is definitely global monorepo :D ;)
<Profpatsch> Hrm, I can imagine lifting nixpkgs in the global monorepo would be a good next step actually.
<Profpatsch> It does solve the problem of duplicated code, but not the problem of nixpkgs size. :P
taktoa has joined #nixos-dev
<taktoa> can someone explain to me why the source code of nix uses tabs for indentation (and this is enforced in the .dir-locals.el) instead of spaces? I mean I get that it's like a holy war or whatever blah blah blah but there's no real advantage to using tabs (space saving??? is this 1977???) and it's REALLY hard to get right (e.g.: emacs M-x tabify will turn spaces that are inside strings into tabs!), whereas spaces Just Work. is it just niksnut's
<taktoa> preference or something? also, why don't we use `clang-format` on the nix codebase? aren't the benefits of automatic formatting pretty well established at this point? I've heard people argue that it fucks up `git-blame`, but that's only true for commits before the clang-format usage goes into effect...
<gchristensen> taktoa: it sounds like you've answered each point in your message already
<taktoa> I'm mostly venting
Sonarpulse has quit [Ping timeout: 276 seconds]
<gchristensen> <3
<taktoa> I'm working on making the line editor for the new nix-repl use https://github.com/jhawthorn/fzy for listing completions
<dtz> taktoa: oh hi! Also YAY :D
<taktoa> hey
* dtz likes using code bases with .clang-format and just applies it and everyone gets to talk about code and be productive instead of formatting complaining
<taktoa> yeah, me too!
<dtz> since even "clang-format makes my precious ugly" is "propose change to our .clang-format or submit bug to clang-format, otherwise sorry but oh well"
<dtz> and i thought I'd regret it a little but... nope! :D
<Dezgeg> where does nix codebase use tabs?
<taktoa> omg I'm an idiot... I misread .dir-locals.el
<taktoa> lmao
<shlevy> niksnut: Can you give dtz nix commit bit?
<taktoa> niksnut: I'm sorry I impugned your taste in whitespace; I now realize that the indent-tabs-mode bit was the inverse of what I thought it was
<taktoa> +1 on dtz having the commit bit