samueldr changed the topic of #nixops to: NixOps related talk | logs: https://logs.nix.samueldr.com/nixops/
<disasm> I can do that aminechikhaoui!
<aminechikhaoui> disasm yaay
<aminechikhaoui> I just moved nixops-libvirtd and nixops-vbox to nix-community org https://github.com/nix-community?utf8=%E2%9C%93&q=nixops&type=&language=
<aminechikhaoui> we didn't setup the teams etc yet
<aminechikhaoui> will try to get the other repos moved in the next days
<disasm> nice! how are we going to define what goes in NixOS, nix-community, or supported by a 3rd party?
sphalerite has joined #nixops
<disasm> sphalerite: for the release, I'm thinking we should have nixopsLegacy and nixops in nixpkgs (with legacy pinning the current version until we drop it and nixops using the plugin architecture)
<aminechikhaoui> good question, but I don't have an answer yet. Common sense would be that there should be at least 2 maintainers that are willing to make sure the backend is maintained and working in each release.
<aminechikhaoui> Right now, what I'm trying to do is to make the previous backends that used to work at least accessible from nix-community.
<aminechikhaoui> we can come up with other requirements but it shouldn't be something hard, just making sure someone would be taking care of the backends in the future
<disasm> and if it's in nix-community, will we support it in all-plugins.txt?
<aminechikhaoui> disasm I don't think so, but it should be really easy to add it if we do something like vim-configurable right ?
<aminechikhaoui> we can package the nix-community plugins in nixpkgs I guess and it will be just a matter of referencing them
<aminechikhaoui> disasm let me know what you think, I don't have any strong preference, we can agree on whatever makes sense ;)
<disasm> would nix-community ones be included in nixpkgs?
<aminechikhaoui> we can do that yeah, but not make them available by default unless it's part of NixOS, what do you think ?
<disasm> so, AWS and hetzner == default, everything else they have to set
<aminechikhaoui> at least for now, I think we can definitely get libvirtd/vbox for example back to NixOS in the future
<disasm> hmm, I'm thinking all-plugins.txt gets everything in from nix-community/NixOS and if someone just asks for nixops without any plugins set, it defaults to just using [ p.aws p.hetzner ]
<disasm> that way people don't have to import the source and use p.callPackage manually to get community plugins
<disasm> johnny101: thoughts?
<disasm> we'd like to move packet to nix-community as well at some point
<aminechikhaoui> disasm yeah I think that should be fine.
<aminechikhaoui> though what I meant is you should be able to do nixops_configurable.customize { name =blabla; plugins = with nixpkgsPlugins; [ libvirtd vbox packet]; }
<aminechikhaoui> assuming nix-community plugins are packaged in nixpkgs
<aminechikhaoui> maybe the real question is, if we do a breaking change in nixops core, should we only make sure the NixOS org plugins work or both NixOS and nix-community
<aminechikhaoui> if it's both then probably there is no reason to have plugins in both orgs
<aminechikhaoui> but I was thinking the opposite, only NixOS org plugins are expected to be stable
<aminechikhaoui> * with nixpkgsPlugins -> with nixopsPlugins
<disasm> that makes sense, only NixOS ones guarantee stability
<disasm> I'll have to look into how we wrap this up into a configurable
johnny101m has joined #nixops
<johnny101m> disasm: what you guys are proposing sounds good to me. I don't have strong opinions formed yet one way or another.