<{^_^}>
#50452 (by P-E-Meunier, 1 day ago, open): Rust build-support: fixing a compilation error in some crates
<thoughtpolice>
andi-: I know rust re-compilation is generally expensive but I think buildRustCrate changes aren't quite as bad (it's not used as much I think?) ofborg only lists ~100 rebuilds, so I think that's pretty ok
<andi->
thoughtpolice: sure, let me just comment on P-E-M's last question… I think we need test cases in the `tests/` subfolder of the build-rust-crate thingy.. Those heuritisc/problematic packages should be added for future testing.
<thoughtpolice>
andi-: I think in my case proc-macro2 got pulled in by failure-derive, so maybe just committing a carnix package for that and trying to build it would work
<thoughtpolice>
I'll see if it does
<andi->
check the tests in the folder. I alreayd have one that has a larger list of dependencies.. maybe just "merging" that carnix generated file there would be a good thing to do. I really do not want to bloat nixpkgs with those :/
<thoughtpolice>
the brotli one? that one isn't too bad at least, but I'll see if I can merge them somehow
<andi->
thoughtpolice: Just today I found `cargo build --build-plan` which could serve as a proper replacement for all the hacky things we do there. Maybe we can have a nice(r) way to build rust crates using that with the dependency information. It could remove the need for carnix entirely.
<thoughtpolice>
andi-: Honestly it's arguably a bug in proc-macro2, as well
<thoughtpolice>
It just silently continues if the compiler minor version can't be found? That... seems wrong, tbh.
<thoughtpolice>
Like I can't imagine there are many cases when RUSTC is unset. And if there are, like this case, it clearly results in a totally broken build? So why do it silently?
<thoughtpolice>
Maybe I should file something upstream about this too
<{^_^}>
alexcrichton/proc-macro2#153 (by thoughtpolice, 9 seconds ago, open): Consider failing loudly when RUSTC is unset in build.rs
<thoughtpolice>
andi-: Also, looking at --build-plan, it certainly looks like it could fulfill that roll. Looking at its output, the main thing it would need is to track source repositories/non-crate dependencies better. That's a problem with Carnix I'm currently trying to work around (annoyingly)
<thoughtpolice>
andi-: Mainly, it looks like it lacks any sort of information about where a build came from. So for example I want to clone repository foo.git, and retrieve packages foo-bar, and foo-baz. But by the time Cargo emits the build plan, it's already thrown that information away -- it already checked out the repository
<thoughtpolice>
That's made worse because Cargo also knows how to scan manifests/repositories for Cargo.toml files to find a dependency in some subdirectory, e.g. I just point the source of 'foo-bar' to foo.git and Cargo magically figures out the subdir. Honestly I feel this is a misdesign, but oh well
<thoughtpolice>
If it could tell you 1) where it came from and 2) where the resolved Cargo file is, that would be ideal and almost perfect.
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 268 seconds]
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 244 seconds]
lassulus_ is now known as lassulus
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 268 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
drakonis has quit [Quit: WeeChat 2.2]
orivej has quit [Ping timeout: 240 seconds]
garbas has quit [Quit: WeeChat 2.3]
<andi->
thoughtpolice: the main takeaway isbthst it is relatively easy to implement since you can have custom executors in/around cargo
drakonis_ has quit [Ping timeout: 272 seconds]
lopsided98 has quit [Ping timeout: 264 seconds]
Lisanna_ has joined #nixos-dev
lopsided98 has joined #nixos-dev
orivej has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
<timokau[m]>
If I have a variable `a = "xorg.xmodmap"`, is there a way to do something like `pkgs.${a}` mean `pkgs.xorg.xmodmap`? When doing it naively nix assumes the dot is part of the attribute name.
<timokau[m]>
I guess I'm looking for something like `eval` in nix
<simpson>
Hm, interesting. I don't think that there's builtin syntax, but maybe there's a library function somewhere.
<qyliss>
there’s builtins.tryEval…
aszlig has quit [Quit: Kerneling down for reboot NOW.]
aszlig has joined #nixos-dev
<timokau[m]>
qyliss: Thats nearly what I need, but if I understand correctly that doesn't return the output of the evaluation
<timokau[m]>
It just echoes its input if the evaluation was successful
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
<timokau[m]>
Oh `tryEval` doesn't actually evaluate a string. It evaluates a nix expression. Which is why it echoes back any string.
<ekleog>
> let a = "xorg.xmodmap"; in lib.attrByPath (lib.splitString "." a) (throw "not found") pkgs
<ekleog>
by default the dot is part of the attribute name because eg. services.nginx.virtualHosts."example.com" = ...
<timokau[m]>
ekleog: Just came up with `nestedSubattr = cur: attrs: if attrs == [] then cur else nestedSubattr cur.${lib.head attrs} (lib.tail attrs);` but your version is a little less horrible :D
<timokau[m]>
Thanks!
drakonis has quit [Ping timeout: 245 seconds]
<ekleog>
your version looks like exactly lib.attrByPath, btw :p
<ekleog>
(as you're handling a list and not a .-separated string)
<timokau[m]>
Well at least I don't have to maintain it myself ^.^
<ekleog>
heh ^^
FRidh has quit [Quit: Konversation terminated!]
genesis has quit [Remote host closed the connection]
drakonis has joined #nixos-dev
genesis has joined #nixos-dev
phreedom has quit [Ping timeout: 256 seconds]
lassulus has quit [Ping timeout: 252 seconds]
drakonis1 has joined #nixos-dev
drakonis has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
* gchristensen
waves
<samueldr>
doesn't waving hurt?
<samueldr>
and: hi!
<gchristensen>
actually, no, it doesn't hurt
<gchristensen>
compared to my right elbow surgery, this one was easy and painless
<flokli>
welcome back, and good it went well :-)
garbas has joined #nixos-dev
<jtojnar>
let's just merge the meson PR
<LnL>
gchristensen: welcome back to the land of the living :)
<gchristensen>
as mark twain says, reports of my death have been greatly exagerated. (however only one person, in jest, PM'd and asked if I was still alive)
<LnL>
btw, I was thinking yesterday, we could monitor (and kill?) processes that have been running for too long on the builders
<LnL>
because of the build users we can identify them, and something that's running for 6d isn't normal given the hydra timeouts
<gchristensen>
that sounds really good
<gchristensen>
ideally we could take a stack trace too?
drakonis has quit [Ping timeout: 240 seconds]
<LnL>
you don't want data like that in prometheus, but exposing it some other way might be possible
<gchristensen>
I agree
<gchristensen>
even just emitted to journald would be fine, just to capture some data
<gchristensen>
we don't want to stymie efforts to fix the bugs :)