-
-
Notifications
You must be signed in to change notification settings - Fork 15.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python: add hook to check against dependencies in a requirements.txt file #71908
Conversation
…file 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note I haven't actually tested this yet.
echo "Error: no $requirementsCheckFile was given." | ||
exit 1 | ||
|
||
@pythonCheckInterpreter@ @requirementsCheckScript@ $requirementsCheckFile |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Recently had to ask a developer to add a setup.py because of nix while he was |
not sure how i feel about this, I've seen a lot of cases where people just do As far as i understand, a requirements.txt is aimed more at being a system (many project) construct rather than a per-package construct |
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>
.
|
oh, if you strip the versioning info, then I would agree, at least you would have the full package set |
Thank you for your contributions.
|
I marked this as stale due to inactivity. → More info |
Python applications are often not distributed as installable packages
using setuptools/flit/..., but instead a
requirements.txt
file isoften given.
This commit adds a hook to check whether the listed deps are fullfilled.
To ignore a certain requirement, use
substituteInPlace
toreplace/remove it.
Motivation for this change
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nix-review --run "nix-review wip"
./result/bin/
)nix path-info -S
before and after)Notify maintainers
cc @