-
-
Notifications
You must be signed in to change notification settings - Fork 611
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
Support options in requirements.txt in pip-sync #824
Conversation
8e7e9c4
to
8b55247
Compare
Codecov Report
@@ Coverage Diff @@
## master #824 +/- ##
==========================================
+ Coverage 99.26% 99.47% +0.21%
==========================================
Files 34 34
Lines 2446 2494 +48
Branches 306 312 +6
==========================================
+ Hits 2428 2481 +53
+ Misses 10 6 -4
+ Partials 8 7 -1
Continue to review full report at Codecov.
|
Thank you for taking care of this. 👍 We hit that problem in one of our projects. Can we help in any way to get this fix in with the next version? |
@jnns |
Hi, @jnns! Thanks for being interesting in this PR. I'll rebase this branch to the master then (for there was a lot of changes since this PR has been created), let's see whether the tests pass. |
a3c7c1f
to
890d1b5
Compare
FIY PR is ready to test and review. Take a look at it please if you have time. |
@atugushev Thank you! Your branch fixes the problem we have with |
@jnns great! Let's wait a review from contributors then. |
134664f
to
22d2c7c
Compare
["--only-binary", ":all:"], | ||
], | ||
) | ||
@mock.patch("piptools.sync.check_call") |
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.
FTR the preferred way of patching things in pytest
is to use a built-in fixture called monkeypatch
.
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.
Are there any links to the discussion about monkeypatch
vs mock
? I see only pytest-dev/pytest#4576 and a few others where arguments are mostly based on personal preferences. Personally, I do like @mock.patch
decorator.
Would you like to open an issue so that we can discuss it and decide whether it's worth to refactor codebase form mock to monkeypatch?
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.
I just think that it's cleaner because it's natively integrated + fewer deps.
Also, it automatically, unpatches things on exit.
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.
fewer deps
MagicMock would require pytest-mock
btw.
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.
I think it's vice versa
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.
Sure.. but that's not monkeypatch
.
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.
Wait, the patching method may still be monkeypatch
while the value would be MagicMock()
.
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.
I just think that it's cleaner because it's natively integrated + fewer deps.
You are right, it could be the mock.MagicMock
. Instead of using mock
and patch things with mock
, the suggestion is to use monkeypatch
with mock.MagicMock
. I don't get it, how it can be "fewer deps"?
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.
It's fewer deps under py3. Also, I'm not sure I'd actually endorse magic mock, better define a proper fake object which would fit expectations instead of implicitly hiding possibly malicious behaviors.
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.
I see. Pretend might be an alternative to the MagickMock
, btw.
Reduce the nesting. Co-Authored-By: Sviatoslav Sydorenko <wk@sydorenko.org.ua>
Rename _build_install_flags() to _compose_install_flags() and update the docstring. Co-Authored-By: Sviatoslav Sydorenko <wk@sydorenko.org.ua>
3d8db95
to
61a7ee5
Compare
@Nebukadneza I've rebased the PR against current master. Thanks for pinging! |
bump |
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.
I'd probably go for --binary
and --source
and drop the "only" or "no" prefixes.
How would that work given that pip uses the prefixes? I didn't think we were creating new options, just supporting existing pip ones. $ venv/bin/pip --version
pip 20.0.2 from /home/altendky/venv/lib/python3.8/site-packages/pip (python 3.8) $ venv/bin/pip install --help
<snip>
--no-binary <format_control>
Do not use binary packages. Can be supplied multiple times, and each time adds to the
existing value. Accepts either :all: to disable all binary packages, :none: to empty the
set, or one or more package names with commas between them (no colons). Note that some
packages are tricky to compile and may fail to install when this option is used on them.
--only-binary <format_control>
Do not use source packages. Can be supplied multiple times, and each time adds to the
existing value. Accepts either :all: to disable all source packages, :none: to empty the
set, or one or more package names with commas between them. Packages without binary
distributions will fail to install when this option is used on them.
--prefer-binary Prefer older binary packages over newer source packages.
<snip> |
|
bump |
Would be interested in getting this merged as well. Any help needed? |
Hello @JensPfeifle, This PR needs an approvement form one of the members. |
thanks all for your great work! |
@auvipy thanks for reviewing and merging. Looks like this PR should be rebased onto master before merging. Master's CI is broken now. |
@atugushev that could be solved by https://bors.tech/ |
GitHub can also just require that PRs be up to date. |
Sounds good to me! |
Addressed in #1085. |
I made a post-merge conflict fix in #1086. Please, review. |
Adds support of the following options in
requirements.txt
inpip-sync
:Closes #637
Closes #638
Inspired by #703 #464.
Changelog-friendly one-liner: Support
requirements.txt
options in pip-syncContributor checklist