Below is an email response from Justin Womersley from PyUP:
Thanks for your patience. I had a look into why PyUp is still opening PRs on that repo after you has set update to False.
It turns out our default for requirements files that you list explicitly under Requirements setting is to set update to All. This means that all the requirements files you have listed in your .pyup.yml file that do not have an update field are going to update.
I realize this isn't necessarily the naturally expected behavior and I'm going to speak to my team about this and whether it makes sense to change.
In the meantime, to stop updates on those requirements files you can add
update: False to each requirement file you've listed and that should stop the updates.
Let me know how that goes.
So basically, you need to set the update thing on each requirements file. That makes sense but since the project is still alive I think it makes sense to still receive security updates just to be absolutely sure we receive them. That way you get GitHub's vulnerability report and the PRs to go with them.
Below is an email response from Justin Womersley from PyUP:
Thanks for your patience. I had a look into why PyUp is still opening PRs on that repo after you has set update to
False
.It turns out our default for requirements files that you list explicitly under
Requirements
setting is to set update toAll
. This means that all the requirements files you have listed in your .pyup.yml file that do not have an update field are going to update.You can see how PyUp is interpreting your .pyup.yml settings file on your repo's settings page: https://pyup.io/account/repos/github/mozilla-services/buildhub/settings/
I realize this isn't necessarily the naturally expected behavior and I'm going to speak to my team about this and whether it makes sense to change.
In the meantime, to stop updates on those requirements files you can add
update: False
to each requirement file you've listed and that should stop the updates.Let me know how that goes.
So basically, you need to set the
update
thing on each requirements file. That makes sense but since the project is still alive I think it makes sense to still receive security updates just to be absolutely sure we receive them. That way you get GitHub's vulnerability report and the PRs to go with them.