-
-
Notifications
You must be signed in to change notification settings - Fork 278
Support development using makefile #777
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
Conversation
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.
@neiljp Functionally, this looks good! I tested linting, testing, and changes in dependencies and they seem to work well.
Left some minor comments.
README.md
Outdated
If using make with pip, you should also be able to use the following: | ||
* `make` - ensure the development environment is up to date with specified dependencies | ||
* `make lint` - equivalent to `tools/lint-all` | ||
* `make test` - equivalent to running `make lint` and pytest | ||
|
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.
We should add make pytest
here too. I run the linters only after all my tests pass which could take a few iterations.
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 wasn't sure how much to duplicate the table - some things don't run via make, and others are equivalent except for testing venv. Prefixing pytest
with make
each time felt like maybe too much. Happy to include it though.
'fix' should likely depend on venv
too.
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 am wary of make
with pytest
as well given that writing make pytest
takes more time and hinders tab completion.
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're meaning for pytest options?
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.
No, I meant in general. It is easier to do pyte + <TAB>
than write make pytest
.
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.
To clarify, we can still run make pytest
and it will work (because of the way its listed in makefile) . Are we considering here whether to only mention it README or not?
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.
@neiljp Thanks for automating the dev setup. It would greatly help new contributors to set up the dev environment easily. 👍
I tested the PR locally and it seems to work well. However, I have a few concerns that I have left in-line.
@@ -0,0 +1,34 @@ | |||
.PHONY: install-devel test lint pytest check-clean-tree fix force-fix venv | |||
|
|||
# Customize your venv name by running make as "ZT_VENV=my_venv_name make <command>" |
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.
We should mention that the ZT_VENV=...
would not only be required for the first time but every time it is run.
Additionally, perhaps rename <command>
to <zt-command>
?
Also, should we rather include this in the README so that it is easier to find?
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 had specifically left these notes in the makefile for now as they seemed more 'advanced', and may be scope for further extension - they work, but for now it's easier to just have one environment with a standard name.
I'm not sure we gain from zt-command
- what matters is running the different makefile 'targets', which are more just specific to those in the makefile.
@@ -283,15 +283,15 @@ def test_set_narrow_not_already_set(self, model, initial_narrow, narrow, | |||
} | |||
}, {0, 1}), | |||
([['stream', 'FOO'], | |||
['topic', 'BOO']], { | |||
['topic', 'BOO']], { |
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.
The fact that make fix
made formatting changes in files which were already passing the linting tests is concerning. Do we have a plan to enforce make fix
promptly?
Otherwise, it could potentially accumulate a bunch of unrelated changes in PRs which build on a master
commit that didn't run make fix
.
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 believe the difference is that autopep8 fixes many pep8 rules as specified, but also some additional ones as here: https://pypi.org/project/autopep8/#features
We could add this to CI without --in-place
and with --diff
, as a linter. Also autoflake. Ideally this would be part of flake8, so we wouldn't need another checker :/
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.
Ah, I see. :/ Nonetheless, we should perhaps enforce this with our CI for consistency.
# Short name for file dependency | ||
venv: $(ZT_VENV)/bin/activate | ||
|
||
# If setup.py is updated or activate script doesn't exist, update virtual env |
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.
We should perhaps include the fact that the makefile
will continue to make a new venv
even if a custom venv
exists (without the ZT_VENV=...
command).
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 mean if you don't use a custom environment name for all make
invocations, it will build the standard one?
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.
Yes, it seems to build the standard one without that.
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.
On second thought, since the custom one is a bit awkward to run and manage, perhaps we should only promote the standard one.
4d82097
to
0b2c405
Compare
Just pushed with the .gitignore. |
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.
@neiljp As mentioned previously I think this will be very useful to ppl who want to get a quick ZT dev environment setup. Manually the PR works fine and the code changes look good as well. 👍
(As I side note, the docker PR I had open would end up being much simpler now as well.)
|
||
# Customize your venv name by running make as "ZT_VENV=my_venv_name make <command>" | ||
|
||
BASEPYTHON?=python3 |
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 the only restriction this poses is being able to choose the exact python version during venv creation. This isn't a limitation on its own, but if we are going for an "advanced" setup option, we should consider this being customizable.
README.md
Outdated
If using make with pip, you should also be able to use the following: | ||
* `make` - ensure the development environment is up to date with specified dependencies | ||
* `make lint` - equivalent to `tools/lint-all` | ||
* `make test` - equivalent to running `make lint` and pytest | ||
|
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.
To clarify, we can still run make pytest
and it will work (because of the way its listed in makefile) . Are we considering here whether to only mention it README or not?
Also upgrade flake8 plugins & relax pinned versions.
0b2c405
to
52ad22d
Compare
Documentation on new development installation approach added to README. Default venv directory added to .gitignore.
52ad22d
to
90c3d3e
Compare
Note that the README is not updated to document `make fix` as yet, as this is considered an experimental development feature.
90c3d3e
to
68b6c4c
Compare
Following discussion on czo:
Also fixed .phony targets for 'fix', which are moved to the correct commit. Does this address the outstanding feedback? |
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.
@neiljp This looks good to me!
@neiljp Thanks for updating this. Looks good to me! |
Thanks for the reviews everyone! 🎉 |
This has been in the works since before 0.5.2, so here's a PR for wider review.
The main feature is how it makes setting up, maintaining and resetting a development venv even easier - simply run
make
and activate the venv. Ifsetup.py
changes, thenmake
sets up the environment accordingly on the next run. This latter approach is adapted from a number of examples I've seen. If an install fails or gets too big, then it can just be wiped and made afresh.I've also added and applied some explicit 'fixing' tools. We can iterate on these, or drop these in the first instance.
If we move to zulint in time, then we could still maintain this approach and swap-out linting/fixing commands.
I've updated some documentation, but there may be other parts I've missed.