Skip to content
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

Merged
merged 6 commits into from
Oct 21, 2016

Conversation

ohemorange
Copy link
Contributor

As per #3324.

@ohemorange ohemorange added this to the 0.10.0 milestone Oct 20, 2016
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.01%) to 98.759% when pulling 7d2b6ca on remove_dialog_two into b9adb7c on master.

@ohemorange
Copy link
Contributor Author

Coverage went down because I removed covered lines, and also because I fixed some of the testing code that runs when the tests break.

Copy link
Contributor

@jsha jsha left a 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.")
Copy link
Contributor

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?"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That it should!

Copy link
Contributor Author

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
Copy link
Contributor

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.."

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very true.

Copy link
Member

@bmw bmw left a 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.
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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")
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.01%) to 98.759% when pulling 4eeec42 on remove_dialog_two into b9adb7c on master.

@ohemorange
Copy link
Contributor Author

Re: certbot/interfaces.py - I'm fine keeping it in the interface and continuing to ignore it, on the off chance that this breaks some closed-source plugin.

@bmw
Copy link
Member

bmw commented Oct 21, 2016

I personally don't think reverting changes to certbot/interfaces.py and the notification methods in certbot/display/util.py is necessary. I was just bringing that up as an example of the kind of thing we need be careful about. I looked into it though and it doesn't seem to be a problem.

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.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.01%) to 98.76% when pulling f19eeda on remove_dialog_two into ce252bd on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.01%) to 98.76% when pulling ced5f34 on remove_dialog_two into ce252bd on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.01%) to 98.76% when pulling 25c8d18 on remove_dialog_two into ce252bd on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.01%) to 98.76% when pulling 25c8d18 on remove_dialog_two into ce252bd on master.

@ohemorange
Copy link
Contributor Author

All requested changes made!

@bmw bmw merged commit d54cb76 into master Oct 21, 2016
@pde pde deleted the remove_dialog_two branch November 18, 2016 20:27
@pde pde removed the has pr label Dec 8, 2016
archlinux-github pushed a commit to archlinux/aur that referenced this pull request Jul 29, 2022
Remove dialog, which is dropped since
certbot/certbot#3665
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants