@dotlambda flake8 update is included here

@FRidh The flake8 bump required bumping pyflakes, pycodestyle, entrypoints and configparser as well. I added some changed other than just bumping these packages so I replaced your commits by mine.

I'm getting

$ nix-shell -I nixpkgs=. -p "python3.withPackages (ps: with ps; [ pykerberos ])" --run "python -c 'import kerberos'"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: /nix/store/77n1k65iv1ihk8j3jbz78rzl477p3qlr-python3-3.7.2-env/lib/python3.7/site-packages/kerberos.cpython-37m-x86_64-linux-gnu.so: undefined symbol: gss_nt_service_name

Any idea what's happening?
cc @catern

I believe that's caused by pykerberos having krb5 listed as a buildInput, when it should be a nativeBuildInput. I guess something was changed about buildInput handling in Python-land in this PR, since that worked before.

Fixed here: #56268

Is there any kind of policy on how to handle the fallout of breaking changes? I just spent quite some time bisecting the rpy2 failure to the strictDeps commit. I realize that it may not be realistic to expect the committer to fix all downstream issues, but I think doing nothing and hoping for maintainers / end-users to figure out the root cause of failures isn't optimal.

Maybe we could at least notify maintainers / post about changes with big breaking potential on nixos-weekly / post on discourse.

Uh, hmm, actually that pykerberos fix seems really weird. #56268 pykerberos links against krb5, so shouldn't krb5 be in buildInputs? But when krb5 is in buildInputs, the built binary doesn't properly link against krb5. But it does work if krb5 is in nativeBuildInputs. Huh?

Maybe the following would make more sense.

diff --git a/pkgs/development/python-modules/pykerberos/default.nix b/pkgs/development/python-modules/pykerberos/default.nix
index 994ba059f9e..ca1fda884d5 100644
--- a/pkgs/development/python-modules/pykerberos/default.nix
+++ b/pkgs/development/python-modules/pykerberos/default.nix
@@ -9,7 +9,9 @@ buildPythonPackage rec {
     sha256 = "0v47p840myqgc7hr4lir72xshcfpa0w8j9n077h3njpqyn6wlbag";
   };
 
-  nativeBuildInputs = [ krb5 ];
+  nativeBuildInputs = [ krb5 ]; # for krb5-config
+
+  buildInputs = [ krb5 ];
 
   # there are no tests
   doCheck = false;

I have no idea though why it works without buildInputs nor do I get what their code at https://github.com/02strich/pykerberos/blob/v1.2.1/setup.py#L38 is supposed to do. The except certainly doesn't trigger when krb5-config is not present. Maybe we should report that upstream.

EDIT: Removed a # that shouldn't have been there.

@dotlambda that's correct, it needs to be in both. strictDeps only handles the things on PATH, but it doesn't consider distinguishing whether the libraries need to be available for the host machine or not.

that's correct, it needs to be in both. strictDeps only handles the things on PATH, but it doesn't consider distinguishing whether the libraries need to be available for the host machine or not.

I know, but nix-shell -I nixpkgs=. -p "python3.withPackages (ps: with ps; [ pykerberos ])" --run "python -c 'import kerberos'" works without having it in buildInputs. That's what I don't get. Maybe the library is only used at a later point.

When not cross-compiling, there is no difference between buildInputs and nativeBuildInputs.

I pushed the fix in 82b3892.

The python: azure-mgmt-compute: 0.20.1 -> 4.4.0 bump also broke nixops.

backported the nixops fix (#56775) to 19.03 in 17a5b64.

The python: azure-mgmt-compute: 0.20.1 -> 4.4.0 bump also broke nixops.

azure-mgmt-compute doesn't build anymore at all, but there's a PR for that.

@FRidh? If you don't want to rebase #52550, you can always just pin the older version.