python plugin: record manifest #1487
Conversation
come-maiz
force-pushed
the
python-manifest
branch
from
ea51a5a
to
c9e4e6e
Compare
| @mock.patch.object(python.PythonPlugin, 'run') | ||
| def test_pull_with_nothing(self, mock_run): | ||
| def test_pull_with_nothing(self, mock_run, mock_run_output): | ||
| mock_run_output.side_effect = fake_empty_pip_list |
There was a problem hiding this comment.
This can/should be done in the @mock.patch.object line - e.g. @mock.patch.object(python.PythonPlugin, 'run_output', side_effect=fake_empty_pip_list)
Makes a clearer distinction between your fixture and the actual test
There was a problem hiding this comment.
This looks like sane advice. I just reviewed another PR where I made a comment about it getting complicated on reviewing what we want to test versus the setup for that and the resulting verification. This is a big thing for tests that have complicated fixtures to setup.
There was a problem hiding this comment.
That's a good suggestion. Thanks!
|
It feels like storing the requirements file is almost informational now, isn't it? Given that we record the exact packages to install and can potentially use constraints to avoid some weird behaviour (unbeknownst to us) of pip picking packages outside of what was locked down. I guess the reason we store requirements files is in case it is something external to the sources of the project. I don't have any critique here, just thinking out loud as this has prevented me from reviewing properly since I first saw the PR Monday night. |
|
Since testing was brought up, now that we are using testtools, I much prefer self.assertThat(output, Equals(expected)instead of self.assertEqual(output, expected)since in the latter when writing (made easier with good variable naming) or executing it is never clear what is what you wanted versus what you got. |
Agreed, especially when you consider that, with testtools, it's |
come-maiz
force-pushed
the
python-manifest
branch
from
11a13ce
to
a94830c
Compare
|
Alright, thanks for the reviews! |
snapcraft/_baseplugin.py
Outdated
| @@ -131,6 +131,10 @@ def clean_build(self): | |||
| """Clean the artifacts that resulted from building this part.""" | |||
| pass | |||
|
|
|||
| def get_manifest(self): | |||
| """Return the information to record after the build of this part.""" | |||
There was a problem hiding this comment.
Does the return value here need to be a dict? Documenting expectations here would be nice.
There was a problem hiding this comment.
Yes, that would be very good.
We haven't finished discussing about docstrings. How do you imagine this? As prose, or just an rtype sphinx tag?
I added :rtype: dict, let me know what do you think.
There was a problem hiding this comment.
The prose you have in addition to rtype is excellent.
| installed_pipy_packages = self._run_pip(setup_file) | ||
| # We record the requirements and constraints files only if they are | ||
| # remote. If they are local, they are already tracked with the source. | ||
| if self.options.requirements and isurl(self.options.requirements): |
There was a problem hiding this comment.
this check need improvement as != url does not imply it is part of the source. You can do this in a follow up PR though.
|
Fixes #1454 |
No description provided.