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>
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
<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
<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