@GrahamcOfBorg build python.pkgs.flake8 python3.pkgs.flake8

Looks like this should be cherry-picked to staging-next as well.

not into staging-next because it would cause too big of a rebuild for no real gain

@FRidh @Mic92 master is broken for me now because of this dependency

❯ flake8 --version
Traceback (most recent call last):
  File "/nix/store/0r3m3fshl6r2mj9k2g3n7wc7kh1lqh08-python3.7-flake8-3.8.3/bin/.flake8-wrapped", line 6, in <module>
    from flake8.main.cli import main
  File "/nix/store/0r3m3fshl6r2mj9k2g3n7wc7kh1lqh08-python3.7-flake8-3.8.3/lib/python3.7/site-packages/flake8/main/cli.py", line 5, in <module>
    from flake8.main import application
  File "/nix/store/0r3m3fshl6r2mj9k2g3n7wc7kh1lqh08-python3.7-flake8-3.8.3/lib/python3.7/site-packages/flake8/main/application.py", line 11, in <module>
    from flake8 import checker
  File "/nix/store/0r3m3fshl6r2mj9k2g3n7wc7kh1lqh08-python3.7-flake8-3.8.3/lib/python3.7/site-packages/flake8/checker.py", line 18, in <module>
    from flake8 import processor
  File "/nix/store/0r3m3fshl6r2mj9k2g3n7wc7kh1lqh08-python3.7-flake8-3.8.3/lib/python3.7/site-packages/flake8/processor.py", line 13, in <module>
    from flake8 import utils
  File "/nix/store/0r3m3fshl6r2mj9k2g3n7wc7kh1lqh08-python3.7-flake8-3.8.3/lib/python3.7/site-packages/flake8/utils.py", line 16, in <module>
    from flake8._compat import lru_cache
  File "/nix/store/0r3m3fshl6r2mj9k2g3n7wc7kh1lqh08-python3.7-flake8-3.8.3/lib/python3.7/site-packages/flake8/_compat.py", line 12, in <module>
    import importlib_metadata
ModuleNotFoundError: No module named 'importlib_metadata'

I cannot confirm this on d35735a:

$ nix-shell -p python3.pkgs.flake8 --run 'flake8 --version'
3.8.3 (mccabe: 0.6.1, pycodestyle: 2.6.0, pyflakes: 2.2.0) CPython 3.8.3 on Linux

It works on python3.8 because importlib_metadata is in stdlib, for python3.7 it's a separate library https://github.com/NixOS/nixpkgs/pull/90366/files#diff-9c09aa30a0ca61fd3e14aba395286af9R20

Just be patient, the change is in staging-next by now and will end up in master in a couple of days of nothing strange happens.

Just be patient, the change is in staging-next by now and will end up in master in a couple of days of nothing strange happens.

That's not the problem for me I switched to python3.8 version, I just thought that broken version slipped into master by mistake

not into staging-next because it would cause too big of a rebuild for no real gain

so am I right that we can ship a (partially) broken version to master from time to time if the fix requires big rebuilds or something else?

Sometimes bugs end up in master, and fixing it requires a long rebuild.

so am I right that we can ship a (partially) broken version to master from time to time if the fix requires big rebuilds or something else?

There's a reason why it's called unstable on the release channel. There's no gaurentee about breakages, both in APIs and builds.

Package updates to core libraries often break downstream packages. That's just how software works currently. And it's not realistic to expect volunteer maintainers to fix builds for ~70k builds across 2 architectures and 2 platforms.

Thanks for you replies, no complains here, just want to understands what policies are applied to different channels.