On Wed, 2014-05-07 at 16:07 -0400, Chris Lumens wrote: > While you are looking in this area, it may very well be worth switching > anaconda to using argparse instead of optparse. The latter is no longer > really being developed, and I know that argparse does a much better job > with translated help text than optparse does. That's not a bad idea at all! :) Why not, I'll just do it when I'm at it. > > > * The help texts are currently printed one after another without any > > padding, creating a huge wall-of-text-column on the right side of the > > screen. > > Do we want to add some white space or other formatting between them and > > will optparse be able to do that ? One possible downside is that it will > > make the already long help output even longer. > > We have our own help text formatter at the moment. Just running > anaconda --help the first thing I notice is that the text is only being > displayed in the left perhaps 50% of my terminal windows, so we may want > to teach our help text formatter about terminal width for better > wrapping. Definitely! Also maybe argparse might already have something built-in for this we can use. > > > * Some options might make sense/work only in > > netinst/liveinst/dirinst/imageinst/etc. or even mean different things in > > different modes. The question is - what to do about this ? > > Should each option have an indication in what mode it should be used ? > > > > One other solution would be to group the options to groups, say a group > > for all options specific to an installation mode and a group for > > multi-use options. For example the firewall-cmd command --help work like > > this. > > Certainly, grouping options is one way to go. Otherwise I would say > yes, options should be somehow marked with what modes they are relevant > for. This could get a little overwhelming though. Probably grouping is > the nicest looking way to do it. OK, will use grouping then. > > > Another possible solution would be to just print options relevant to > > CLI use-cases. On the other hand this would prevent people from using > > their locally installed Anaconda as a reference for Anaconda boot > > options. > > I think if you're going to do it, you should just go all the way with > it. Otherwise people are going to ask for more and more until you end > up doing it all anyway. Might as well plan for that from the beginning. > > > * man page ! I think would not be difficult to generate a useful > > anaconda man-page from the anaconda_options.txt file holding the > > help text. What do you think ? :) > > If it can be generated from the same data, sure! Turns out it is possibly even easier than I though: http://www.gnu.org/software/help2man/ It basically parses the output from --help and spits out a simple man page. I guess I'll have to check the quality of the output, but it might just work! :) > > - Chris > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
