-
-
Notifications
You must be signed in to change notification settings - Fork 42
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
Better error message when cherry-picker repo state is invalid #147
base: main
Are you sure you want to change the base?
Better error message when cherry-picker repo state is invalid #147
Conversation
938ee33
to
7032c27
Compare
Signed :) |
Ah .. I noticed I am not the first one #119 -> so I will let maintainers to decide if that is worth fixing (well there are already two of us thinking there is (@serhiy-storchaka ) and choose the righ fix. |
7032c27
to
e9b83a5
Compare
And there is also PR #112. |
When proposing python#147 I noticed that mypy failed with missing `types-request` - and while the mypy configuration had the `--install-types`, it did not work automatically for requests. The error was: ``` cherry_picker/cherry_picker.py:15: error: Library stubs not installed for "requests" [import-untyped] import requests ^ cherry_picker/cherry_picker.py:15: note: Hint: "python3 -m pip install types-requests" cherry_picker/cherry_picker.py:15: note: (or run "mypy --install-types" to install all missing stub packages) cherry_picker/cherry_picker.py:15: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports ``` I looked a bit closer and noticed the advice from https://github.com/pre-commit/mirrors-mypy > Note that using the --install-types is problematic. Mutating the pre-commit environment at runtime breaks cache and will break parallel builds. This PR fixes the problem by removing `--install-types` and installing types-requests explicitly as additional-dependencies. starting
When somoene uses `uv` to manage their venv, uv.lock is generated automatically when `uv sync` is run. This PR removes it, so that it is not committed accidentally (happened in python#147)
When I played with cherry-picker as we introduced it in Airflow, I manage to set the repo to the state where I always got the message "You're not inside a airflow repo right now!" After short debugging it turned out that it is because I manage to Ctrl-C and mix `git cherry-pick --abort` with `cherry_picker` commands - when I learned how to use it, I did not know that I had to only use `cherry-picker --continue` command rather than git commands. This might happen to others, so I think we should have a better way to handle this case. When this happens you get this exception: ``` Traceback (most recent call last): File "/Users/jarek/IdeaProjects/cherry-picker/cherry_picker/cherry_picker.py", line 666, in check_repo self.get_state_and_verify() File "/Users/jarek/IdeaProjects/cherry-picker/cherry_picker/cherry_picker.py", line 684, in get_state_and_verify raise ValueError( ValueError: Run state cherry-picker.state=BACKPORT_LOOP_START in Git config is not known. Perhaps it has been set by a newer version of cherry-picker. Try upgrading. Valid states are: BACKPORT_PAUSED, UNSET. If this looks suspicious, raise an issue at https://github.com/python/cherry-picker/issues/new. As the last resort you can reset the runtime state stored in Git config using the following command: `git config --local --remove-section cherry-picker` During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/Users/jarek/.local/bin/cherry_picker", line 8, in <module> sys.exit(cherry_pick_cli()) ^^^^^^^^^^^^^^^^^ File "/Users/jarek/.local/share/uv/tools/cherry-picker/lib/python3.12/site-packages/click/core.py", line 1157, in __call__ return self.main(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/jarek/.local/share/uv/tools/cherry-picker/lib/python3.12/site-packages/click/core.py", line 1078, in main rv = self.invoke(ctx) ^^^^^^^^^^^^^^^^ File "/Users/jarek/.local/share/uv/tools/cherry-picker/lib/python3.12/site-packages/click/core.py", line 1434, in invoke return ctx.invoke(self.callback, **ctx.params) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/jarek/.local/share/uv/tools/cherry-picker/lib/python3.12/site-packages/click/core.py", line 783, in invoke return __callback(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/jarek/.local/share/uv/tools/cherry-picker/lib/python3.12/site-packages/click/decorators.py", line 33, in new_func return f(get_current_context(), *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/jarek/IdeaProjects/cherry-picker/cherry_picker/cherry_picker.py", line 804, in cherry_pick_cli cherry_picker = CherryPicker( ^^^^^^^^^^^^^ File "/Users/jarek/IdeaProjects/cherry-picker/cherry_picker/cherry_picker.py", line 123, in __init__ self.check_repo() # may raise InvalidRepoException ^^^^^^^^^^^^^^^^^ File "/Users/jarek/IdeaProjects/cherry-picker/cherry_picker/cherry_picker.py", line 668, in check_repo raise InvalidRepoException(ve.args[0]) cherry_picker.cherry_picker.InvalidRepoException: Run state cherry-picker.state=BACKPORT_LOOP_START in Git config is not known. Perhaps it has been set by a newer version of cherry-picker. Try upgrading. Valid states are: BACKPORT_PAUSED, UNSET. If this looks suspicious, raise an issue at https://github.com/python/cherry-picker/issues/new. As the last resort you can reset the runtime state stored in Git config using the following command: `git config --local --remove-section cherry-picker` ``` So this PR checks for presence of that message in the exception and it will provide better explanation, and guidance in this case. Fixes: python#99
e9b83a5
to
0d86d1b
Compare
So you have to choose which is the best approach .. But clearly the need is there :) |
Looks green :) |
Any chance to get that improvement in :) (Friendly ping :D) |
When I played with cherry-picker as we introduced it in Airflow, I manage to set the repo to the state where I always got the message "You're not inside a airflow repo right now!"
After short debugging it turned out that it is because I manage to Ctrl-C and mix
git cherry-pick --abort
withcherry_picker
commands - when I learned how to use it, I did not know that I had to only usecherry-picker --continue
command rather than git commands.This might happen to others, so I think we should have a better way to handle this case.
When this happens you get this exception:
So this PR checks for presence of that message in the exception and it will provide better explanation, and guidance in this case.
Fixes: #99