https://pantsbuild.org/ logo
Join Slack
Powered by
Hi Team, Can we (or do we) have a check that ensu...
# general
b
Hi Team, Can we (or do we) have a check that ensures lockfile is regenerated when 
requirements.txt
is updated?
w
A good option is to run a ci job that git diff the outputs of running the lockfile generation
There's also support in the python backend to pretty print the diff after generation
b
Thank you. If I understand it correctly, we’d generate the lockfile in CI and compare it with what’s already present in the repo? And if there is a difference, fail the CI there?
w
Exactly
b
How about adding a step (as the very first) in CI to see if the branch being merged to 
main
has 
requirements.txt
, then it should also have the lockfile? That would be faster than generating the lockfile in CI I assume.
w
Indeed, that's a reasonable optimization
b
TYSM.
w
But take care if you use e.g github action "paths" or similar. Those checks are generally at the HEAD commit level, not branch. Meaning the check can be accidentally skipped if you, for example, interactively rebase.
👍 2
h
We really should behave like cargo and always regen the lockfile if needed
➕ 1
It is never a valid state to have a requirements.txt that doesn't align with its lockfile
e
yeah I would love to have a Pants goal that just checks if the lockfile is up-to-date. The above suggestion is a fine manual way to do it, but I imagine everyone has this problem.
➕ 1
b
^^ That's my thinking as well.
c
the validation should be easy enough, given that we track the input requirements in the lock so we can compare that against the requirements.txt file(s) going into the resolve..
b
My 2 cents. I would even propose going further and having a production-like lock that is frozen and pants fail if there are discrepancies between the lock and the requirements. Like 
yarn install --frozen-lockfile
b
Agreed @happy-kitchen-89482. I just want to ensure that there is a validation in place to avoid any human errors.
5 Views
Open in Slack
PreviousNext
Powered by