[anaconda][master][PATCH] Improving the Anaconda CLI help - second batch

Anne Mulhern amulhern at redhat.com
Mon Jun 23 11:31:44 UTC 2014





----- Original Message -----
> From: "Martin Kolman" <mkolman at redhat.com>
> To: "anaconda patch review" <anaconda-patches at lists.fedorahosted.org>
> Sent: Monday, June 23, 2014 7:08:20 AM
> Subject: Re: [anaconda][master][PATCH] Improving the Anaconda CLI help -	second batch
> 
> On Fri, 2014-06-20 at 11:34 -0400, Chris Lumens wrote:
> > > BTW, it looks like we have yet again some outdated information in the
> > > wiki page -
> > > I've already fixed some minor details but I'd eventually like to do a
> > > more comprehensive
> > > "correction sweep". Also some better structuring & an overview table
> > > would be nice. :)
> > 
> > Could data/anaconda_options.txt be given in some format (markdown,
> > etc.?)
> Maybe reStructuredText ? We are already kinda using it in the form of
> the Spnihx docstrings. On the other hand the format we can use kinda
> depends on what the wiki markup generator will be able to use.
> >  that can then be processed into text that can be pasted into the
> > wiki page?  It'd be nice to have one source for these two places, even
> > if it does end up requiring a manual step on our part.
> Definitely - we now have three totally independent places we need to
> manually keep in sync and that's not good.
> 
> Still, there are a few issues wee need to work out to make this work
> correctly. If we add markup to the help text source file,
> then we not only need a tool that spits out the wiki markup,
> but also one that removes all the markup and can be run
> during build (or testing) to provided the plain text variant
> for the actual help texts.

It might be better to generate the markup text
from the help text source file
as part of the make process. The help text source file has a very
simple structure, so it would be easy to surround the bits with
markup.

> 
> Also, some of the stuff we have on the wiki might not be appropriate
> for the help texts - like the list of all possible kickstart URL
> variants that can be used. So we will need also something like
> a <wiki_only></wiki_only> tag that the parsing tool understands
> and omits the content for the wiki page. Same thing might bee needed
> for CLI only stuff. This should be quite easy to do though.
> 
> Another thing we will need to take care of is that there are basically
> 4 types of options - boot-only options, CLI-only options (--liveinst,
> --image, etc.), common options and (on the wiki page) non-Anaconda
> options that are useful for setting up the installation environment.
> 
> I plan to add boot-only, CLI-only and common grouping to the help texts
> (argparse looks like it can do that), so I guess we could apply the same
> thing when generating the wiki markup, differentiating the groups for
> example by a header. As for the non-Anaconda options, they would just
> have their own static section on the page, like they have now.

If the grouping information ends up in the help text source file that
might be a good thing, and helpful with the generation of markup.

> > 
> > - Chris
> > _______________________________________________
> > anaconda-patches mailing list
> > anaconda-patches at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
> 
> _______________________________________________
> anaconda-patches mailing list
> anaconda-patches at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
> 

- mulhern


More information about the anaconda-patches mailing list