bhipple has quit [Remote host closed the connection]
evanjs has quit [Ping timeout: 240 seconds]
evanjs has joined #nixos-emacs
codygman has quit [Quit: Quit]
cole-h has quit [Ping timeout: 256 seconds]
leons has quit [Quit: killed]
rycee has quit [Quit: killed]
qy[m] has quit [Quit: killed]
fasd has quit [Quit: killed]
Guest23652 has quit [Quit: killed]
kyren has quit [Quit: killed]
alexarice[m] has quit [Quit: killed]
<ldlework>
doh I forgot to pin emacsGit again!
<etu>
:D
<etu>
Some day you'll remember it ;)
<ldlework>
accidental early adopter
<ldlework>
adisbladis: can we set this up for other packages too?
<adisbladis>
What exactly?
<ldlework>
adisbladis: Like, an easy way to create nightly/master overlays for other softwares.
<ldlework>
I guess flakes will make this easier?
<ldlework>
Maybe overthinking it
alexarice[m] has joined #nixos-emacs
<adisbladis>
Um, sure. The emacs overlay is not exactly rocket science stuff.
<etu>
ldlework: Should be fairly easy to do an overlay like this one
<etu>
tbh this was a quite hard one because of the amount of packages :D
<adisbladis>
Flakes is not required and completely orthogonal to this.
<adisbladis>
I actually don't even like flakes
<ldlework>
adisbladis: why shouldn't I like them either?
<ldlework>
Eh, that's a big question don't feel like you have to answer here and now :)
bqv[m] has joined #nixos-emacs
<bqv[m]>
adisbladis: its certainly better than all trying to ram prs into nixpkgs
<bqv[m]>
This way the nur is a first class citizen :)
<adisbladis>
Ugh... That is a big discussion :P
<adisbladis>
1. I _hate_ the global registry idea
<adisbladis>
2. It's really, really hard (read impossible) to write an architecture agnostic flake
<adisbladis>
3. I'm afraid it will be used as a mechanism (and/or a political tool) to move away from our monorepo approach
<qyliss>
adisbladis++
<nix-build>
adisbladis's karma got increased to 45
<adisbladis>
<3 qyliss
<nix-build>
qyliss's karma got increased to 46
<adisbladis>
I could go on but.. I't just feels like the wrong design to me.
<qyliss>
I'm not sure what to do about 3
<qyliss>
I can argue 1 and 2 at RFC meetings
<adisbladis>
3 is more of a "soft values" kind of thing
<bqv[m]>
I agree with 1 but 3 is actually one of my goals, see it as a problem
<adisbladis>
Monorepos is love, monorepos is life
<adisbladis>
Just imagine the horrors of debugging in the flakes world
<ldlework>
I just find that you basically can't sell Nix to anyone
<ldlework>
When I show them my configuration, even though it's very modularized an abstracted with helper functions
<ldlework>
they still recoil in horror
<qyliss>
The NUR being a first class citizen would just mean people start depending on code written in 20 different ways with limited or no code review
<qyliss>
the thousands of nix users have all been sold at one point.
<adisbladis>
I have sold plenty of companies on Nix
<ldlework>
i am just trying to relate my experience as an active and fervent evangelist
<etu>
qyliss: That's (probably) the reason why ArchLinux have been very hesitant to put the AUR helper packages as a mainline package.
<adisbladis>
You just need to learn to sell it to your specific audience ;)
<etu>
qyliss: To not make it too easy to destroy things that is.
<qyliss>
etu: exactly
<adisbladis>
IME it's rarely a good thing to start selling NixOS, start selling shell.nix and work your way up from there
<bqv[m]>
And yet the first thing anyone does on arch is install an aur helper
<ldlework>
I think I do a fine job at relating the merits, but people can't get over how much work it looks like
<qyliss>
I do see flakes as a potential opportunity to get all the proprietary and binary-only leaf packages occupying space in the PR list out of Nixpkgs
<ldlework>
And their right, getting my system to where it is was an absolute fuckton of work
<adisbladis>
qyliss: That would be fantastic
<bqv[m]>
To make that gap invisible
<ldlework>
I mean, I'll never have to do it again, which is part of the point. But it's just a hard-sell.
<qyliss>
But I don't think that using third-party Nix code in general is a good idea
<ldlework>
I didn't know leafs would replace Nixpkgs, I thought it was a standard abstraction you can use to configure your system.
<ldlework>
So you could teach someone how to use a leaf, and then they could more easily, say, use a different source revision for their favorite package or whatever
<ldlework>
not have to learn override attrs and friends and all their subtleties. But I guess I have to reread the RFC.
<bqv[m]>
I just see it as federating the responsibility of managing nixpkgs. You can still review entire repos the same way you review individual packages now, it'll be so much more efficient
<etu>
bqv[m]: But AUR is much scarier anyways. NUR and nix builds are at least sandboxed and can't ruin your system as bad :)
<qyliss>
bqv[m]: but then _everybody_ has to review that package, not just a couple of trusted Nixpkgs reviewers
<qyliss>
You can no longer delegate
<qyliss>
ldlework: a "leaf" in packaging terms is just a package without any dependents. I'm not sure what you think a leaf is.
<ldlework>
well i just described it
<bqv[m]>
Exactly etu, so I don't see the harm
<qyliss>
But, what is this concept you are describing?
<qyliss>
flakes?
<ldlework>
qyliss: don't worry about it i'm clearly mistaken
<etu>
adisbladis: I guess flakes could be quite nice for like companies that have their own package set... But it's already possible to do... I know.
<qyliss>
bqv[m] etu: the build is sandboxed, but since the whole point of the build is generally to install software to be run outside the sandbox, it's hardly a security consideration
<etu>
qyliss: I've seen wrappers for AUR that doesn't do a "sudo -k" before it runs the builds. So if you had a sudo cookie the build could use sudo without you knowing it.
<qyliss>
sure, but a Nix flake could install a program that sudo -ks before it runs
<ldlework>
i mean, can't the end software just do something nefarious anyway?
<qyliss>
that's exactly the point I am making
<ldlework>
nixpkgs maintainers are not security auditing the actual software in the packages are they?
<etu>
Sure, one can get software that bad things from any system. But in the nix case the buildphase shouldn't be able to break things while they can in the AUR case.
<ldlework>
so it seems the threat model here is nefarious things in the flakes themselves...?
<qyliss>
not in general, but with nixpkgs at least there will be action taken if one person notices
<etu>
that does bad*
<qyliss>
If a flake is installing malicious software, you will probably _never_ know about it.
<ldlework>
isn't everyone affected already then, and only redeemed if they update after
<qyliss>
How would you?
<qyliss>
Whereas if Nixpkgs is installing malicious software, it will at least be removed.
<ldlework>
qyliss: do flakes support being installed from git? wouldn't most flakes just come from the software owners themselves
<ldlework>
like a Dockerfile, etc?
<qyliss>
no, of course not
<qyliss>
Nix adoption isn't anywhere near high enough for that
<ldlework>
Yeah, but you could contribute one
<qyliss>
Unlikely it'd be merged in most cases, I'd say
<bqv[m]>
It boils down to "do you want to treat your users like theyre imbeciles". if thats your issue, of course you won't like flakes. But its no different to say installing a custom repo on debian
<ldlework>
Fork the project, add a flake, submit a pr, use your fork until it is accepted
<ldlework>
That would be my central workflow I think
<qyliss>
And then, do you really want responsibility for maintaining the flake resting with somebody who doesn't even use Nix?
<ldlework>
A lot of software I use works this way
<ldlework>
With build stuff in the repo from which the source comes from
<ldlework>
Is that unusual?
<qyliss>
yes, I think so
<ldlework>
Not in my experience I guess.
<bqv[m]>
ldlework: I love flakes for that reason, if I want to use something thats been stuck in pr for half a year, I now can without horrible hacks
<ldlework>
I feel like if there was just one abstraction I needed to teach people
<qyliss>
I come across the occasional repository that has a built-in Debian package, and a Dockerfile, and so on, but it's not the norm at all.
<ldlework>
In order to unlock their productivity for designing their own workstations
<ldlework>
I'd have a lot better chance at making more nix users
<qyliss>
bqv[m]: I think the problem is that pulling changes into your own Nixpkgs tree feels like a horrible hack
<qyliss>
I don't think it should
<qyliss>
It's a highly effective workflow.
<ldlework>
Right now I have to teach them the whole of Nix an a bunch of library stuff
<ldlework>
writeSubbedBin, and on an on
<qyliss>
I'm not even convinced more Nix users is a good thing
<ldlework>
People don't need the whole of Nix
<ldlework>
Most people
<ldlework>
They just want to describe their workstation environment
<ldlework>
Or server environment
<ldlework>
qyliss: My impulse is to share with others I'm friendly with the same advantages I've found for myself. It's a character flaw mostly I guess.
<ldlework>
XD
<qyliss>
Sure, share with others if they want them
<qyliss>
But that's different from trying to win them over
<ldlework>
Basically everyone who has a dotfiles repo, could benefit from advancing their reproducability to not just the configuration of the software they use, but the packages containing the software those configurations were written for
<qyliss>
I think this is how we end up with "NixOS hostages", which is a term I've heard used by a few people
<qyliss>
Company moves to Nix, they hate it and complain about it
<qyliss>
That's no good for anybody
<qyliss>
And it's not like switching to Nix is a painless process that's better in every way
<qyliss>
And it never can be
<ldlework>
I guess the thrust of my suggestion that we have a reduced API for the 80% of cases wont be heard :)
<adisbladis>
"I'm not even convinced more Nix users is a good thing" <3
<adisbladis>
We want more users, but they need to understand what they're getting into
<adisbladis>
At least that's my perspective
<qyliss>
I'm halfway through a Discourse post in response to the "marketing team" exactly to this effect.
<ldlework>
As user for over two years now, I wouldn't mind it being a bit easier each time I had to go and do something in my configuration
<ldlework>
It doesn't seem like a "know what you're getting yourself into" thing, for me.
<qyliss>
I'm very concerned by how many people seem to want to pursue growth above all else
<ldlework>
The learning curve is super high because you can't get anything really done until you've absorbed essentially the whole system at once.
<etu>
adisbladis: Like the discussion regarding graphical installers we had the other day
<etu>
It's probably a bad idea
<adisbladis>
Yeah, I'm 100% convinced it's not a good idea.
<etu>
It would be super cool to have. But it's probably a bad idea.
<ldlework>
sounds like FUD, tbh
kyren has joined #nixos-emacs
Guest7156 has joined #nixos-emacs
rycee has joined #nixos-emacs
fasd has joined #nixos-emacs
leons has joined #nixos-emacs
<etu>
adisbladis: I'm fine with doing cool live-images that are pre-configured for people to try out for certain purposes etc.
<ldlework>
the fact that I had to spend three weeks with infinsil working with him to build nice abstractions to make our own configurations more turn-key and trivial to add and customize new packages...
<etu>
But due to how the config system works and how "most people" reason about computers... A graphical installer would get people into a system they can't manage.
<ldlework>
for what? so we can be elitist? I don't understand what the advantage of not providing abstractions is. Is it the ad absurdum that all abstractions are bad because we ourselves have it fully figured out?
<qyliss>
ldlework: ...is a sign that pursuing growth now is likely to turn off people who try Nix now, have a bad experience, and then don't consider it again later when we've made those things better
<qyliss>
Who's arguing against abstractions here?
<ldlework>
If people who try nix have a bad experience
<qyliss>
I'm certainly not
<ldlework>
And your argument is that we shouldn't improve nix and make it more attractive
<qyliss>
I work full time on an abstraction over Nix, as a matter of fact.
<ldlework>
because that would be "pursing growth"
<ldlework>
then how does one reach a point where users don't have this reaction?
<ldlework>
you make it sound like people don't fundamentally understand the value propositions of Nix, try it, and despite it's ease of use, don't like it's fundamental value propositions
<qyliss>
ldlework: no, my argument is that flakes are bad, and that actively trying to sell people on Nix is likely to burn bridges as well as create them.
<ldlework>
I think that's totally wrong
<qyliss>
What?
<ldlework>
People understand the value propositions, try it, find it completely inhumane, and then don't like it
<qyliss>
No, my argument is the opposite
<qyliss>
It is too hard to use Nix
<ldlework>
Likely lamenting not being able to benefit from those value propositions
<qyliss>
After people try it, then what? You think they're going to come back once we've made it better?
<etu>
ldlework: I've watched two talks on guix at FOSDEM this year. Their tooling looks so nice! I'm a bit envious about it :(
<ldlework>
qyliss: people involved in computers have an intrinsic dependency on reproducability
<ldlework>
the more reproducability, the better, for nearly every usecase of computers
<qyliss>
I agree
<etu>
guix have done so many cool things
<qyliss>
Again, my life at the moment is dedicated to this principle
<adisbladis>
etu: I haven't tried it myself, but I think `guix import` is a _huge_ mistake.
<etu>
adisbladis: That one I don't know what it does upfront
<qyliss>
I'm also very envious of Guix in a lot of ways
<etu>
qyliss: You seem to do a lot of cool things as well though <3
<adisbladis>
Given just how hard it is to get certain ecosystems right and how few people actually understand them: See python
<adisbladis>
I can count on one hand the number of people who understand both Python packaging & systems package management
<qyliss>
Something that gives me hope for Guix's implementation is that they have demonstrated they will wait and do things the right way, rather than rushing
<qyliss>
e.g. they won't take packages they can't bootstrap
<ldlework>
Most users of Python don't need to deeply understand the package system
<ldlework>
Most times you get by by just listing the packages you need
<qyliss>
but the author of an abstraction absolutely does
<qyliss>
otherwise it won't work properly
<ldlework>
Yes but no one who just wants a reproducable workstation does
<adisbladis>
ldlework: That may be true for users
<ldlework>
They just wanna list the packages they use
<ldlework>
And the configuration for that software
<adisbladis>
But seriously, in the nix community we have maybe 3-5 ppl who can actually work on fundamentals in python packaging & understand the implications
<ldlework>
There should be some meager escape hatches for the 80% of non-default cases
<qyliss>
But you need somebody who understands how it all works to implement the system where they can list they packages they want.
<ldlework>
Literally no one anywhere said that people who write package managers shouldn't understand them
<qyliss>
Then you have to teach people the escape hatches, and it's even harder
<ldlework>
Then learning the whole of Nix?
<ldlework>
please, be real
<qyliss>
You have to explain "Yeah, sometimes you need to do things this other way, because we haven't implemented this properly"
<ldlework>
giving an abstraction with things like an easy way to override the source git hash or repo name
<qyliss>
I'm all for one of those
<adisbladis>
ldlework: I'm talking about fundamental infrastructure, not packaging single packages.
<ldlework>
is not some insurmountable escape hatch that undermines regularity and consistency
* etu
had a moment yesterday of why he uses nix whenever possible... with a debian system that couldn't install a package and complained about broken dependencies... This package was mariadb.
<ldlework>
no one here doesn't vouch for the value propositions
<qyliss>
In fact I'm involved in an effort to improve overrideAttrs to make it work more consistently and me more generally useful for that sort of thing.
<ldlework>
qyliss: after two years, it's not even that bad
<ldlework>
i just copy one of my other modules and change what i need
<qyliss>
It is if you want to use it with python/rust/go
<qyliss>
Because with those it's fundamentally broken
<ldlework>
but i had to break my neck for like three weeks to learn enough of nix and the module system and so on
<ldlework>
to build the abstractions I have
<qyliss>
With python you have to instead use overridePythonAttrs
<ldlework>
which let me do those things at such a high level
<ldlework>
qyliss: right
<qyliss>
And with Rust and Go there's no equivalent.
<ldlework>
for programming languages its much worse
<ldlework>
than stuff that will just make
<qyliss>
But we can fix that, by overriding overrideAttrs on the language-specific builders.
<ldlework>
i have trouble wrapping my head around using some of the foo2nix helpers
<ldlework>
things go wrong and i don't understand anything
<qyliss>
ldlework: but that's exactly why we're arguing for tools done right rather than escape hatches
<qyliss>
Probably, there's some escape hatch you can use to get things to work
<ldlework>
qyliss: i just thing there is an intrinsic conflation right now
<ldlework>
between the concerns of package managers
<ldlework>
and those of system users
<ldlework>
ever nix user is a package manager
<qyliss>
But if somebody who understood the system took the time to implement that sort of thing properly, it would just work and you wouldn't need to know.
<ldlework>
i don't want to be a package manager except for the cases where i am actually making a package
<qyliss>
a noble goal
<ldlework>
qyliss: well i am certainly not trying to dissuade anyone from that universe either :)
<qyliss>
but anyway, my point is that right now, all that stuff is such a bad experience, I think trying to evangelize Nix as it is today will do more harm than good.
<ldlework>
i evangelize nix to other developers obsessed with tooling
<ldlework>
early adopterers and hackers
<ldlework>
Nix deserves non-zero evangelism. Afterall, I learned about it somehow.
<qyliss>
That's a bit different to growth at all costs, though.
<qyliss>
You're selectively evangelising to people who will see the potential and put up with it
<ldlework>
qyliss: yes the ad absurdum presented when i described how i had hoped flakes were this easier abstraction
<qyliss>
And that's a good thing!
<qyliss>
I can assure you that it's not ad absurdum
<ldlework>
i certainly never presented a case for growth at all costs
<qyliss>
There are people arguing this right now on Discourse
<ldlework>
qyliss: it is when used as a reply to what I said here
<ldlework>
if it's a continued reaction from discussions elsewhere I understand
<qyliss>
That's just not true
<qyliss>
I introduced it as
<qyliss>
08:40 <qyliss> I'm very concerned by how many people seem to want to pursue growth above all else
<ldlework>
sure if you were not bringing that up so as to draw me as an example
<ldlework>
then no problem
<adisbladis>
<qyliss> but anyway, my point is that right now, all that stuff is such a bad experience, I think trying to evangelize Nix as it is today will do more harm than good.
<adisbladis>
This is why I brought up Python specifically
<adisbladis>
I have talked to sooo many python devs who discarded Nix because it sucks for them
<adisbladis>
They have to manually package up everything or use one of the very broken helpers
<ldlework>
I experience this myself
<ldlework>
I mostly just copy an existing project I got working and carefully replace whatever is needed and hope it works.
<ldlework>
When it doesn't, I'm prone to just do the whole thing in Docker
<qyliss>
Having docker/podman as an escape hatch is invaluable to NixOS being practical, IMO
<adisbladis>
Oh, speaking of which
<ldlework>
i couldn't agree more for now
<adisbladis>
qyliss: What do you think about deprecating Docker in favour of podman?
<qyliss>
I don't think we have to make a decision on that in Nixpkgs, do we?
<qyliss>
Do we privelege Docker over podman anywhere?
<qyliss>
podman is unquestionably better, but still doesn't have a good story for stuff like docker-compose AIUI
<adisbladis>
qyliss: I'm talking NixOS services, like declarative docker containers
<qyliss>
Those should probably be replaced with podman
<qyliss>
Although people might be surprised not to be able to talk to them over the docker daemon.