-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
[RDY] Fix requirements file lookup #3800
[RDY] Fix requirements file lookup #3800
Conversation
Added some additional tests for Conda environment :) |
Before: Coverage for doc_builder/python_environments.py : 44% |
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 liked those tests!
I didn't get what's the change in the logic what fixes the lookup. I left a question for that.
Also, I'd like you to refactor a little bit the test cases before merging. I left some comments with suggestions on how to improve them.
Besides that, I think there are no major issues to change/modify.
break | ||
paths = [docs_dir, ''] | ||
req_files = ['pip_requirements.txt', 'requirements.txt'] | ||
for path, req_file in itertools.product(paths, req_files): |
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 don't see any logic change here, right?
We just had 2 nested for and now we use itertools.products
that produces the same result in the end. Am I right?
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.
>>> import itertools
>>> d = ['a', 'b']
>>> r = [1, 2]
>>> iter
iter( itertools
>>> list(itertools.product(d, r))
[('a', 1), ('a', 2), ('b', 1), ('b', 2)]
>>> for _d in d:
... for _r in r:
... print(_d, _r)
...
a 1
a 2
b 1
b 2
>>>
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 is the same result, but the break now exists the loop #2812 (comment)
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.
Oh boy! Great catch! :)
build_env=self.build_env_mock, | ||
) | ||
python_env.install_core_requirements() | ||
requirements = [ |
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.
Use the same list of reqs (common) for both project (created in setUp
) and append the ones that are specific for documentation type in each test.
This will be easier to follow and to change when we upgrade the reqs also.
'requirements_file' | ||
] | ||
|
||
paths[docs_requirements] = True |
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.
Can you add a simple comment in each of the cases saying what's the scenario and what we expect?
) | ||
|
||
def test_install_user_requirements(self): | ||
self.build_env_mock.project = self.project_sphinx |
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.
Can you add a docstring here explaining the test case in general?
paths[root_requirements] = False | ||
with fake_paths_lookup(paths): | ||
python_env.install_user_requirements() | ||
args[-1] = '-r{}'.format(docs_requirements) |
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 don't like this modification of the list, but I don't have a cleaner way of doing 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.
I didn't like it either, but it was the only way I thought to reuse the previous list p:
build_env=self.build_env_mock, | ||
) | ||
python_env.install_core_requirements() | ||
conda_requirements = [ |
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.
Same here, try to use a shared list.
'python', | ||
mock.ANY, # pip path | ||
'install', | ||
'-U', |
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.
You can also use a shared args_pip
for all these tests. You will need to change the -U
by --upgrade
but I think that's OK and it's better to use long attributes instead of short. So, 👍
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.
There is two types of the arg_pip, on conda the --use-wheel
isn't used. Is that on purpose? or perhaps we can unify both :)?
|
||
# No requirements file | ||
# no requirements should be installed | ||
self.build_env_mock.run.reset_mock() |
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.
With the last update of the mock lib, the assert_not_called()
was counting the previous calls too, so I have to reset it here.
@humitos I updated the tests, and now there is a shorter file, I think this can be even shorter if this is possible #3800 (comment) |
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 really like these changes!
From my point of view, this is ready to merge.
Fix #2812
I didn't find any place that match the tests, so I added a new class.