<simpson>
gchristensen: I don't think Nix really has anything resembling a powerbox. In #erights we talked a little about Plash. It sounds very opt-in, so it's clearly a transitional technology.
lopsided98_ has joined #nixos-dev
lopsided98 has quit [Ping timeout: 260 seconds]
<gchristensen>
gotcha
<gchristensen>
I was thinking more generally about rights
<simpson>
Mm. Well, I'm sure that the Lobsters community would appreciate your input. I'm too toxic of a person to be given an invite, though.
<gchristensen>
oh I see
mbrgm has quit [Ping timeout: 260 seconds]
mbrgm has joined #nixos-dev
<thoughtpolice>
Sonarpulse: I think the native stdenv builder is completely broken. :| Do you have any idea about this?
<Sonarpulse>
thoughtpolice: yeah I'm not surprised
<Sonarpulse>
I wouldn't mind if it all went away
<Sonarpulse>
along with the "nix stdenv"
<Sonarpulse>
it's not that hard IMO to make pure stdenvs for open source platforms
<Sonarpulse>
especially once I repackage LLVM or GCC so the cross stuff can be used for regular bootstrapping effectively
<thoughtpolice>
So what's the recommended way for packaging bootstrap-tools for the first time? Cross compile the first variant of bootstrap-tools?
<Sonarpulse>
yeah
<Sonarpulse>
exactly
<Sonarpulse>
or if you have the platform
<Sonarpulse>
ideally things should be done so that you can just throw in some statically linked binaries and it is very forgiving
<thoughtpolice>
I do have the platform, I'm running on QEMU.
<Sonarpulse>
what platform?
<thoughtpolice>
That's why it's annoying, since Nix builds and works perfectly.
<thoughtpolice>
I suppose but I was looking to do a completely "fresh" build from a system emulator. But I only have the installer; although the cross tools aren't hard to build
<Sonarpulse>
the cross tools should be built
<Sonarpulse>
hmm riscv64 is failing
<Sonarpulse>
weird
<thoughtpolice>
Still though there's something deeply annoying about the fact that I can have a perfectly working Linux system, and working C++ compiler, for a language that does not-self bootstrap (Nix isn't written in Nix), yet I still have to start with a cross compile anyway. :|
<Sonarpulse>
thoughtpolice: yeah it's just hard to write a native boot strap because all the impuriies
<Sonarpulse>
I'd just copy binaries by hand to make a bootstrap tools
<Sonarpulse>
the cross binaries should work, and I sort of like cross being a supported default to avoid things like GHC 3 release policy being so important :D
<Sonarpulse>
sorry that's not much help; I got to go back to pairing with somebody
kmicklas has quit [Ping timeout: 265 seconds]
tomberek has joined #nixos-dev
lopsided98_ is now known as lopsided98
lopsided98 is now known as lopsided98_
lopsided98_ is now known as lopsided98
lopsided98 is now known as lopsided
ma27 has joined #nixos-dev
ma27 has quit [Ping timeout: 265 seconds]
tomberek has quit [Ping timeout: 260 seconds]
goibhniu has joined #nixos-dev
MichaelRaskin has quit [Quit: MichaelRaskin]
pie_ has joined #nixos-dev
s33se has quit [Ping timeout: 256 seconds]
zybell_ has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
zybell_ has joined #nixos-dev
ma27 has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
ma27 has quit [Ping timeout: 255 seconds]
ma27 has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
jtojnar has quit [Remote host closed the connection]
<thoughtpolice>
As an added bonus I added myself as the maintainer and have been touching up the manual. Presumably, this is because I love creating problems for myself.
<thoughtpolice>
Pending no feedback, I'll open a PR soon and assume everyone thinks its an incredible idea they wish they could take credit for, themselves.
<thoughtpolice>
(And yes as a bonus it should be 100% backwards compatible with existing instances, so no Hydras, etc should break. I suspect we'll want to maintain this at least until 18.09 is released, unless someone objects and thinks it's not worth it)
<thoughtpolice>
Not that I think it would break Hydra, anyway
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
<Profpatsch>
makeTest (if builtins.isFunction f then f (args // { inherit pkgs; inherit (pkgs) lib; }) else f)
<Profpatsch>
I always wonder why anyone would write stuff like this.
<Profpatsch>
Like, seriously. I know that it’s possible but it’s just not a good idea. :v
<zybell_>
Profpatch: That seems to me like an ordinary extension point. What do you mean?
<thoughtpolice>
It's unreadable as hell.
<thoughtpolice>
Aside from that, it's absolutely a pain to explain and keep track of "function-ish" things that are handled either as a fn or a value in that manner, there aren't good types annotations for it AFAIK (e.g. module options), and there is an easier-to-maintain way to do it unless backwards compat is really necessary.
orivej has joined #nixos-dev
<zybell_>
I did read it. Out of context too!
<zybell_>
You have an optional type? null or ...? Why not define Extensible? function or ...? Along the same lines.
<Cale>
Yeah, I hate type-cases like that *especially* as there's no static type system to help figure out what's going on. John Ericson and I were recently working on ocaml2nix, and there was a list of things which were either 1) string package names, or 2) attrsets whose keys were package names and whose values were either 2a) true, 2b) string version numbers 2c) constraints in the form of a string starting with a
<Cale>
relation like "< 2.0" or >= 0.7.2" or "==1.0+beta19"
<Cale>
That was a list called "packages", and there was also a list called "extraPackages" that it was being concatenated with at one point
<Cale>
However, extraPackages happened to be a list of functions, so that was a bug.
<Cale>
We need a type system ;___;
<zybell_>
ocaml-users always need a type system;-) But seriously auto-converting types has something on the UX-side. But it shouldn't be forgotten.
<zybell_>
Profpatch:I think too that conv is not automatic. But inserting a ifType whenever nix fails *in the plumbing* will make it seem very automatic at the surface, over time.
<Cale>
My #1 complaint about nix thus far is that you just end up reading all the code all the time because there's no way to know how to use anything otherwise. Maybe that's just the normal thing that most programmers do, and as a Haskell programmer I'm very spoiled. :)
<Profpatsch>
Cale: As a Haskell programmer I read more code than in other programming languages to be honest.
<Cale>
Well, but you can get away with just looking at types to figure out how things are meant to fit together.
<zybell_>
Cale:Only solution:Write documentation.
<Cale>
At least, that's what I'm used to doing.
<Profpatsch>
But not to find that weird corner cases, like I normally do, rather to see how it works. :)
<Cale>
I mean, it's one thing to *want* to read code and it's another to *have* to read it :)
<Profpatsch>
alp: I plan to integrate it into ofborg at some point.
<zybell_>
Profpatsch:I think too that conv is not automatic. But inserting a ifType whenever nix fails *in the plumbing* will make it seem very automatic at the surface, over time.
<zybell_>
Oops
<Cale>
I'd prefer just to have things fail with a comprehensible error when I use the wrong type of thing, rather than try to interpret my confusion in some other way.
<Cale>
Of course, the errors we typically get are not very comprehensible at the moment.
<Profpatsch>
alp: To add an automatic check for meta values (and if possible more).
<Profpatsch>
But it won’t go into nixpkgs soon I’m afraid.
<Cale>
Profpatsch: Also, hnix is coming along nicely. Ryan Trinkle and John Wiegley are down to only a few tests left to get working. :)
<alp>
Profpatsch, thanks! I'll keep an eye on it. nice work.
<zybell_>
The idea would be to make function a do one thing on type a, another related thing on type b, function b one thing on type a, related on type b, and function c which combines funtion a and function b calling them with the same arg can be made to do the right thing by choice of type. Think that nix must understand many conventions in sources, which possibly amount to types of sources.
<thoughtpolice>
Profpatsch: that looks great, I'm all for more validation. I got to see gchristensen's manual validation stuff in practice finally yesterday, too
<thoughtpolice>
:)
<gchristensen>
What was my manual validation?
<thoughtpolice>
Didn't you write all the patches to where the manual build didn't spit out a bunch of vomit if you made an error
<thoughtpolice>
like, forgetting </para>
<gchristensen>
Some of it, yeah, but I haven't really touched the NixOS manual
<thoughtpolice>
Rereading that sentence I can see how "manual validation" came off weird :P
<samueldr>
hi! I made two additional PRs for nixos-homepage fixing minor issues with CSS + the older PR fixing an issue with the options page + big PR
<samueldr>
I know only a handful of people check the nixos-homepage project, and fewer have the commit bits
<samueldr>
(this is pretty egotistical of me to announce it :/)
<gchristensen>
So egotistical to want your patches merged
<thoughtpolice>
Well, good thing you did... because it looks really good, imo.
<thoughtpolice>
I especially like how it actually lists the maintainers with their real names
<thoughtpolice>
As opposed to "Maintainers: [object Object]"
<zybell_>
is there some 'autoconv' going on?
<zybell_>
Note the quotes
<zybell_>
Should be read as quotes
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-dev
<simpson>
zybell_: The technology you anticipate is called 'multimethods' and they've been tried in many contexts before. I suspect that the right answer to the Nix typing question is 'no, Nix shall not have typed names' since an untyped calculus is better at the kind of fix-point silliness which we often get up to.
<simpson>
Also doing attrset typing requires fancy row-polymorphic setups or lots of head-bashing ala Elm.
jtojnar has joined #nixos-dev
<LnL>
Sonarpulse: I think I'm kind of confused by your comment
<Sonarpulse>
LnL: I have a little bit of time
<Sonarpulse>
let me try to explain
<LnL>
what I'm suggesting won't work without shlevy's pr
<Sonarpulse>
same
<Sonarpulse>
in mine `meta.platforms = ....;` is where it *ought* to work
<Sonarpulse>
`meta.knownGood` is where we know it works
<Sonarpulse>
`meta.knownBad` is where we know it doesn't (whether or not it should!)
<LnL>
sure, but that doesn't help with the current state of things
infinisil has quit [Ping timeout: 240 seconds]
MichaelRaskin has joined #nixos-dev
infinisil has joined #nixos-dev
zybell_ has quit [Ping timeout: 256 seconds]
mbrgm has quit [Ping timeout: 268 seconds]
zybell_ has joined #nixos-dev
mbrgm has joined #nixos-dev
<Sonarpulse>
LnL: well... I guess every time you hit a package and want to allowBroken to build it,
<Sonarpulse>
fix the meta.platforms and platforms.knownGood instead?
<Sonarpulse>
is that too much work>
<Sonarpulse>
is that too much work?
<LnL>
I agree, but the reason people use allowBroken now is because they don't contribute platforms changes
<LnL>
and currently they can't build nix :p
<Sonarpulse>
LnL: hmmm
<Sonarpulse>
good point
<Sonarpulse>
LnL: well landing shlevy's PR will help in the short term for that, right?
<Sonarpulse>
then my stuff, if we choose it, could continue with less urgency?
<LnL>
yes, if we also add broken = !stdenv.isLinux
<Sonarpulse>
LnL: hmm
<Sonarpulse>
now I'm confused :)
<Sonarpulse>
but it's ok
<LnL>
without broken = true; libseccomp is considered available when unsupported platforms are allowe
<LnL>
so it gets included in the nix build
<Sonarpulse>
LnL: ok
<LnL>
if it's both broken and unsupported it won't for allow unsupported
<Sonarpulse>
broken = !stdenv.isLinux
<Sonarpulse>
that *IS* correct under mine
<Sonarpulse>
I forgot about that
<Sonarpulse>
ok cool
<Sonarpulse>
we're good
<Sonarpulse>
before *either* allowUnsupportedSystem and allowBroken would work
<LnL>
yeah, so we'll have to tell people not to use allowBroken
<LnL>
but there's an alternative
<Sonarpulse>
ok
<Dezgeg>
does keeping the current behaviour really harm anyone?
<Dezgeg>
then you don't need the whole 'have to tell people not to use allowBroken' part
<Sonarpulse>
Dezgeg: it does with the new use of meta.available
<Sonarpulse>
it's the first complete way to handle optional deps
<LnL>
it's a breaking change but it makes sense IMHO
<Sonarpulse>
but it does clash with this latent stuff
<LnL>
broken and unsupported are different things
<Sonarpulse>
+1
<Dezgeg>
does this now mean if someone by accident adds a linux-only dependency to something without intending that, instead of darwin users getting an error they just have some feature silently disabled?
<LnL>
yes, if lib.meta.enableIfAvailable is used
<LnL>
kind of like the null weirdness we have now with some attributes
jtojnar has quit [Quit: jtojnar]
<zybell_>
Is there a way to make a shared library file that uses -f/-F options of ld but keeps the same hash independent which version it links to?
ma27 has quit [Ping timeout: 255 seconds]
<Sonarpulse>
Dezgeg: LnL: I would rephrase that "No, because lib.meta.enableIfAvailable must be used"
<LnL>
:)
<Dezgeg>
yes, but if you have buildInputs = [ ...] + enableIfAvailable foo
<Sonarpulse>
Dezgeg: dependencies are mandatory by default, perhaps moreso than the null stuff because if you null out in all-packages.nix downstream will still eval fine
<Dezgeg>
oops
<Dezgeg>
yes, but if you have buildInputs = [ ...] + enableIfAvailable foo + enableIfAvailable bar
<Sonarpulse>
that's explicitly two orthogonal optional deps
<Sonarpulse>
what would use expect?
<Sonarpulse>
or want?
<Dezgeg>
where it's done because let's say foo doesn't work on darwin and bar doesn't work on risc-v
<Sonarpulse>
ok
<Dezgeg>
now if someone adds a linux-only dep to bar, now it silently goes away on darwin as well and you don't notice it
<Sonarpulse>
Dezgeg: bar won't go away
<LnL>
no, it only looks at foo.meta.available
<LnL>
right?
<Sonarpulse>
the check-meta logic isn't transitive like that
<Dezgeg>
ok
<Sonarpulse>
Dezgeg: our first priority in designing it was no sneaky optional deps :) we'd only try to cut down on null-style boilerplate to the extent we could without sacrificing that
<Sonarpulse>
I agree sneaky optional stuff is a huge footgun, footbazooka even
<MichaelRaskin>
A huge rocketjump?
<zybell_>
Is optional always sneaky or are you only agains sneaky optional?
<zybell_>
*against
<Sonarpulse>
MichaelRaskin: that sounds almost like a good thing :D
<MichaelRaskin>
Depends on the damage rules!
<zybell_>
New try:Is optional always sneaky or are you only against optional that is sneaky too?
<MichaelRaskin>
Personally, I think optionals based on flags are not sneaky