potiuk commented on a change in pull request #8487:
URL: https://github.com/apache/airflow/pull/8487#discussion_r412256786
##########
File path: setup.py
##########
@@ -446,6 +446,9 @@ def write_version(filename: str = os.path.join(*[my_dir,
"airflow", "git_version
'pytest',
'pytest-cov',
'pytest-instafail',
+ 'pytest-rerunfailures',
Review comment:
> From a git history point-of-view I'd rather that adding the
requirement to setup.py and using it was in the same commit, otherwise
cherry-picking will be almost impossible to get right (you have to pick the
version update, and the change it needs).
True. That convinces me that we should go with (2). Since the requirement
files are just a hint, not the real requirements I don't think it's a bit deal.
The requirement files will be re-generated anyway regularly - with every
setup.py, so this is really a by-product. I would not worry too much about
having unrelated requirement changes when setup.py changes.
Yes. Agree (3) is ideal, but it's not easy.
When you first look at it - (3) is not as "bad" for developers as it sounds.
It does require a bit of discipline when adding new requirements to
setup,py. But It's perfectly workable even now and requires just few specific
steps to follow:
1) add/modify requirement in setup.py
2) Run ./breeze generate-requirements --python [3.6,3.7]
3) git add -p . adding all other changes but the newly added/changed
requirements
4) commit
5) add/commit the rest of your change
However you would have to do it just before merge, because then if it takes
few days your requirements will change again :( or you would have to do fixups
to the other commit and rebase two of them. Sounds messy.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
