samueldr changed the topic of #nixops to: NixOps related talk | logs: https://logs.nix.samueldr.com/nixops/
<aminechikhaoui> bhipple there is a branch pre-python3 in nixops that can be used
<bhipple> It looks like nixops has moved to python3, but nixops-aws has not; is there a way to build them together still?
<bhipple> I tried looking at the latter, but I hit https://github.com/NixOS/nixops/issues/1258, which appears to be an (unrelated?) issue with setuptools, has anyone else seen this?
<gchristensen> going back to non-master would be good, but otherwise moving nixops-aws to py3 :)
<{^_^}> nixops#1258 (by bhipple, 22 hours ago, open): Plugin instructions do not build
<gchristensen> ah
<bhipple> It looks like we're still using distutils, so I wonder if it's something in the buildPythonModule helpers changing in 20.03
<bhipple> should probably migrate to setuptools regardless
<gchristensen> I think adisbladis had an example way forward with poetry2nix which was really elegant, and I'd like to work in that direction if aminechikhaoui is amenable
<aminechikhaoui> I was just reading through the PR, I'm not sure I understand how plugin development is done that way
<aminechikhaoui> is it required to nix-shell into the plugin src checkout ?
<gchristensen> I ... will have to let adisbladis explain :P
<bhipple> I've had some pretty mixed experiences with the *2Nix toolchains, TBH. When they work they're beautiful, but when they breakdown it takes someone who is a real expert in the language's package management, nix's package management, and the specific repo/project's build conventions
<gchristensen> I agree
<bhipple> E.g., nixpkgs-update has some magic just-in-time cabal file generation where the cabal file comes out of nowhere from a nix codegen step
<gchristensen> I've found poetry2nix to be fairly consistently on the beautiful end of the spectrum :P
<bhipple> it took me forever to figure out how to compile it with cabal/stack, and in fact I was never able to figure it out myself and needed significant amounts of rynantm's time
<bhipple> now that I have it working it's humming along beautifully, and he and I buffed up the README.md a bit more, and we have better CI, so it shouldn't be a problem going forward
<bhipple> but point being that the *2nix toochains can dig you in a real deep hole real fast if you're not careful to document the build/test/iterating processes
<bhipple> All that said I'm happy with anything, as long as it works :)
<adisbladis> aminechikhaoui: Yes, exactly.
<aminechikhaoui> adisbladis hm, what I was thinking is ideally we can still do a nix-shell that provides multiple plugins
<aminechikhaoui> e.g before the plugins split when release testing a typical workflow is `./nix-shell; run tests; apply fixes; run tests; etc ..`
<aminechikhaoui> but not sure if it can be done easily, we've never really had that after the plugins split
<aminechikhaoui> btw regarding flakes it would be good to have Eelco's opinion :-)
pbb has joined #nixops
pbb has quit [Client Quit]
pbb has joined #nixops
abathur has quit [Ping timeout: 265 seconds]
bhipple has quit [Remote host closed the connection]
abathur has joined #nixops
abathur has quit [Ping timeout: 250 seconds]
abathur has joined #nixops
abathur has quit [Ping timeout: 246 seconds]
abathur has joined #nixops
abathur has quit [Ping timeout: 246 seconds]
<adisbladis> aminechikhaoui: That could certainly be achieved too
<adisbladis> But I think it's an anti-pattern that the main nixops repo is aware of any plugins
abathur has joined #nixops
abathur has quit [Ping timeout: 264 seconds]
<adisbladis> aminechikhaoui: If you'd like we could have a call & a tmate session and discuss any questions you may have like that. There is a lot of new stuff to learn so I think that would be more efficient :)
<gchristensen> ideally that tmate session and audio could be recorded, to then make docs? :)
<adisbladis> Very good idea
<adisbladis> Also I think anyone who is interested could join in.
<gchristensen> I'm sort of in Maximize Social Contact mode
<adisbladis> =)
<gchristensen> video calls at the drop of a hat, to keep people feeling connected to people the y know :)
lordcirth_ has joined #nixops
abathur has joined #nixops
abathur has quit [Ping timeout: 250 seconds]
abathur has joined #nixops
lordcirth__ has joined #nixops
lordcirth_ has quit [Ping timeout: 246 seconds]
<gchristensen> "hard to make it work with a specific pinned version of nixpkgs"
<adisbladis> gchristensen: ?
<gchristensen> "why don't you use nixops?" -> "I found it hard to make it work with a specific pinned version of nixpkgs"
<adisbladis> Ah :)
<adisbladis> The poetry2nix solution would mostly solve that
<gchristensen> eh?
<adisbladis> gchristensen: Because it does not rely on pythonPackages. Or did I misunderstand that ?
<adisbladis> Are you talking about nixops relying on NIX_PATH ?
<gchristensen> this is about pinning what version is deployed :)
<lordcirth__> It would be nice if you could specify NIX_PATH / -I in your nixops .nix files
<gchristensen> aminechikhaoui, adisbladis: I have a few pages of docs to write. how are we feeling on RST?
<gchristensen> should I suck it up and go docbook? :P
<adisbladis> gchristensen: Friends don't let friends do docbook
<samueldr> wordperfect
<adisbladis> I'm quite partial to rst (because of sphinx)
<adisbladis> samueldr: Ah! Galaxy brain right there.
<samueldr> (off-topic, but I thought about doing my last nixcon slides in powerpoint in windows 3.11 on dosbox for giggles)
<adisbladis> samueldr: Last time I actually used DOS for something real was only about ~10 years ago.
<adisbladis> I had a super nice DOS-based handheld device I used for notes
<samueldr> nice
<samueldr> I figure one of those with an almost full-size keyboard keycaps?
<adisbladis> Yeah
<adisbladis> Someone stole it :/
<samueldr> :(
<adisbladis> I loved that stupid thing
bhipple has joined #nixops
<aminechikhaoui> gchristensen is it nixops core, a plugin ?
<gchristensen> core
<aminechikhaoui> if it's nixops core then I think we'd better comply with whatever NixOS is on, at some point I think we need to revive the nixops manual in the website or is that not the target anymore ?
<aminechikhaoui> if the manual is just read from Github then rst/markdown is fine I think
<aminechikhaoui> but then you loose stuff like auto-generated nixops options documentation
<aminechikhaoui> which is docbook based as of now
<gchristensen> right
<gchristensen> aminechikhaoui: do you know why nixops uses /run/keys by default for keys? it does seem a bit annoying to take this approach
<lordcirth__> gchristensen, well, /run is in RAM
<gchristensen> I know, but is that significant?
<gchristensen> other than avoiding they hit disk. it seems the threat model which puts them in RAM is a bit outdated for most users, when you have to trust your hosting company extensively anyway
<aminechikhaoui> hm so how would encrypt an EBS volume for example ? other than not using software encryption
<gchristensen> I'm not sure I understand the question
<aminechikhaoui> right now if you have an ebs volume on AWS that you mount to /data for example, luks based encryption is done through a file in /run/keys/ that nixops is managing
<aminechikhaoui> unless you do AWS KMS or some cloud provider specific or maybe Vault approach you need to have the key somewhere right ?
<lordcirth__> gchristensen, not everyone using NixOps is using a cloud provider, for one thing...
<gchristensen> of course not, I'm thinking defaults
<gchristensen> and even still, having them erase on reboot is often not the choice people actually would like to make
<gchristensen> and again, my question was the history, not making an assertion that we should definitely change it