<{^_^}>
undefined variable 'never' at (string):471:1
<hexa->
gotcha
<worldofpeace>
eyJhb: I actually was going to say "shit"
<hexa->
NixOS is older than Docker. They are solving the same task, but NixOS is way less popular.
<hexa->
right.
<hexa->
I'll scrub my browser history next
<eyJhb>
I actually think, that we have seen this article a couple of times now?
<eyJhb>
worldofpeace: :o damn
<eyJhb>
`To get fast or enterprise support.` -> Tweag?
<eyJhb>
ALso, comparing any OS to the biggest OSs on Linux is not really fair I guess.
<eyJhb>
`It is not possible just to upgrade the kernel from “ver1” to “ver2”. New kernel will bring whole set of system packages and their dependencies with it. Do not know if it is safe. Will test it soon.
<eyJhb>
Well, not really true, is it
<worldofpeace>
But lol, that's literally the point of it!
<eyJhb>
`<meta property="og:updated_time" content=2018-11-19T00:00:00Z />` yeah we have seen this before :D
<eyJhb>
There are some points, and the documentation is REALLY REALLY one of them. Holy hell I miss some good documentation for Nix
<worldofpeace>
eyJhb: Thx, I was trying to find the date
<energizer>
worldofpeace: that article has amazing SEO, it's in my search results all the time
<worldofpeace>
but it's funny though, I actually just searched "nixos" into duckduckgo.
<worldofpeace>
energizer: exactly
<eyJhb>
I feel like having better documentation would fix a lot of things, and might bring the noise down in #nixos + if you add some more CI and a workflow on this. It would be a amazing ! :D
bennofs[m] has quit [Quit: Idle for 30+ days]
<worldofpeace>
probably going to happen soon ™
<eyJhb>
Both things? Because I mostly have dreams about the documentation right now :p
<eyJhb>
A cleanup of the spaces would be grand as well..
<worldofpeace>
eyJhb: probably documentation ™
<eyJhb>
Can you give more information? :o Is there anything I can see that is in-progress?
angerman has quit [Ping timeout: 272 seconds]
<worldofpeace>
I mean, considering we could use a format people (including the devs) don't pain to use
angerman has joined #nixos-dev
<eyJhb>
Couldn't parse that sentence, it is the early hours for me
<eyJhb>
"a format people"?
<worldofpeace>
-> markdown
<eyJhb>
AH! I was very confused on how you would format people.
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
<worldofpeace>
If only
<eyJhb>
But wouldn't the documentation be based on e.g. this ? https://github.com/NixOS/nixpkgs/blob/master/lib/attrsets.nix#L15-L23 also, the man issue I see, is that there are wrappers etc. in nixpkgs random places, that also should be included. But just having lib woudl be a good start!
lopsided98 has joined #nixos-dev
<worldofpeace>
eyJhb: full disclosure, I haven't slept 😂 but that as much is normal for me
<eyJhb>
You still have time worldofpeace ! :D
orivej has quit [Ping timeout: 264 seconds]
<eyJhb>
Else you are going to have a loooong day tomorrow :p
<worldofpeace>
eyJhb: two days in one isn't uncommon either. how else is perfection reached if u sleep like some mortal
<eyJhb>
I tried to do that for a exam, I was close to dead. I cannot handle anything more. Get like half a glass of redwine yesterday, and I feel hungover today. Keep in mind, I am less than 25 years old....
<worldofpeace>
*moves to -chat
pie_ has quit [Remote host closed the connection]
orivej has joined #nixos-dev
pie_ has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
<siraben>
How does Nix find Python libraries/
<siraben>
?*
<symphorien[m]>
it patches executables to add store paths in sys.path at startup
<symphorien[m]>
nix-shell adds buildInputs to PYTHONPATH
<siraben>
Ah I see
<energizer>
i thought it used sitecustomize.py but maybe i misremember
__monty__ has joined #nixos-dev
WilliButz has quit [Ping timeout: 256 seconds]
hexa- has quit [Ping timeout: 244 seconds]
WilliButz has joined #nixos-dev
<ehmry>
dhall doesn't count, dhall is weird
<ehmry>
do we have a real or theoretical language that uses nix as its package manager for libraries?
<ehmry>
well it seems we have the problem that packages that specify their dependencies somewhere outside nixpkgs, and synchronizing that takes labor, so a nix native language would not formally specify dependencies in the package repos, but in the registry of nxi packages for that language?
<ehmry>
and unpackaged software developers would need to fork or overlay the registry with their package inserted?
<ehmry>
I'm just thinking about how updating fixed-output hashes is something that must be done once but can be automated, but specifying dependencies is something that usually has to be done twice?
<__monty__>
Depends on the approach. You could do constraint solving like cabal does. That way people can back your packages by any nixpkgs containing a compatible set of deps.
<bennofs>
__monty__: lack of Windows support in Nix would be one problem for lang package managers
<__monty__>
Hmm, but would providing such support from scratch be easier than fixing nix/nixpkgs?
<ehmry>
is there not an incentive to centralize dependency information as much as possible
<bennofs>
well if you only deal with packages for your own lang it's much easier than trying to get all of nixpkgs working on windows.
<__monty__>
Unless you mean that's why they just take the C approach of "🙌 *your* responsibility to make the compiler find the deps?"
<ehmry>
windows doesn't matter, those people can just do whatever in chrome
<__monty__>
If your packages don't have external deps from nixpkgs is there a compatibility problem actually? And if they *do* have external deps isn't providing a nice way to provide them on linux and macOS still better than nothing?
<__monty__>
Or is nix that incompatible with windows?
<symphorien[m]>
stdenv is extremely incompatible with windows, to the least
<ehmry>
if packages were language pure, then its easy, but if depedencies are things outside the language, then you need nix?
<__monty__>
Ok, that's a pretty big issue but it's still a nixpkgs-specific issue, no?
<symphorien[m]>
yes, but if you dump nixpkgs, there is not much advantage reusing nix instead of reimplementing the idea like cabal does, right ?
<bennofs>
yeah ofc it could me made to work. But it's probably easier to just implement nix-like behaviour in your pkg manager, especially if you already have a pkg manager
<bennofs>
i mean, reimplementing the idea is not hard, right? just store all build artifacts in $STORE/hash-of-build-config and you're basically done with the part the Nix would give you
<bennofs>
also for example cabal would still have to do dependency resolution itself
<bennofs>
generating nix expressions from dep resolution results and then calling nix to perform the build would be possible, but not much easier than just calling the build tool (ghc) yourself. And using nix would make things like using a locally installed GHC harder.
<__monty__>
Well, the advantage to me seems like the future rewards. You can specify external deps *now* (except windows) but the more languages adopt nix the more external deps you could specify and eventually either nixpkgs gets windows compatibility or someone starts winixpkgs.
<bennofs>
using nix in your pkg manager still doesn't mean that you can easily compose the expressions generated by different lang pkg managers
<symphorien[m]>
also, using nix kinda prevents non-root installation
<ehmry>
reusing what is already packaged is at least as useful as whatever features nix provides as a package manager
<symphorien[m]>
(I know, user namespaces, proot, etc., been there, done that, but it's a pile of hacks)
<bennofs>
"You can specify external deps *now* (except windows)" so if you still need some kind of solution for Windows *right now*, then making that same solution work on other platforms could be easier than special-casing Windows
<__monty__>
bennofs: Re the composition I just meant specifying them as buildInputs and then their ecosystem would build and provide the executables or libraries. Not sure why that would pose a problem?
teto has joined #nixos-dev
<__monty__>
Ah, but my "solution" for windows is the non-solution C uses. "Set up your environment correctly, it's not my responsibility." : )
<bennofs>
__monty__: well, for that, basically all you'd need would be a $LANG_PACKAGE_PATH and a command that installs a package into $out. Now wonder why most languages already fail at that :)
<bennofs>
and also, nix doesn't solve the problem of version resolution or automating lock files. There's niv, but that's not part of Nix
<__monty__>
Once any language implements generic-enough constraint solving in nix though, everyone could benefit.
<bennofs>
not sure if constraint solving belongs in nix
<sterni>
well this would mean packaging multiple versions of a package in the first place
<sterni>
and I guess would make eval time even worse because constraint solving would be done at eval time in the end
<sterni>
much easier writing tooling to do constraint solving on some data basis and generate a package set
<sterni>
of course the added problem that you have to solve a whole package set instead of a single package
<sterni>
but that is something you want anyways probably
<__monty__>
Doesn't have to imply packaging multiple versions. Would just make it possible to specify constraints that can determine whether or not the nixpkgs you chose to go with is compatible.
<ehmry>
and then you would have to make an expensive walk back in history to find previous versions?
<__monty__>
And with IFD constraint solving doesn't have to be done in nix, I guess. And materialization can alleviate the eval time problem a little bit.
<ehmry>
I believe spack is a package manager does constraint solving already
<ehmry>
and the solver is tweakable?
<sterni>
could probably also use existing SAT solvers like opam does
<siraben>
Is satisfying version constraints NP-hard?
<__monty__>
Is spack based on Guix? Just because I seem to recall that being used for supercomputers too.
<bennofs>
siraben: usually it is, at least if you add things like platform-dependent dependencies and feature flags
<siraben>
I can imagine a naïve backtracking solver for constraints
<siraben>
Ah I think the reduction to SAT is literally just translating the boolean expressions to version constraints, I see
<dhess>
(I'm using 3 different binary caches: cache.nixos.org, hydra.iohk.org, and our own S3 cache, populated by our own Hydra.)
<dhess>
The solution so far is just to retry the command (or Hydra evaluation) a few times. Eventually it works.
evils has quit [Ping timeout: 260 seconds]
cole-h_ has quit [Ping timeout: 265 seconds]
AlwaysLivid has quit [Ping timeout: 268 seconds]
<domenkozar[m]>
dhess: it would help to find out from what cache it's coming and what's the etag header in response
evanjs has quit [Read error: Connection reset by peer]
evanjs has joined #nixos-dev
<dhess>
domenkozar: Any idea how to do that? All I get is this: hydra-eval-jobs: src/libfetchers/tarball.cc:67: nix::fetchers::DownloadFileResult nix::fetchers::downloadFile(nix::ref<nix::Store>, const string&, const string&, bool, const Headers&): Assertion `request.expectedETag == res.etag' failed.
<domenkozar[m]>
--max-jobs 1 -vv
<dhess>
domenkozar: This is where you tell me I should be using Cachix :D
<domenkozar[m]>
:D
<domenkozar[m]>
well need to see if that punchline is needed hehe
<dhess>
(we are now, but we have this massive S3 cache as well)
<dhess>
domenkozar: ok cool I'll try that next time this occurs. It's unfortunately only sporadic and not particularly reproducible
<domenkozar[m]>
that's really weird
<domenkozar[m]>
haven't seen it before so seems like you're extra lucky :)
<dhess>
I also wiped the .cache/nix dirs in the various Hydra homedirs, root, and my own, but that does not seem to have helped
<domenkozar[m]>
it seems like it's assuming etag is content addressed
<domenkozar[m]>
could be you're rebuilding something that was GC-ed
<domenkozar[m]>
has a different etag then
<dhess>
domenkozar: we only started seeing it after migrating from one Hydra to a new one. Also after I enabled these caches in the /etc/nix/nix.conf on the Hydra and other build machines (previously they were only using cache.nixos.org).
<dhess>
but I don't think it's related to the cache settings on the Hydra/build machines because I'm also seeing it on my local machine, which has used these 3 caches for awhile
<dhess>
domenkozar: if that were the case (trying to rebuild something that was GC'ed) then why would it eventually work after a few tries?
<domenkozar[m]>
I'd guess that tarball cache expires
<domenkozar[m]>
does it automatically retry and succeed or does it work after manual intervention?
<domenkozar[m]>
that would explain it with the time gap
<dhess>
domenkozar: obviously when it's a nix-build on my local machine, the latter.
<dhess>
so usually just a few seconds later.
<dhess>
on the Hydra, it's unfortunately difficult to tell. Usually this causes the hydra-eval-jobs process to core dump. Then sometimes it seems to retry eventually, and other times I need to restart the hydra-evaluator service.
<dhess>
We did only recently start using hydra.iohk.io. I wonder if that cache is causing the issue.
evanjs has quit [Ping timeout: 264 seconds]
<domenkozar[m]>
my other guess would be that one of the caches is returning weird etags, but that seems very unlikely?
<domenkozar[m]>
I know IOHK maintains a fork of hydra
<domenkozar[m]>
so it could be they changed something there :shrugs:
<domenkozar[m]>
too many caches at play :)
<dhess>
We've been patching upstream Hydra for over a year (some of the patches are from IOHK's fork) and have had no issues until just a few days ago.
<dhess>
but we're not running IOHK's forked version. It's mostly up-to-date.
<dhess>
the patches are to fix the scheduler and for reading GitHub auth tokens from a file.
<dhess>
"fix" the scheduler as in, maybe it fixes it and maybe it doesn't :)
<domenkozar[m]>
heh
<dhess>
We've also recently switched to Flakes for many of our projects. So unfortunately a lot has changed in the last 2 weeks and it could be any of these things :\
<domenkozar[m]>
probably not used when using S3 :shrugs:
evanjs has joined #nixos-dev
<domenkozar[m]>
dhess: nah, so you're always hitting S3
<domenkozar[m]>
dhess: also I'm not familiar with nix master code, could be this is used by any url
<domenkozar[m]>
with the flakes
<domenkozar[m]>
so that would mean one of your flakes is returning flaky etag :D
<domenkozar[m]>
that's most likely I'd say
<domenkozar[m]>
in general what Nix expects there is wrong, there's no such invariant such as that etag shouldn't change
jonringer has joined #nixos-dev
<domenkozar[m]>
really that equality should move to the if statement
<gchristensen>
yeah pretty sure the only requirement on etags is that if something changed it must be regenerated, but not a statement to the opposite: that if nothing changed, it must not change
<domenkozar[m]>
I'll make a patch, should be quick
<domenkozar[m]>
ah it's not that simple as filetransfer is already doing the wrong thing :)
<dhess>
domenkozar: What's the implication of just dropping that particular assertion?
<dhess>
are you saying that you think it's just an incorrect assumption by Nix?
<domenkozar[m]>
it seems like response is 304
<domenkozar[m]>
but etag is different than the matched one
<dhess>
ahh
<domenkozar[m]>
not sure if that's per http spec or not
<domenkozar[m]>
even if it's not, that's the reality and Nix should recover
<dhess>
but eventually (and sometimes only a few seconds later) it passes. How?
<dhess>
I could see this being some weird CDN thing, but it's odd that it only just started happening
<dhess>
and that nobody else seems to be encountering it.
<dhess>
(unless it's just our S3 cache, which seems unlikely.)