Python: add hook to check against dependencies in a requirements.txt file

[FRidh]

Python applications are often not distributed as installable packages
using setuptools/flit/..., but instead a requirements.txt file is
often given.

This commit adds a hook to check whether the listed deps are fullfilled.

To ignore a certain requirement, use substituteInPlace to
replace/remove it.

Motivation for this change

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

Notify maintainers

cc @

[FRidh]

Note I haven't actually tested this yet.

[FRidh]

Hardcoding the interpreter I don't like very much because it makes it harder when testing a Python env. In that case, one would have to set PYTHONPATH or NIX_PYTHONPATH to include that env.

The only alternative I see is using that env's Python to execute this, but we can't automate that, which means users would have to copy in the check-requirements.py script instead.

[teto]

Recently had to ask a developer to add a setup.py because of nix while he was
just using the requirements.txt so it's a welcome addition.

[jonringer]

not sure how i feel about this, I've seen a lot of cases where people just do pip freeze > requirements.txt as a way to ensure everyone has exactly the same packages.

As far as i understand, a requirements.txt is aimed more at being a system (many project) construct rather than a per-package construct

[FRidh]

Yes those cases are bad because they freeze at patch level. Typically we don't do anything with requirements.txt although sometimes setup.py loads them. There are however cases, such as web apps, where we so want to check that we have all dependencies. Of course, if everything is pinned at patch level that is bad, but those restrictions can be patched away still giving us a useful test.

…

On Thu, Oct 24, 2019, 18:43 Jon ***@***.***> wrote: not sure how i feel about this, I've seen a lot of cases where people just do pip freeze > requirements.txt as a way to ensure everyone has exactly the same packages. As far as i understand, a requirements.txt is aimed more at being a system (many project) construct rather than a per-package construct — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#71908?email_source=notifications&email_token=AAQHZ32ZA57VRUHIFSPS2W3QQHGEDA5CNFSM4JEUYQX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECFVYLY#issuecomment-546004015>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQHZ33VNV6MBB2LRVMJYLTQQHGEDANCNFSM4JEUYQXQ> .

[jonringer]

oh, if you strip the versioning info, then I would agree, at least you would have the full package set

[stale]

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.

[stale]

I marked this as stale due to inactivity. → More info