adisbladis has quit [Remote host closed the connection]
jD91mZM2 has quit [Quit: WeeChat 2.0]
adisbladis has joined #nixos-chat
adisbladis has quit [Client Quit]
adisbladis has joined #nixos-chat
drakonis_ has quit [Remote host closed the connection]
Lisanna has joined #nixos-chat
tertl3 has quit [Quit: Connection closed for inactivity]
Lisanna has quit [Remote host closed the connection]
Lisanna has joined #nixos-chat
<infinisil>
ldlework: neato!
<infinisil>
Oh my god, youtube is getting more shit everyday
<infinisil>
Mobile youtube now newly display 3 ads between the video frame and the rating buttons, so you have to scroll like two times to get to it, wtf!
<infinisil>
Also it now occasionally blocks the last 20 seconds of a video with unremovable "video suggestion" overlays, almost completely blocking the video itself. You wanted to watch the end of the video? Nope!
<infinisil>
Then there's the thing of the 10 minute mark at which video length producers get more money. So guess what every second video is now? 9 minutes of bullshit talk and 1 minute of content, to get dat sweet money
<ldlework>
awesome, make sure to tell adamantium when you see them in #nixos
<jD91mZM2>
Is anybody here somehow using ZFS (directly or indirectly) send/receive to backup their files to S3? If so, could you please link your scripts?
<jD91mZM2>
Lol everything looks better now, but I have no idea why. Maybe there was an update for my theme, but... it wasn't that long ago I updated, so... what
<sphalerite>
jD91mZM2: woooooo
<sphalerite>
jD91mZM2: I don't use it with s3, but I do use zfs send/receive for backups
<sphalerite>
I want to switch to sanoid/syncoid… one day…
<jD91mZM2>
sphalerite: Nice, thanks!
<jD91mZM2>
sphalerite: Does that mirror your entire FS to another drive? Because that's pretty cool!
<sphalerite>
no, just my $HOME
<sphalerite>
typically with zfs (and btrfs) you'll have a lot more filesystems (subvolumes) than with traditional filesystems, because it allows making more granular snapshots and not snapshotting data you don't actually need to snapshot
<jD91mZM2>
With "FS" I meant dataset, sorry
<sphalerite>
I don't actually snapshot anything outside of $HOME because all that's there is the nix store (which is easy to get back without a backup), /etc/nixos (which I have in git mirrored in various locations), and various not-particularly-important bits of state
<sphalerite>
jD91mZM2: no actually the answer is yet. dataset is a slightly more general term, and includes both filesystems and zvols
<sphalerite>
s/yet/yes/
<sphalerite>
filesystems are datasets, zvols are datasets, but not all datasets are filesystems :)
<jD91mZM2>
Would people usually have separate datasets for pictures/music/whatever in ZFS?
<jD91mZM2>
Or with "more than usual", do you just mean separating root and home?
srhb has joined #nixos-chat
<srhb>
Any polish speakers around who can help gracz in #nixos? There's a bit of a language barrier. :)
jD91mZM2 has quit [Quit: WeeChat 2.0]
jD91mZM2 has joined #nixos-chat
<sphalerite>
jD91mZM2: separating anything you want to snapshot separately.
<sphalerite>
jD91mZM2: of course, repeated snapshots of the same thing don't cost much storage. So snapshotting music and films and photos together with your code is fine
<sphalerite>
since they won't typically be changing much over time :)
Lisanna has quit [Remote host closed the connection]
<jD91mZM2>
sphalerite: Cool, thanks!
<sphalerite>
jD91mZM2: I have a separate dataset for my steam user's $HOME as well because I don't want that eating up my precious snapshot space
<sphalerite>
i.e. when I delete a game I want the space to be freed up right away. So I don't keep snapshots of steam
<jD91mZM2>
Do you enable compression for root?
<sphalerite>
yep
<jD91mZM2>
Btw I love how with Nix I was able to reinstall, reformat, and get up an almost identical system... in just 5 hours, probably less if I hadn't made a buncha mistakes everywhere
<jD91mZM2>
:pray: Imperative configuration :pray:
<jD91mZM2>
s/Imperative/Declarative
<srhb>
sphalerite: "steam users home" -- how do you deal with this? Log in on a different user when you want to use steam?
<sphalerite>
srhb: yep. I don't trust steam with access to all my stuff o.o
<srhb>
That's a good point...
<srhb>
Wonder how difficult it would be to set up the right X permissions to allow it to run sudo'ed in my regular session
<srhb>
Logging in and out is too meh
<sphalerite>
srhb: well that breaks the security completely :p
<sphalerite>
srhb: I don't log out, just create a new session
<srhb>
Why does it breaks the security completely?
<srhb>
s/breaks/break
<sphalerite>
srhb: if you're using lightdm or sddm (not sure about other DMs) nix-shell -p lightdm --run 'dm-tool switch-to-greeter' should let you open a concurrent user session
<srhb>
I had no idea, thanks. :)
<sphalerite>
because anything that can open X windows can log all your keys
<srhb>
Oooh
<sphalerite>
or inject events into other windows
<srhb>
Right right.
<srhb>
I'd probably be more scared of access to files in my homedir, but I see your point :)
jD91mZM2 has quit [Ping timeout: 272 seconds]
__monty__ has joined #nixos-chat
<sphalerite>
TIL: You can thoroughly hang up bash by doing `read -N 8 </dev/zero`
jD91mZM2 has joined #nixos-chat
<srhb>
I miss my emacs, but I can't deal with the relaunching times, and my workflow is usually to open and close lots of editors (vim) in a shell with the correct dev environment already set up. Is there any salvation for me? Can emacs inherit the environment despite being a single session for instant launch time purposes? Is there any sanity left in the world?
* srhb
cries
<sphalerite>
srhb: probably. Don't ask me how though :D
<srhb>
sphalerite: :'(
<__monty__>
srhb: Different e
<__monty__>
srhb: Different environment for every invocation?
<srhb>
__monty__: Yeah, that would match my workflow best. Alternatives that work are also very very welcome.
<srhb>
I just can't find a good workflow for it...
<__monty__>
I'm no emacs user. At first it sounded like you wanted emacs --daemon but I have no idea how that'd deal with changing environments or multiple environments.
<srhb>
If I could easily sort of "transform" the environment of any buffer on the fly (eg exiting, entering a nix shell) that would help too
<srhb>
__monty__: Yeah, exactly. :/ Thanks anyway
<__monty__>
I suspect it's completely doable. It might require a boatload of elisp though.
<srhb>
Indeed.
<srhb>
I'm not sure though. It's probably hard to have it respect every major mode.
<srhb>
nix-shell mode appears to have some of the bits.
<LnL>
why is this a problem, I only need to restart my editor if there's a major change like a new dependency
<srhb>
LnL: A lot of it is simply habit. I exit and enter my editor a lot, using my shell as the main development environment, really.
<__monty__>
LnL: That sounds more like working around the problem than "the right way to use an editor" though : p
<srhb>
It may be a weird method, but I've done this for so many years it's hard to give up.
<__monty__>
For what you describe I'd use C-z tbh.
<srhb>
That's just the same editor session again. I've now changed directory and set up a new environment and need my editor to respect that. Since vim launches instantly, it's fine to just relaunch it. :)
<srhb>
I know, I'm a monster. :-P
<LnL>
__monty__: not sure what you mean by that, but an "editor" is something you open/close frequently
<__monty__>
Why are you setting up new environments so often? I have one environment per project usually. Sometimes I add a couple deps but not often.
<srhb>
__monty__: The easy answer is that I often deal with many tens of projects at a time that interdepend, but I was to keep them separated in expressions that would actually mimic how they would be used with dependencies specified through nix rather than by having one big expression for them all that "pretends" to deal with the way it will eventually be distributed (as separate units)
<srhb>
s/was/want
<srhb>
And yes, it's painful.
<srhb>
Maybe commanding emacs to inherit the environment in a new buffer isn't nearly as bad as I assumed though...
jtojnar has quit [Ping timeout: 252 seconds]
<__monty__>
How about multiplexing your terminal so you have all of the environments open at the same time?
<srhb>
I uh, have an even weirder setup there... >_>
<srhb>
Like, I usually have one workspace with four terminals open, all multiplexing the same session of tmux, so I can have any of them display any of my open shells at any time. :-P
<srhb>
Maybe that actually would be nice, if I had a quick way to jump to a specific environment. That's probably a thing.
<__monty__>
If you replaced the terminals with window splits, maybe?
<__monty__>
Then you could have the different environments in different tmuxes.
<ldlework>
srhb: I never use emacsclient. My emacs init time is 3.2 seconds.
<ldlework>
Hardly a painful weight. Especially given all it does for me.
<infinisil>
ldlework: With server-client emacs the startup time for a new window is about 0.1 seconds!
<ldlework>
Sure, but then you have to use server-client emacs
<ldlework>
I like separate instances to keep activities disjoint.
<infinisil>
You have a point there
<ldlework>
If you used deferred package loading you can get it down.
<etu>
That wraps the loading of my config and cut away like 2s
<ldlework>
etu, i don't like using nix for emacs config
<ldlework>
but thanks for the snippet :D
<gchristensen>
this reviewer wants me to take `set -e` out of a script improvement PR I sent
<srhb>
Well, that doesn't sound smart. :P
<jD91mZM2>
/ set -e // DON'T UNCOMMENT!! The whole script breaks!!!
<jD91mZM2>
^ was a // before irc interpreted one / as a command
<srhb>
#continueatallcosts
<infinisil>
gchristensen: Well I've been told by #bash that set -e is the most primitive form of error handling and it should be preferred to handle errors more thoroughly
<gchristensen>
indeed!
<gchristensen>
you should
<jD91mZM2>
But then you forget to `if` one single command and when that fails instead of crashing it continues
<gchristensen>
if you use handle errors, and `set -e`, the `set -e` won't hurt you
<gchristensen>
few more gens and maybe I'll replace my Phenom II X6 1100T
<joepie91>
gchristensen: I run an AMD Spaceheater, the predecessor of the AMD Threadripper :P
<joepie91>
(also known as the FX-series)
<ldlework>
__monty__: I don't like specifying my packages twice
<gchristensen>
yeah... this thing warms up my basement real nice
<ldlework>
Nor coupling my emacs config build to rebuilding nixos or home-manager
<infinisil>
ldlework: I once had a setup where I could put a line `; foo bar baz` at the top of my elisp files to have Nix include packages foo bar and baz
<ldlework>
I just don't see any benefit.
<ldlework>
My emacs config is portable to anywhere.
<ldlework>
Including Windows.
<ldlework>
And it uses straight.el which is very much like Nix, but for Emacs.
<infinisil>
Heh, not sure why anybody should care for windows users
<__monty__>
I sympathize tbh. Have a hard time caring about OSX at this point.
<infinisil>
At least macOS is unix
<ldlework>
I would use Nix to deploy emacs for servers
<srhb>
ldlework: What do you mean "would" :P
<ldlework>
I just haven't added any emacs config to my servers
<ldlework>
srhb: did you see my desktop screenshot?
<srhb>
ldlework: Not really my taste, but I can see the appeal. :D
<srhb>
(Mine's as densely packed as possible)
<infinisil>
srhb: Yeah I also use very tight spaces on my small laptop, there's not much space
<srhb>
I could probably go for something more "open" if I had a real desktop :)
<infinisil>
If this nice kawase compton blur wouldn't be that laggy on my beefy machine (wut?) I'd be using it to be able to see the wallpaper, it looks really nice
<ldlework>
i am using qtile's scratch terminal to build my nixos and home-manager builds
<ldlework>
when i open the terminal with the binding, the build starts
<ldlework>
i can toggle it and look away and check back in as often as i like
<ldlework>
when it is done the output is in a less pager
<ldlework>
when i close the pager, the next time i open the scratch term, the build will start again
<ldlework>
and up at the top right i have a custom indicator which tells me if I'm recording, and if there's any nix fuckering going on
drakonis has joined #nixos-chat
<sphalerite>
infinisil: what resources would you recommend for getting started dabbling with idris? I know a bit of agda (so I have a rough idea of dependent types) but none of the standard library
<samueldr>
the contributions can be filtered by org
<samueldr>
and the year picker affects the contribution graph
<infinisil>
Neat!
<samueldr>
don't be fooled
<samueldr>
those ascii art bots are most probably tests to work around sigyin
<samueldr>
(or whichever is the proper spelling)
<samueldr>
and they did...
<samueldr>
gchristensen: :(
<gchristensen>
hrm?
<gchristensen>
ugh
<infinisil>
Tbh, there's a rather simple condition: If the message contains almost no alphas and is long enough, it's spam
<samueldr>
btw, I think I saw in the backlogs the other day questions about $a~ or whatever the exact pattern for extbans
<samueldr>
the effect would be that it whitelisted a specific pattern from the restrictions (matrix users)
<infinisil>
gchristensen: Don't you have a block bot? Could you add such a condition to it?
<ldlework>
infinisil: or at least ascii art
<samueldr>
infinisil: :) has no alphas!
<ldlework>
You could also give some of us ops
<gchristensen>
^.^
<infinisil>
samueldr: That's why it should be long enough :)
<__monty__>
Hmm, only submitted issues for 3 years, then a year of contribution, then a year of code review. I don't like where this is going, instead of complaining about features I have to implement and maintain them now -.- I was tricked!
<samueldr>
the system works
<joepie91>
lol
<joepie91>
was about to say that
<joepie91>
wontfix, works as designed, *closes*
<infinisil>
I have 60-90% commits through my 3 years
<infinisil>
Most of which are for my system configuration lol
<gchristensen>
a few weeks ago t shlevy's prodding I switched to Helm which I hated... my brother got me to switch to ivy / counsel today which seems nice.
<samueldr>
emacs using lawyer?
<ldlework>
i am so happy right now
<samueldr>
(insert a hyphen where appropriate)
<gchristensen>
samueldr: how did you know he's a lawyer?
<samueldr>
the multiple times you said so
<gchristensen>
oh. well, yes. I have multiple brothers.
<samueldr>
:)
<gchristensen>
and it is the emacs-using lawyer brother. uses yasnippets and latex for his court filings.
<samueldr>
neat!
<joepie91>
so, after having played with xod for a bit, my conclusion so far: promising concept, in many aspects I'm already finding myself annoyed at having to write text-based code... *however* xod itself is not yet very mature, it's still missing a lot of ergonomics features, the data model needs some changes, the vertical-flow layout was a mistake, and the lack of non-C++ custom data types is really a big hindrance
<joepie91>
(one of my main complaints about its data model is that while the split between values and pulses makes sense, the hard separation between them does not; it really should be possible to have a 'pulsed value' that triggers a reevaluation)
<joepie91>
(without needing to manually wire up pulses)
<joepie91>
hm, that was poorly worded. s/that triggers a reevaluation/that is required to get pulsed before a reevaluation is triggered/
Lisanna has joined #nixos-chat
Lisanna has quit [Quit: Lisanna]
<__monty__>
Wouldn't that be easily implemented in a library?
<joepie91>
__monty__: xod does not have sufficient extensibility features - at least in the graphical part - to implement the above, it would require changes to xod itself
<__monty__>
Ah. My gripe with graphical languages is usually there's no simple escape hatch. Like I'd love to be able to write a scratch block in smalltalk but there's no block with a textfield that does this.
<joepie91>
__monty__: that, xod *does* have; but given it's designed for microcontroller dev, the escape hatch is C++ :)
<joepie91>
you actually _need_ C++ code for custom datatypes right now
<joepie91>
which is... problematic
pxc has joined #nixos-chat
<samueldr>
build-vm is one of the best features when playing around with bootloaders
<samueldr>
well, build-vm-with-bootloader
<gchristensen>
+1
<samueldr>
I don't know how the rest of the world lives without nix, nixos or alternatives built upon its principles
<gchristensen>
+1
<drakonis>
worth mentioning that they don't know much about it
<drakonis>
your hype fu is too weak
<joepie91>
persuading people to care is difficult, especially when the differences are subtle enough that it's not immediately apparent how and why they matter
<drakonis>
then there's the sharp edges that have to be rebuffed
<pxc>
in my experience, certain kinds of people don't need much of a pitch at all. There are a few people at the place where I work who all started playing with it after hearing about it and they seem to have persistent interest in it
<pxc>
demos that set up tricky development environments seem to go pretty far, too, even when they're easy
<samueldr>
» hype: promote or publicize (a product or idea) intensively, often exaggerating its importance or benefits.
<joepie91>
drakonis: s/rebuffed/fixed/ :)
<drakonis>
sorry
<drakonis>
its
<drakonis>
buffed
<samueldr>
;)*
<drakonis>
rebuffed is rejecting something, my mistake.
<drakonis>
the nix experience is not yet as smooth as any of the other distributions
<joepie91>
I actually read it as 'rebutted' and then typed 'rebuffed' myself as well somehow
<joepie91>
bit of a brain disconnect there...
<drakonis>
me too
<joepie91>
anyway
<joepie91>
[21:44] <drakonis> the nix experience is not yet as smooth as any of the other distributions
<joepie91>
yes, very much this
<drakonis>
i'm running debian again and it feels very slick
<joepie91>
I think a large part of it is down to a lack of observability
<joepie91>
there are a *lot* of "why does it X" questions that do not have an obvious way to obtain an answer for
<joepie91>
Nix 2 improved this somewhat for at least rebuild progress
<drakonis>
then there's the nixos experience, crap its awkward
<joepie91>
but questions like "why is it recompiling X", "why is it breaking on Y", "what dependencies are installed from multiple channels", etc. are still unanswered
<joepie91>
also doesn't help that system management is forcibly terminal-driven and there's no integration between system config tools and what Nix manages
<drakonis>
feels like i'm swimming on tar to get things done
<joepie91>
which means that in many cases you can get either a fancy and usable config interface *or* reproducability
<joepie91>
and sometimes the fancy interface is there, but just... doesn't save
<samueldr>
drakonis: maybe do you have a write-up about the issues you're facing, as swimming on tar, (I'm not doubting!)
<drakonis>
god i'll write that down
<samueldr>
I did feel somehwat a disconnect at first when using NixOS, which is why I'm not doubting
<samueldr>
but having actual knowledge of pain points can be good for evaluating fixes to do
<drakonis>
i haven't actually written down my issues but i can recall the bigger pain points
<samueldr>
(my main savin grace was that I was learning **only** nix/nixpkgs/nixos at first, as I had all the required knowledge that made the linux-side completely transparent to me)
* samueldr
wonders when he'll write a fully thought-of sentence without a typo
<drakonis>
heh
<joepie91>
drakonis: anyway, I'd be interested in hearing your pain points as well :)
<simpson>
samueldr: Start small.
<samueldr>
simpson: about?
<gchristensen>
this little SDR I got reaches 130F :/
<simpson>
samueldr: Your desire to speak in complete, fully-thought-out sentences. Start small, and work your way up.
<drakonis>
i need advice on how to improve my conversational skills
<simpson>
drakonis: Check out the "FORD" method. It is a little boring and obvious, but you will be able to do small talk with just about anybody.
<gchristensen>
FORD is a good method to keep in your back pocket for a tough one
<drakonis>
okay so, first pain point, the things i can do are defined by the person that packaged it
<drakonis>
if i want to do something different, i need to jump through hoops
<joepie91>
drakonis: can you give an example?
<drakonis>
postgresql
<drakonis>
better yet
<drakonis>
the desktop environments are in a really awkward place
<drakonis>
gnome 3 is reasonably complete i suppose
<drakonis>
ah i'm getting carried away and not talking about the pain point
<drakonis>
what i want to say is that you got, say, a module and you can only work with what the module templates
<__monty__>
drakonis: ISWYM but doesn't every other distro have the same problem? It just doesn't show as often because they've had longer to mature.
<drakonis>
they don't have to contend with nix's way of handling packaging
<drakonis>
so for them, they just have to package it and see if it works
<drakonis>
they don't have weird behavior because packages have to be wrapped for dependencies
<drakonis>
wrapped for extra things
<drakonis>
you can just fix it yourself on other distros
<__monty__>
There's more patching than most distros but not so much that it's crazy.
<__monty__>
You can fix it yourself in an overlay : )
<drakonis>
sure, but you can't solve all your problems and then leave it in some personal overlay, can you?
<samueldr>
it's a first step into working on an appropriate fix
<samueldr>
though it all depends what the *actual* issue being fixed is and can only be judged on a case-by-case basis :/
<drakonis>
of course
<samueldr>
some things are expected to be kept in a personal overlay, maybe a public one, just as one could write a custom PKGBUILD or .deb instructions, or a script mutating the system in place when doing things differently than the distribution expects
<__monty__>
How is that any different from other distros though? Like, if a debian package is missing something I might build from source (which is somewhat easier on non-nixos I admit) now how does that help anyone else using the package?
<drakonis>
the other issue is that perhaps the immutability is what makes it into a tarpit
<samueldr>
in my case, the immutability was an issue at first "but I *just* need to modify that one file like I'm used to"
<samueldr>
(I say issue, but more like a stumbling step where I needed to learn new things to make the equivalent change)
<drakonis>
when you have to change a single file repeatedly and measure what's different, it does become a problem
<drakonis>
home manager does somewhat remedy that
<drakonis>
but its not yet in a state it can enable creating an user service for a server
<drakonis>
system rebuilding is a pain because the changes you need to happen on switch don't always take effect
<drakonis>
updating is also incredibly baffling and confusing
<drakonis>
my previous nixos install was stuck in a state from several months prior because nothing warned me there wasn't enough space on the efi partition
<drakonis>
nor it would switch to the fresher packages
<drakonis>
as for the lack of software inspired on nix, i raise you ostree and flatpak
<drakonis>
i also raise you endless OS
<drakonis>
i also raise you spack
<drakonis>
spack is strongly inspired by nix
<drakonis>
jesus i got derailed again, but another pain point is that tooling has to be consolidated
<drakonis>
lobsters' sysadmin gave nixos another shot, but he needed to use an ruby gem that wasn't available on nix, docs werent exactly in top shape nor was gem2nix because the developer stopped using ruby
<drakonis>
something he pointed out on his blog that would be interesting, having the ability to drop in configuration files somewhere in the system and then allow these files to be modified freely, outside of modules
<drakonis>
that would get rid of a large amount of issues that prevent getting into nix
<joepie91>
drakonis: can you give an example of that?
<joepie91>
like, a specific usecase
<joepie91>
(for the config files thing)
<drakonis>
escaping templated settings files
<drakonis>
hold on
<drakonis>
you know the abomination that is grub, right?
<joepie91>
to the degree that is necessary to not set my system on fire, yes :)
<samueldr>
simply dropping mutable files would make generations useless, as the now modified config may not match with what was there at the time
<joepie91>
samueldr: hold on, jumping the gun there :)
<samueldr>
oh, sorry!
<drakonis>
the grub configuration module operates with a perl file
<drakonis>
there are times that it would be useful to route around it
<samueldr>
drakonis: and it's progress when compared to the previous implementation (that I was reading today)
<joepie91>
drakonis: in the sense of replacing the generated config file entirely, or in the sense of adding custom rules?
<drakonis>
provide the ability to directly provide your own configuration files when creating generations
<joepie91>
(ie. replace vs. append)
<drakonis>
that depends
<drakonis>
there are situations that your configuration works fine with nix but not with the application itself
<LnL>
if you're talking about configFile options, I agree most modules should have that and not force you to reverse engineer the nix options
<drakonis>
yes please.
<joepie91>
yeah, this is what I was thinking; mutable config files is a bad idea because it breaks all guarantees of Nix... *however*, I see no reason why there cannot be a standardized "don't bother with config generation, use this file instead" override
<LnL>
that's completely different from mutable files
<drakonis>
yes.
<joepie91>
and the latter does indeed seem useful
<samueldr>
bootloaders though are probably an exception that needs to make the end-user work more
<joepie91>
drakonis: the good news is that this can be implemented entirely on a nixpkgs level, afaik
<samueldr>
and as far as the bootloaders are concerned, something on my todo list for 19.03 (shhh) is to look into unifying all of their generation code (let<'s hope it's possible)
<joepie91>
like, all the modules and config generation and the module system itself and such are implemented in nixpkgs, not Nix
<drakonis>
on the other hand that needs improved tooling and docs
<joepie91>
drakonis: it might be worth creating an issue thread for this on nixpkgs, if one does not already exists
<joepie91>
exist*
<drakonis>
of course
<joepie91>
make sure to link me when you've created or found it, I'd like to follow it :)
<joepie91>
also, I'm thinking that maybe we should be tracking these kind of usability issues as user stories rather than features
<joepie91>
the "I want to X" variant
<drakonis>
agreed
<drakonis>
it would avoid foot shooting
<joepie91>
I feel like a lot of subtle usability requirements slip under the radar because implementers think in terms of features rather than requirements
<joepie91>
(in Nix/nixpkgs)
<drakonis>
other things that would be worth looking into
<joepie91>
and it's not always clear what desire drives a particular request
<drakonis>
pushcx also wanted to use a newer ruby version
<drakonis>
but its not exactly clear how to use it
<drakonis>
i know that packages are built for multiple versions of the same package
<drakonis>
but there's no clear way to set which one is the default in a local scope
<joepie91>
drakonis: with python packages - I don't know if this is the same for Ruby stuff - the packages are exposed on different attrsets depending on Python version
<joepie91>
so... one sec
<drakonis>
instead the user has to dive into nixpkgs and do it themselves
<joepie91>
you have like, python2Packages.someLib and python3Packages.someLib and which of those you pick determines what version of Python is used for it
<drakonis>
oh i'm aware of that
<joepie91>
and that propagates through the dependency tree
<drakonis>
but the problem is that you can't actually define which thing is the default for your own use
<drakonis>
it defaults to what's in nixpkgs
<joepie91>
the default for what, though?
<drakonis>
multi versioned packages
<drakonis>
oh yeah this brings me back to the "debian alternatives" alike
<joepie91>
I'm... not quite following
<drakonis>
but this takes a hell lot of time to do and cooperation
<drakonis>
hmm
<drakonis>
say, you have python 2.7 and 3.6, how do you define which one is the default option?
<joepie91>
it's unclear to me what you're trying to specify a default version for - it's apparently not for "package that uses $runtime" because there you use the appropriate *packages prefix
<joepie91>
drakonis: this isn't answerable because I don't understand what the default you're thinking of is *for*
<joepie91>
like, what operation does it affect?
<drakonis>
erlang has four releases on nixpkgs R{18,19,20,21}
<drakonis>
it defaults to R19
<joepie91>
drakonis: are you talking about the `erlang` attribute in the package set?
<__monty__>
drakonis: With haskell you have haskellPackages. That's the nixpkgs default. If I want to change the default version, I just do that in an overlay by redefining haskellPackages.
<LnL>
why would you want to do that, there's no reason to rebuild graphviz if you want to use a newer ghc
<drakonis>
joepie91,
<drakonis>
yes
<drakonis>
LnL, erlang doesn't need to rebuild anything either
<drakonis>
but if i install an erlang package, it defaults to r19
<joepie91>
drakonis: so why not just specify the specific attribute for the specific version of Erlang that you want? the point of the alias is to stick with "whatever upstream considers stable at that point".
<drakonis>
if i manually install erlang r21 it will replace r19
<LnL>
it definitively does
<drakonis>
the current stable is r20 btw
<drakonis>
the point is that i want to be able to toggle the default for packages that don't need a rebuild
<LnL>
that doesn't exist
<drakonis>
hmm, not toggle, set it
<drakonis>
set the alias to the package, since they're all still built
<drakonis>
hmm, a question, there's no concept of runtime dependencies, right?
<joepie91>
drakonis: changing the alias would still cause a rebuild
<joepie91>
there's no semantic difference with using a version of the package that points at a different erlang package
<drakonis>
ah ok
<joepie91>
drakonis: keep in mind that packages in Nix are essentially 'content-addressable'; that is, their identity is determined by what they're made up of, rather than by their name
<joepie91>
so it doesn't matter *how* you specify a different version of Erlang as a dependency to something else, or what it propagated through; it's a different package definition, thus it'll result in a rebuild
<joepie91>
'names', or rather 'attributes', in nixpkgs are pretty much just pointers at package definitions, they're not a part of the packages themselves
<drakonis>
right so if i set the alias to r21 it will rebuild every beam package
<drakonis>
that depends on erlang the alias
<joepie91>
not sure what a 'beam package' is, but if those packages use the `erlang` alias in their dependencies, then yes
<drakonis>
erlang's beam vm
* joepie91
knows very little about erlang
<__monty__>
LnL: I override haskellPackages without any problems. I don't see why you *wouldn't*?
<drakonis>
beam is the runtime
<drakonis>
what would it entail to add an issue covering the ability to override files with user provided files?
<drakonis>
someone remind me what's up with the whole helm vs ivy thing?