<drakonis>
its a bit impressive how clean triton is
<drakonis>
but it shouldnt come as a surprise
<qyliss>
yeah, one person working on it, much smaller in scope
<qyliss>
at some point I think we're going to need some CI for other operating systems, to stop them bitrotting again
<gchristensen>
Kinnison has noticed a *lot* of Hydra VM test builds failing like this: https://gist.github.com/grahamc/7e27183c1bb4418c0233dcbc17321668 has anyone seen this before or have ideas on what is going on? it does not appear to be limited to a specific, small, set of machines
<clever>
gchristensen: shouldnt that vm be booting with an initrd?
<jonringer>
Don't want to add too many criteria to selection, otherwise you get like 1 or 2 options
<gchristensen>
:)
<jonringer>
they already are: must start with the next letter, and not be widely associated with a technology of the same name
<jonringer>
For 20.09 (the letter O), we had like 1 option
<qyliss>
I think I've heard of some project with a penguin mascot already... not sure
<jonringer>
I would like to do an ubuntu style naming scheme of "<adjective> <animal>"
<jonringer>
E.g. Perplexing penguin
<jonringer>
have more fun with it. Probably be more rememberable as well
<drakonis>
memorable names is it?
<jonringer>
Like groovy gorilla. I don't remember release of ubuntu that was, but damn is that a good name
pmy has quit [Ping timeout: 240 seconds]
<drakonis>
that's fairly recent
<hyperfekt>
great point about the restrictions jon
pmy has joined #nixos-dev
<cole-h>
There's also "Polar bear" :P
<MichaelRaskin>
Perplexing penguin? As in. Linux and hard to understand?
<drakonis>
wordplay is fun.
<jonringer>
It was the first non-strictly negative P adjective I could think of: pessimistic, petty, plastic, etc
<jonringer>
Apparently my subconscious is very negative
<hexa->
pretty! :D
<sterni>
why is gccStdenv not a stdenv with gcc as cc in all cases?
<MichaelRaskin>
Persistent? Predictable?
<MichaelRaskin>
(also, I guess penguin should be out because it is litterally the official Linux kernel mascot?)
<samueldr>
pacific poodle
<samueldr>
not to be confused with the pacific puddle
<__monty__>
There's also "positive." I like the sound of Persistent Porpoise though.
<hyperfekt>
what if we got rid of every last bit of non-runtime bash in nixpkgs
<samueldr>
hyperfekt: build-time only?
<hyperfekt>
haha i'm trying not to be too divisive
<samueldr>
or "non-runtime" includes things like stage-1 init and other scripts running on the system, but actually "not interactive"
<samueldr>
not dismissing, I wanted to bounce back questions for you :)
pbb has quit [Read error: Connection reset by peer]
<gchristensen>
I think bash is a good fit for defining how to build software
<gchristensen>
generally
<gchristensen>
it is sticky and mushy enough to deal with the silly problems, and a lot of people know enough to be ~dangerous~productive
pbb has joined #nixos-dev
<gchristensen>
I think a lot of the bash we have could be not bash, though, for example a lot of stdenv could be ... not bash, and then be easier to grok -- but still mutate the enviroment and stuff in a way that doesn't change the interface
<qyliss>
hyperfekt: what would you replace it with?
<adisbladis>
Tbh I'd probably pick python
<gchristensen>
I've seen a python stdenv put to good use at least twice
<adisbladis>
It's not really the best at anything, but it has a reasonably widespread knowledge
<hyperfekt>
i don't really care, but something that throws errors when you evaluate nixpkgs rather than something that silently ruins your builds
<adisbladis>
And gradual static typing is pretty great
<qyliss>
I think defining how to build software in a language where shell commands aren't first class sounds like a nightmare
<adisbladis>
I wonder how good Xonsh would be at this..
<qyliss>
guix at least gets the advantage that the same language is used for build instructions and packaging information, but this wouldn't even get us that
<hyperfekt>
yeah switching to a different language in the same place isn't really much better
<adisbladis>
qyliss: Based on what I've seen in Guix I'm not sure that goal is something worth having..
<hyperfekt>
ideally what would happen is if build instructions were part of the same language used for package definitions
<qyliss>
hyperfekt: that's guix
<hyperfekt>
is it written in the same language or is it part of the same expression?
<samueldr>
"running list of commands" should be a first-class use case in whatever replaces
<hyperfekt>
big difference imho
<jonringer>
My main concern with python is early breakages of the stdlib. And an unbounded amount of features being added
<qyliss>
samueldr++
<{^_^}>
samueldr's karma got increased to 347
<samueldr>
and hopefully something that composes better than "soup of bytes"
<jonringer>
yearly*
<qyliss>
execline would be a reasonable alternative (although I still think it would be worse than shell for this use case), but not Python
<hyperfekt>
aiui guix has their scheme so the job of nix, and then has their scheme so the job of bash. what i'm imagining is getting rid of bash and lifting all their logic into the nix computation graph
<hyperfekt>
*do the job
<adisbladis>
jonringer: Wdym by "early breakages of the stdlib" ?
<samueldr>
qyliss: sadly I tried an execline builder thing recently, and it sucked
<jonringer>
I meant "yearly breakages"
<samueldr>
but composed nicely!
<samueldr>
well, nicelier
<qyliss>
yeah, execline isn't nice if you want lots of conditional behaviour or functions
<qyliss>
hence shell being a better fit
<hyperfekt>
i feel like everyone is taking my criticism here as a jumping off point for something incredibly incremental. even if we replaced bash with agda we could do much better
<samueldr>
I was thinking that if I were to continue with that experiment, execline could be the backing implementation of a "nix" frontend DSL
<adisbladis>
My prediction: We'll never get away from bash
<samueldr>
adisbladis: you're most likely right
<jonringer>
each minor version of python is now being released yearly, and there's usually deprecations and removals of items from the stdlib. So we would need to revisit almost all "scripts" in nixpkgs each time we bump the python interpreter
<hyperfekt>
let's say, for the sake of argument, every line of bash we have right now becomes a nix derivation
<adisbladis>
jonringer: I guess that could at least partially be helped by mypy
<jonringer>
It's still an unwelcome amount of additional maintenance debt which needs to be paid
<adisbladis>
It's a fair concern
<hyperfekt>
oh god i hope i didn't kick off the pythonization of stdenv haha
<jonringer>
then again, I'm probably just very salty from all the breakages I see in python packages.
<adisbladis>
hyperfekt: I've been wanting this for years already
* gchristensen
's actually a huge fan of (almost) all the bash we have
<jonringer>
don't get me wrong. If you're using python for smaller scripts, with little to no dependencies. It's great.
<qyliss>
me too
<hyperfekt>
qyliss: in reference to what?
<qyliss>
19:46 * gchristensen 's actually a huge fan of (almost) all the bash we have
<gchristensen>
it is really quite good at the task, and has almost none of the costs bash usually has (related to handling failure, temporary resources, repeated executions, etc)
<jonringer>
Once you get to a few dependencies, or the code base and complexity grows significnatly.... python starts to have exponential maintenance
<qyliss>
bash makes abstractions just painful enough to avoid overabstration
<jonringer>
qyliss++
<{^_^}>
qyliss's karma got increased to 147
<adisbladis>
I would be afraid of what crazy things people would start doing with a "real" programming language actually :P
<sterni>
execline would probably fail because we surely have stuff in nixpkgs that is larger than the argv limit
<qyliss>
sterni: just exec execlineb after a file
<MichaelRaskin>
Truth about bash: if you are not skilled enough debugging it, you will suffer when untangling the _upstream_ build system
<qyliss>
*while
<sterni>
qyliss: ah right you can do that
<MichaelRaskin>
Some of stdenv bash could be replaced with Nix computation… if they were mre efficient
<samueldr>
sterni: not sure what I should see
<sterni>
samueldr: something somewhat close to a nix DSL frontend with an execline backend
<sterni>
although no idea what precisely you had in mind
<samueldr>
right, I wasn't sure if there was a DSL in that
<samueldr>
might not be DSLey enough
<sterni>
it does nix list -> execline, but it is very one to one, so I wouldn't say very DSL-y
<samueldr>
what I vaguely had in mind is that execline is an implementation detail
<sterni>
just thought it might interest you
<hyperfekt>
another thought exercise: exec and fork are not available during a nix build. what would the solution look like
<samueldr>
hyperfekt: exec and fork are not available?
<gchristensen>
a nix dsl :| we already call a hundred thousand functions to evaluate `hello`, I think Nix would fall over if we made the entire set of individual build steps function calls too
<MichaelRaskin>
Give up and go to a system that works
<qyliss>
MichaelRaskin++
<{^_^}>
MichaelRaskin's karma got increased to 54
<MichaelRaskin>
Again, upstream build system
<qyliss>
if we couldn't fork or exec, we'd need to rewrite every compiler in nix
<samueldr>
gchristensen: in an ideal world where it's fine, when we're talking thought experiments
<samueldr>
limitations of the actual implementation shouldn't be what dictates an imagined workflow
<qyliss>
or in whatever language we're using for builds, I suppose
<samueldr>
or else we'd stick with "it's always been that way"
<hyperfekt>
gchristensen: what would it take to make this work? it's clear we'd have to throw away the nix interpreter and maybe even a large part of the semantics
<gchristensen>
:)
<hyperfekt>
but it's not unimaginable, is it?
<jonringer>
I think bash usage within nixpkgs is fitting. Generally you want to do some imperative commands, and for the most part, bash does this exceedingly well.
<jonringer>
However, the default builder is getting scary huge. And it's essentially the nix equivalent of "skeletons in the closet"
<hyperfekt>
yeah the bash we have seems to be a local maximum in a pretty large neighborhood as i see it
<MichaelRaskin>
Something shell-like has incredible ergonomics addictive factors
<MichaelRaskin>
(although even more for interactive use)
<MichaelRaskin>
I guess t
<MichaelRaskin>
to fix Nix evaluation we need to remake the approach to overrides in Nixpkgs
<MichaelRaskin>
(as in reevaluate when overrides needed instead of storing too much for the case that never happens)
<adisbladis>
As someone who very rarely writes bash it'd be nice to get rid of a lot of bashisms that I don't really understand on the first glance but have to refresh my memory of
<MichaelRaskin>
And then carefully pick which functions should be jit-ted so that they are cheaper to reevaluate than cache…
<adisbladis>
I think we have far more important issues to tackle than which choice of imperative language we choose though
<samueldr>
I think it'd be easy to do worse than bash, which is why replacing bash as the stdenv language is going to be tricky
<adisbladis>
So while I have opinions it's not really all that bad/important
<samueldr>
yes, that too
* gchristensen
mutters about second systems
<adisbladis>
gchristensen: That too
<MichaelRaskin>
I think moving logic from stdenv to Nix has benefits; replacing stdenv while keeping eval-time/build-time split would give little
<sterni>
hyperfekt: I think having huge bash scripts is fairly standard in package managers in general
<hyperfekt>
haha i don't think we're attracted to nix because of the ways in which it is standard
<MichaelRaskin>
We try to pick our deviations from upstream packages
<adisbladis>
It seems that there are a number of choices with questionable value but immense implementation cost
<MichaelRaskin>
Upstream packages use whatever, but with shell commands underneath
<sterni>
hyperfekt: one uphill battle at a time :)
<MichaelRaskin>
Unlike FHS, they are all actually consistent about that…
<MichaelRaskin>
Live with wolves, howl like a wolf… (Russian version of «In Rome do as Romans do»)
<drakonis>
ah skeletons in a closet...
pmy has quit [Read error: Connection reset by peer]
pmy has joined #nixos-dev
orivej has joined #nixos-dev
steveeJ has quit [Ping timeout: 258 seconds]
steveeJ has joined #nixos-dev
<ris>
(why) is ofborg presenting vm-test-run-nixpkgs-trivial-builders as a changed package for *everything* all of a sudden?
<jonringer>
not sure, but there's other nixos tests which it will include by default
<gchristensen>
where's this? link?
<ris>
nah i'm just finding `nixpkgs-review` is building that for bleedin everything today
<ris>
i mean, i guess it just _really_ wants to know it builds ok
<gchristensen>
it probably, as MichaelRaskin suggests, depends on the wholeof nixpkgs
* cole-h
puts on my ofborg hat
<cole-h>
ofborg is about to undergo a redeploy. After this is successful, everybody will have access to darwin builds running on their PRs -- "trusted" or not!
<cole-h>
(this could change at any time, but Graham and I think the risk is negligible considering how often that machine is reset to a fresh state)