-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Remove the curses dialog, thereby deprecating the --help and --dialog command line options #3665
Conversation
… command line options
Coverage went down because I removed covered lines, and also because I fixed some of the testing code that runs when the tests break. |
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.
Overall LGTM. I am excited for this change!
@@ -677,7 +666,7 @@ def prepare_and_parse_args(plugins, args, detect_defaults=False): # pylint: dis | |||
"e.g. -vvv.") | |||
helpful.add( | |||
None, "-t", "--text", dest="text_mode", action="store_true", | |||
help="Use the text output instead of the curses UI.") | |||
help="Use the text output.") |
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.
Shouldn't this also say "Deprecated - this has no effect?"
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.
That it should!
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 right now I remember, I left this in on the off chance we eventually implement something else for the IDialog
interface. I'll make this clear though.
@@ -246,7 +246,7 @@ configuration checkpoints and rollback. | |||
Display | |||
~~~~~~~ | |||
|
|||
We currently offer a pythondialog and "text" mode for displays. Display | |||
We currently offer a "text" mode for displays. Display |
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.
This should probably say "We currently only offer.."
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.
Very 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.
I wanted to review this as well since this is such a dramatic change. For example, we have to be careful when modifying interfaces in certbot/interfaces.py
as they may be used by our 3rd party plugins, however, as of writing this, there are apparently no known 3rd party plugins that use IDisplay
.
Other than my two comments, this LGTM. I love how much code this PR is deleting.
@@ -22,14 +22,11 @@ optional arguments: | |||
-v, --verbose This flag can be used multiple times to incrementally | |||
increase the verbosity of output, e.g. -vvv. (default: | |||
-2) | |||
-t, --text Use the text output instead of the curses UI. |
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.
This is another of our "only modify during releases" files, except this one doesn't have a test to catch the problem. The reason we don't modify this is we use this file to generate our documentation at https://certbot.eff.org/docs/using.html#command-line and we want to keep this information synced with the current release.
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.
Ok it seems the correct choice here is to not generate the documentation on that website based on master, but instead to generate it based on the release branch. Is there already an issue for that, or a reason why we don't already do 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.
We often change the documentation for reasons other than a new release. We could delay publishing changes until a release has been done, but blocking all improvements to our documentation to keep this file in lockstep seems undesirable to me.
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 these documentation changes urgent enough that they can't wait for a new release? If we release regularly, this shouldn't be a problem.
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.
They are rarely urgent, however, they do offer a better experience for the user. Why should we tie our hands and force ourselves to sit on these changes until we do a release?
And while I wouldn't call them urgent, there are definitely times we want to make changes outside of a release. For example, the stuff that I've been working on involves doc changes and needs to go live almost immediately so it is up before super secret project that I'm not sure I'm allowed to talk about publicly involving encryption, pipes, and Noah the hacker is released. Another example of changes like this is changes in OS packaging such as when a new version of a distro is released.
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.
Ok, sounds like we want an update schedule for docs that is decoupled from the certbot release schedule. Let's put it in a new repo! I'm fine with the anti-pattern of "you can't change these files in master until release" if it's because we used to think that was ok and changing it now will break things, but for another site we control that seems strange.
Anyway, for now I'll move the docs changes into a separate PR and have that chill until release.
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.
Yeah I think there are a number of things we could do to make this a little nicer for developers. I think it could get a bit tricky though.
And no need to make a separate PR. These changes happen automatically in our release script.
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.
Cool! I also modified docs/contributing.rst
, should I make a separate PR for that 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.
Oh sorry. I missed that one. Yeah I suppose you should make a separate PR that we can merge during the release.
@@ -686,7 +675,7 @@ def prepare_and_parse_args(plugins, args, detect_defaults=False): # pylint: dis | |||
"which ones are required if it finds one missing") | |||
helpful.add( | |||
None, "--dialog", dest="dialog_mode", action="store_true", | |||
help="Run using interactive dialog menus") | |||
help="Deprecated - this has no effect") |
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 we should suppress help output here rather than continuing to print messages about a deprecated flag. We have a utility function for deprecating arguments called add_deprecated_argument that does this. I think the only reason we may not want to use this is it will cause a warning to be printed whenever the flag is used. This might be overkill for flags like --text
that might be used in renewal scripts.
If we don't want to print a warning, we should use argparse.SUPPRESS
here as it's done in add_deprecated_argument
.
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 wonder if literally anyone ever used the --dialog
flag, I have no problem deprecating that one properly.
As for --text
, we have a whole bunch of tests that use it, I think suppressing it is the right move.
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 agree. Let's deprecate --dialog
and suppress help output from --text
.
Re: |
I personally don't think reverting changes to While it's possible there is some closed source plugin out there, none of us have ever heard about it. I personally think we should take advantage of this and use it as a chance to clean up the API a bit. I don't have a strong opinion here though, so feel free to revert these changes if you wish. |
All requested changes made! |
Remove dialog, which is dropped since certbot/certbot#3665
As per #3324.