waleee-cl has quit [Quit: Connection closed for inactivity]
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 276 seconds]
drakonis has joined #nixos-chat
aszlig has quit [Quit: Kerneling down for reboot NOW.]
aszlig has joined #nixos-chat
drakonis has quit [Read error: Connection reset by peer]
endformationage has quit [Ping timeout: 240 seconds]
<eyJhb>
I cannot express, how much I hate the French Valve on my bike. I just got a flat, not because of any sharp objets, but because the tiny head thing broke off... Like, how often do you get a flat, while pumping your bike
<joepie91>
lol :(
Arahael has joined #nixos-chat
<Arahael>
I want to start a custom service (that uses docker) as a systemd user service, how do I get started?
<Arahael>
What documentation do I need to read to set that up?
<Arahael>
As a trivial example, I want to run syncthing automatically, that's not a docker service though, but the other services I want to run are docker based services.
<Arahael>
I suppose I can just do it the usual systemd way, and ignore anything special nixos might give me.
<emily>
look at the option documentation for systemd.services.* is one option
<emily>
I think there might be a section of the nixos manual about it too?
<emily>
oh, for users there's another copy of those same options under the user I think
<emily>
ah, no: `systemd.user.services` is what I have
<emily>
the docs aren't great, it's not your fault, the discoverability of the actually useful material is pretty low
<emily>
I suggest bookmarking the page or something
<Arahael>
Yeah, I think I'll do that, I guess I'm asking for questions that'd help me discover things myself.
<emily>
hanging out on IRC is a good first step I'd say
<Arahael>
For instance, that options page is actually only mentioned in section 17 of the manual for prometheus exporters.
<Arahael>
emily: I should totally hang out here more often. :)
<emily>
also, keeping a local checkout of nixpkgs and just grepping it if all else fails
<emily>
I prefer that to `nix search`ing for packages, personally...
<emily>
all the docs and everything are in the repo, so you should be able to find what you need in there if you look hard enough
<Arahael>
I should do that too - actually that's on my todo list, to figure out how to fork that.
<Arahael>
Though I could probably just fork it on github and then use that, but I wonder what the benefit is.
<Arahael>
Makes more sense, imho, to fork it "locally" - ie, just git clone it, and then use that tree directly - anyway, that's on the todo list.
<emily>
generally you want to use the nixos-channels repo
<emily>
so that you can sync it to the channel you are using
<Arahael>
Well, I want to modify the gramps .nix at some point to add some more python dependencies to it.
<Arahael>
(*not* today, though)
<emily>
you can clone the nixpkgs repo and add nixos-channels as a remote
<emily>
I generally base the branches I upstream to nixpkgs on one of the nixos channels so that I can test it locally with binaries.
<Arahael>
How do you 'test it locally with binaries' like that? Don't you need to add it to the nix channels thing?
<emily>
I have nixpkgs=/path/to/my/checkout in my NIX_PATH
<Arahael>
I must find out where my nixpkg's point to!
<Arahael>
Both are empty.
* emily
just doesn't use the normal channels machinery at all, I do it all through git. but that might not be to your tastes
<eyJhb>
Arahael: have you looked at the new services.docker-containers option?
<eyJhb>
Don't know if that applies to you, but that is a docker container managed with systemd, somewhat
<Arahael>
eyJhb: Well, thanks to emily, I think I know now that I could copy that into the website, and... No, there are no matching options found. :(
<Arahael>
emily: I use git every day. The normal channels machinery... Isn't something I fully understand.
<emily>
then you might find the nix-channels repo the most comfortable way to manage this stuff, I do
<emily>
I keep personal patches on a branch I base on top of channels/nixos-unstable
<Arahael>
emily: I'm just not sure how to do it, without unintentionally mucking this magic up.
<eyJhb>
Arahael: it is in unstable, so there is no documentation for it in option, if that is what you mean
<Arahael>
eyJhb: I do seem to have the unstable channel (in addition to the nixos-19.03 one, as root)
<Arahael>
eyJhb: The problem is one of discoverability.
<Arahael>
As a "new" nixos user (well, I've been using nix for a while now, but not actually _learning_ it)... I struggle with trying to figure out how the heck I should do stuff.
<eyJhb>
But currently bike fixing, so I might be slow to reply. Also #nixos would be more appropiate for this :p
<Arahael>
eyJhb: That just causes so many more questions! Lets start with the first one: "If you have the channel" - uh, why wouldn't I?
<Arahael>
And what's that <nixos-unsable/nixos/modules...> syntax? I've seen <nixpkgs> before, but never with a longer path in it.
<Arahael>
I'm still very slowly figuring out how to use it for my own software.
* Arahael
probably should do the pills.
<eyJhb>
Arahael: if you have the unstable channel added `sudo nix-channel --list`, which will show the channels you have, it should be something like `<local-name> <url>` e.g. `nixos-unstable https://nixos.org/channels/nixos-unstable`, if you do not have the unstable channel, you can add it with `sudo nix-channel --add https://nixos.org/channels/nixos-unstable nixos-unstable`, the syntax
<eyJhb>
<nixos-unstable/....`, refers to the local channels you have. So in the list you would have seen `nixos`, so anything that does `<nixos/....`, uses that channel, and the syntax I showed you would use the nixos-unstable channel (if you have called it by that local name)
<eyJhb>
Hope that somewhat makes sense
<Arahael>
eyJhb: I added the unstable channel a while back (so that I could get a newer gramps installed)
<Arahael>
eyJhb: So, the '<>' are kind of a quotation symbol that says: "This path belongs to a nix-channel that has previously been added"?
<eyJhb>
You could say it that way yes :)
<Arahael>
eyJhb: I'd rather know the correct way to think about it - my background is that I'm a developer.
<Arahael>
I do prefer to understand how things work from the fundamentals up.
<Arahael>
Rather than try to figure out / guess how the fundamentals work given the examples of using nix-env.
<Arahael>
Just been looking at that etu/nixconfig repo, it's a nice way of versioning the nix environment, looks nifty.
<Arahael>
I don't understand the need for the submodule, though. (the nixpkgs one)
<eyJhb>
Arahael: I don't know the 100% correct terms ;) There is also infinisil configuration, and gchristensen ! Generally, nice looking at other peoples configs for inspiration.
<eyJhb>
The submodule? docker-containers?
<eyJhb>
Because it isn't in stable
<eyJhb>
So unless you run nixos with the unstable channel on it, then it won't work :)
<emily>
Arahael: <foo/...> looks up foo in the Nix path / NIX_PATH
<emily>
Arahael: channels get automagically inserted into the Nix path
<emily>
looks like etu uses a git submodule to pin to a specific nixpkgs version like I do
<emily>
rather than using the channels machinery
<Arahael>
emily: I'm kind of curious now because I don't seem to even have a nix path.
<emily>
yeah, for you it is probably composed entirely of the channels
<Arahael>
emily: I'm actually running nixos, in this case, so should be a pretty standard setup...
<emily>
the standard setup has an empty NIX_PATH and uses channels for everything
<Arahael>
eyJhb: Somehow, I suspect that it's probably not going to be helpful to figure out hwo to get into this docker-containers thing. Ended up doing it by hand, manually (by writing the systemd service files directly in ~/.config/systemd/users/)
<Arahael>
Most of my nixos experiments at home have been trying, in vain, to figure out yet another way to build a haskell script I've written.
<Arahael>
Which had been a bit frustrating.
<Arahael>
(Mostly because it seems that every other month, the current LTS build in stack seems to be different - so the new stack project wont' build in nix, or as what happened previously, my existing stack projects wouldn't build after I upgraded nix, etc)
<Arahael>
(Still much better than the likes of homebrew - I'm only frustrated, not discouraged)
<qyliss>
I'm surprised to hear upgrading Nix broke your builds
<Arahael>
qyliss: It was because the ghc that the stack LTS channels used was removed or something.
<qyliss>
oh, you mean upgrading Nixpkgs?
<Arahael>
Yes.
<qyliss>
aha, that makes more sense
<Arahael>
Well, I was quite surprised, as I hadn't done a garbage collection or anything. Turns out that stack, when in "nix' mode, will directly refer to the current channel or something obscure.
<qyliss>
fwiw, I also use a local source repository for Nixpkgs rather than channels
<qyliss>
channels can be quite difficult to manage, because even if you version control your configuration you don't know what channel version it was built against
<Arahael>
qyliss: One wonders how you discovered that.
<Arahael>
I don't think this is mentioned in the manual - and even if it was, I wouldn't be at the level to understand the implications of that decision. :(
<Arahael>
Plus, I suspect stack uses channels, and therefore wouldn't be using a local source repository for nixpkgs.
<qyliss>
It's not an ideal solution. We're aware of the ergonomic issues with channels and there is a plan to replace them.
<Arahael>
I've probably gone into the deep end by trying to use nix from the get go within a language ecosystem - eg, python, haskell, stack, and all that - I get the impression that those are effectively custom built by the nix developers who use those languages.
<Arahael>
qyliss: The bigger problem is probably that I am wishing that there was more of a hand-held "guide" to doing various tasks with nixos.
<qyliss>
Yes, more of those are always good
<Arahael>
The manual doesn't tell you how to package up a relatively simple python package that uses a requirements.txt, as an example.
<qyliss>
As you might expect, we always need more documentation writers than we have
<qyliss>
But I recently helped publish an equivalent manual section for Ruby, for example
<Arahael>
Could you show me that?
<Arahael>
I do use ruby. :)
<Arahael>
qyliss: (Note: If I look at the nixos manual, and do a ctrl-f for 'ruby', nothing is shown)
<qyliss>
aha! I think I may have found your problem :)
<qyliss>
you should be looking in the nixpkgs manual for these things
<qyliss>
because it's not NixOS specific
<qyliss>
The NixOS manual tells you about NixOS modules and services and stuff
<qyliss>
Package stuff is all in the Nixpkgs manual
<qyliss>
Note, however, that the manuals are for 19.03, the latest stable version.
<qyliss>
So our new Ruby stuff won't appear there until 19.09 comes out
<qyliss>
There's no way that I know of to view the latest unstable version of the manual, short of building it yourself. This is another problem, because if you actually want to contribute to Nixpkgs that's what you need to read.
<qyliss>
Wow, you're right. We should definitely put it in the other resources section, at least.
<qyliss>
That would be an extremely easy change.
<Arahael>
Yeah, well, clearly first I need to familiarze myself with the nixpkg's manual. I'd been reading the nixos manual, finding it pretty... useless... And then thinking that I have to do things the hard way and try going through all the nix pills instead. (Which I'm still slowly doing )
<Arahael>
qyliss: Absolutely needs to be referenced in an obvious location - such as indeed, 'other resources'.
<Arahael>
qyliss: Id' rather you do it, for a few reasons: 1) It's starting to get late for me and 2) I don't know how to test that and display it locally to see how it looks.
<qyliss>
Okay, np :)
<qyliss>
Thanks for coming and talking to us on IRC. It's good to hear what people struggle with, and it's a good way for users to get help. I hope you stick around. :)
<Arahael>
qyliss: I might even suggest that maybe nixpkg's shoudl be it's own section, with a blurb: "This is the underlying stack, for information about... you'd be best to consult the nixpkg's manual, available HERE", or something like that.
<qyliss>
hmm. I think it definitely belongs in the same place as the Nix manual
<Arahael>
qyliss: I intend to stick around - been around for a couple of months, at least. But usually I'm frustrated with not being able to find resources when I chat in the channel - so I'm very grateful that you've finally identified the missing links here. :)
<qyliss>
And the wiki is so good as well it really makes sense to keep them all together I think
<Arahael>
Yeah, wiki isn't neccessarilyt hat useful for newbies, I suspect, though, because it has a different feel to them.
<Arahael>
When you're trying to figure something out, being very new to it, you want to be on well-trodden stuff.
<qyliss>
Yeah
<eyJhb>
Isn't the manual big enough as it is qyliss ? :p
<Arahael>
There is another gap as well - the nixos manual seems more interested in showing you how to use configuration.nix, etc. And a glance at nixpkg's manual seems to suggest that it's mainly interested in showing you how to write packages, and to be a reference...
<Arahael>
eyJhb: It's definitely not big enough.
<Arahael>
However, there's still a gap in showing you how to discover things, like, how to determine what the available settings are and to diagnose and resolve any problems.
<Arahael>
Eg, the original question today I had: How do i do add a systemd user service? ;)
<eyJhb>
Arahael: examples. Examples examples examples. I normally use the nixpkgs repo for that
<eyJhb>
Or look at other peoples configs
<eyJhb>
AND! Your question was more specific, to use docker+sytsemd
<Arahael>
The nixos manual, I suspect, would show me how to add a _specific_ systemd user service, but not show you how to add a custom one. emily's suggestion to use teh options search did help some of the discovery, but then I was left with like, "how do I actually add these options to the configuration.nix file? How do I do this as a *user*, anyway, configuration.nix is system-wide..."
<qyliss>
Arahael: have you seen home-manager? It's like a user-specific configuration.nix
<Arahael>
I probalby should've mentioned; "I have a specific docker-compose.yml file here, and I start it using 'docker-compose up' - how do I schedule that as a systemd user service?" :)
<eyJhb>
Would have made sense yes, but all the configs needed can be seen in systemd.services.<name>, but it is somewhat annoyign
<Arahael>
I've seen home-manager mentioned a few times, I probably really should use it.
<eyJhb>
But if you have made a service file already, it should be EASY to add to your configuration.nix
<Arahael>
eyJhb: I guess when I look at that file - eg, docker-containers.nix, I wonder how to add it to the configuration file. I mean, configuration.nix file feels to be literally just a dictionary, and I have very little idea as to what the keys should be.
<Arahael>
It's magic, how that configuration file gets consumed.
<emily>
the keys are as documented by options.html
<eyJhb>
That is where that comes in
<emily>
you can just do
<emily>
systemd.services. ... = ...;
<Arahael>
emily: At risk of being intentionally obtuse... Would you suggest I do: systemd.services.user.docker-containers = { ... the options I want from the docker-containers.nix file ... }
<Arahael>
emily: What I mean, is I don't know what the LHS should be, and how to specify which actual configuration I want in the RHS.
<Arahael>
I mean, I never actually see anything import that file explicitly.
<etu>
emily: [pinned nixpkgs] I do both, on my stable branch systems I use the channels and usually auto upgrades :)
<etu>
emily: But on systems where I want more control and being able to dig in to nixpkgs and test things with less work I use the pinned one :)
<qyliss>
Arahael: you can import other files, but when you're getting started it's usually easier to just have one big one
<Arahael>
qyliss: I am not really sure how to express myself at the moment, what I"m trying to say is - lets assume I indeed want to use that docker-containers.nix file you've shown me.
<qyliss>
You may already know this, but if not: systemd = { services = ...; }; is equivalent to systemd.services = ...;
<qyliss>
not sure if that helps
<qyliss>
OH, I see what you're asking
<Arahael>
qyliss: Yeah, that I've figured out. :) Anyway, lets assume I want that docker-containers.nix file - how do I specifically refer to the options on lines 168 to 190 in configuration.nix?
<qyliss>
Those are part of, essentially, a private function
<qyliss>
So you can't
<Arahael>
qyliss: So there's no point even looking at it, then, right? ;)
<qyliss>
The only way to interact with them is through the interface exposed by the docker-compose module
<qyliss>
Well, it might give you inspiration
<Arahael>
Oh? So I should look at the top of the docker-containers.nix file, which I'm going to guess is probably going to be a function that takes a set as an argument... And then look to see how those arguments map to lines 168 to 190... But then the problem is that nothing ever actually imports it in the first place.
<qyliss>
it's imported by nixos/modules/module-list.nix, but that's an implementation detail that shouldn't matter to you
<Arahael>
qyliss: But it does apparently matter, because I need to somehow figure out the interface? :)
<qyliss>
You _should_ be able to use options.html, but unfortunately you can't because this hasn't made it into stable yet
<qyliss>
(Our infrastructure is really geared to stable and it can be tricky to do things for unstable. This is another problem we need to fix.)
<Arahael>
Yeah, I"m not actually worried about that particular issue, that can be worked around - as a newbie, I probably really should properly understand /stable/ first.
<qyliss>
So, in your configuration you can set docker-containers.whatever.cmd, docker-containers.whatever.environment, etc
<qyliss>
Does that help?
<qyliss>
And then from that it will generate you a systemd service using the function you saw
<Arahael>
qyliss: Ah, so module-list.nix imports all the modiles... And evaluates them all, so that they all add their options to the global options list, which then lets me, the sysadmin in this case, provide new values for, and then the result is evaluated in some sort of transform that results in a new nix derivation?
<qyliss>
pretty much!
<Arahael>
qyliss: How does it manage to separate declaration of the inputs, and the transformation into the new (system wide) derivation?
<Arahael>
I mean, there surely has to be _some_ imperative stuff happening.
<qyliss>
the 'config = ' part is where it sets values of options
<qyliss>
the 'options.* = ' part is where options are declared
<qyliss>
In terms of generating a derivation, no imperative stuff happens (practically)
<Arahael>
Lets take this particular line as an example line 224: systemd.services = mapAttrs' (n: v: nameValuePair "docker-${n}" (mkService n v)) cfg;
<Arahael>
Somehow, that sets the systemd.services, and simultaniously, *reads* the attributes from the services?
<qyliss>
It's not reading the values from it
<qyliss>
At least I don't think so
<Arahael>
qyliss: cfg comes from config.docker.containers, which I presume is originally set in configuration.nix
<qyliss>
Oh, right
<qyliss>
But it's not reading from config.systemd.services
<qyliss>
If it did that, it would be infinitely recursive
<qyliss>
But the value config.docker.containers doesn't depend on config.systemd.services
<qyliss>
So it's fine for systemd.services to refer to it
<Arahael>
Well, it's lazy, so presumeably it only recurses as far as required.
<qyliss>
because it's one-way
<qyliss>
exactly
<Arahael>
Ok, so this config thing is basically a massive, massive nested dictionary that keeps on growing and expanding until it's finally evaluated.
<qyliss>
yeah
<qyliss>
technically, it's a set of nested dictionaries that can refer to each other and are merged together at the end
<qyliss>
that's why setting systemd.services in one module doesn't override the systemd.services set by another module
<qyliss>
they're all merged together
<Arahael>
I think I vaguely understand that now.
<qyliss>
It'll feel more natural the more you're exposed to it
<Arahael>
qyliss: You've certainly given a lot of enlightenment for tonight. :) I think I should take a break and let it absorb a bit. :) And perhaps take another look at the nix pills *and especially* a read of the nixpkg's manual.
<eyJhb>
You always forget about timezones when chatting..
<Arahael>
eyJhb: What timezone is it for you? :)
<Arahael>
(GMT+10 here)
<eyJhb>
GMT+2, so it is 2 PM here :p
<qyliss>
+1 here
<Arahael>
Heh, nice. :)
<eyJhb>
qyliss: what country?
<qyliss>
Scotland
<Arahael>
qyliss: The land of Robert the Bruce!
<eyJhb>
Ah! Nice :)
<emily>
Iceland doesn't do BST so I think UTC+1 is uniquely occupied by Great Britain + Ireland during summertime?
<emily>
er, *doesn't do DST
<Arahael>
emily: Also, thanks for your help earlier, too. :)
<Arahael>
Made me feel welcomed.
<eyJhb>
Ah... I was so confused, because I remember Denmark being UTC+1, but +2 because of summertime..
<eyJhb>
Someone throw that out the window, and soon
<emily>
Arahael: no problem! if there's one takeaway, it's pretty normal to be confused about nix{,os,pkgs} :p
<emily>
but you do start getting the hang of it once you've packaged a few things and started to understand the model
<qyliss>
Portugal is the same TZ as UK/IE I think
<emily>
and you get a ton of nice benefits in your build and development environments for free once you do
<Arahael>
emily: It doesn't help that I'm trying to apply what I learn to the macos version.
<emily>
ahh
<emily>
in that case, all of the NixOS modules are irrelevant to you
<emily>
I think home-manager supports macOS, and there's also nix-darwin
<eyJhb>
qyliss: It was weird when I flew to Cape Town, because it is in the same time zone as Denmark. Like flying for 11 hours straight, and still being in the same timezone. That is just.. Not what you expect
<Arahael>
Not really - my home computer uses nixos... And it's quite nice there. I don't have nix on my personal macos system - but I do at the work mac system.
<emily>
ah, I see
<Arahael>
(It's a bit awkward - mostly I'm keen to learn nix, but most of my learning scome from the nixos system and at work I occasionally try to figure out how to do the 'same thing'.
<emily>
you should be able to share your builds and development environments, just not your system services and configuration, basically
<Arahael>
And I don't have nix on my personal mac system because nix is HUGE, and I don't really have the space - brew is more efficient)
<Arahael>
Well, sadly, at work I usually use xcode, so that's a huge complication.
<emily>
Nix is a plot by SSD manufacturers: the next time you upgrade your system you will find yourself paying through the nose for a 2 TiB SSD so you can use Nix for all the things.
<Arahael>
So mostly I try to use nix for a few utility services, that just happen to be either python utilities, haskell utilities, or ruby gems.
<eyJhb>
Arahael: comparing the two doesn't make much sense
<Arahael>
eyJhb: I didn't really realise there was a comparison involved. Afterall, isn't it all 'nix'?
<eyJhb>
Between brew and nix :p
<Arahael>
Oh, ha! :)
<Arahael>
Actually no, it does make sense to compare brew and nix, but only superficially.
<Arahael>
You can install packages with either system - but nix takes a heck a lot more space to do so!
<qyliss>
having previously written a bunch of brew, I could compare them for hours
<eyJhb>
*and does a heck of a lot more
<eyJhb>
:p
<qyliss>
part of Homebrew's goals starting out were to not use much disk space, and rely on stuff already on the system
<qyliss>
Because MacPorts liked to build its own copies of everything, like Nix does
<Arahael>
And nix, on the mac, uses a crazy amount of space.
<emily>
unfortunately, as you probably already know, Apple,
<Arahael>
Apple isn't exactly cooperative, either, yeah. :(
<Arahael>
I tried to use xcode within a nix package. Basically gave up.
<qyliss>
They find some exciting new way to break Nix every release
<qyliss>
You might want to check out xcbuild for that, fwiw
<emily>
hard to not bundle stuff when the base system keeps losing things
<qyliss>
It's like, a reimplementation of the Xcode CLI, as I understand it
<Arahael>
qyliss: Back when I looked at it, it was broken. My work project is pretty new sometimes - heck, we're already using XCode 11.
<Arahael>
Also... When I say I use xcode... It's because I"m doing iOS stuff.
<eyJhb>
Anybody who knows word generators for phone numbers? Like, when you type in a phone number on a T9 keyboard, then instead of numbers you could easily translate it into a word instead, like what is somewhat common in US
<samueldr>
use a t9 keyboard and write down your phone number :)
<eyJhb>
That's waaay too easy samueldr ! :p
<eyJhb>
Actually my number has a "1" in it, which sucks :/
<MichaelRaskin>
Argh. What I want: given 50 to maybe 500 hundred headlines, sort them in an order that should typically bring headlines on the same topic together. No state and language independence would both be plusses. What I get if I try searching: given a 1000 to 10000 documents of at least one paragraph, assign topic labels to them, based on a model trained on a million documents or something.
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 276 seconds]
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-chat
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 245 seconds]
spacekookie_ has joined #nixos-chat
hyperfekt_ has joined #nixos-chat
hyperfekt has quit [Killed (cherryh.freenode.net (Nickname regained by services))]