Code change:
A clear and concise description of what the bug is. Steps to reproduce the behavior: -p nixops ... ... it builds! error: builder for '/nix/store/48sdc9gb26pb3prykylvy644mmsma0km-python2.7-ruamel-yaml-clib-' failed with exit code 1; <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Maintainer information:
Builds on linux thanks to .
still fails:
I think the issue is tracked in I do not understand what the state of nixops is. is an issue about NixOps 2.0 with all checkboxes ticked. Further down in the thread there is a link to a board called . So what's going on? Are the things in that board release blockers? Which version of nixops should normal users use today? The project does not seem to make it clear.
And even with that insecure package enabled, the fails with an import error.
NixOps 1 is effectively end-of-life. That issue does not include critical usability problems present in master. To quote my response to another issue: All maintenance to the NixOps core currently happens on NixOps 2 (master / pre-release), because of the project's limited resources. NixOps 1 relies on python 2.7, so maintaining it is not feasible with the NixOps project's limited resources. Please consider helping with maintenance and testing, or donate to This fund currently supports reviews and fixes on master. Donations greatly increase our ability to get things merged and work towards a functional NixOps 2 release.
Is there a current way to get oneself an overview of what's working in NixOps 2 master, and what isn't? Is it I would like to contribute testing it, but need to know: what the migration path from nixops 1 is (can I continue to use my existing state files?) whether there are dangerous unaddressed issues (will it wipe my infrastructure?) if there are key unsupported parts that nixops 1 has (Hetzner support, EC2 support, Route53 support)
Yes, this is more up to date than the previously linked issue. I'll have to refer to the issues and PRs. For the core, that's The documentation is still lacking in this regard, and some more work on the legacy state storage backend or other state storage code may need to be done, e.g. In my experience, NixOps 1 state files can be picked up by NixOps 2, but the opposite may not be true. Unlikely, but check the issues and prs of the plugins you're using. The plugins that are responsible for these parts should continue to support whatever those parts used to support, and they are available. IIRC we have two plugins for Hetzner now, one using a newer API. I have not worked on any hetzner related code.
don't you dare.
The build passes, if you permit that insecurity, now.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: # it should not override the version of pytest that is used for say # Python 2. This is an ugly hack that is needed now because the hook # propagates the package. <ins> pytestCheckHook_5 = if isPy3k then self.pytestCheckHook.override { pytest = self.pytest_5; } else self.pytestCheckHook; </ins> pytestCheckHook_6_1 = if isPy3k then self.pytestCheckHook.override { pytest = self.pytest_6_1; } else