After the koji.conf 'pkgurl' attribute was enabled (sigul wants this; I'll submit a patch for that too, later), one of my scripts broke because the "Warning: the pkgurl option is obsolete" message is printed to stdout instead of stderr. Here's a little patch to print the warning with the warn() function instead.
I realize some warnings from the cli might be best printed to stdout, but for ones that might appear when using a computer-readable type of command like 'list-* --quiet', stderr seems like the better choice.
Thanks-
John
On 04/04/2012 01:16 PM, John Morris wrote:
After the koji.conf 'pkgurl' attribute was enabled (sigul wants this; I'll submit a patch for that too, later), one of my scripts broke because the "Warning: the pkgurl option is obsolete" message is printed to stdout instead of stderr. Here's a little patch to print the warning with the warn() function instead.
I realize some warnings from the cli might be best printed to stdout, but for ones that might appear when using a computer-readable type of command like 'list-* --quiet', stderr seems like the better choice.
I do highly recommend that scripts used the xmlrpc interface directly rather than screen-scraping.
However, I do agree that errors like this should go to stderr.
(also, please be wary of stray whitespace in patches)
Hi Mike,
I realize some warnings from the cli might be best printed to stdout, but for ones that might appear when using a computer-readable type of command like 'list-* --quiet', stderr seems like the better choice.
I do highly recommend that scripts used the xmlrpc interface directly rather than screen-scraping.
Yes, I do need something better. This raises a question I've had about workflow. The koji CLI is very simple. I think that most commands expose a single xmlrpc call (perhaps with a little sugaring). I haven't seen a document yet that describes workflow beyond the most basic steps. I often find myself doing cumbersome things, and think there must be an easier way. This example could be called 'list-tagged --rpms --nosigs':
koji list-tagged --rpms --sigs fc16-cadcam | \ sed '/^ /s/^/2ef86730/' | sort | uniq -u | sed 's/^[^ ]* //'
Is there some documentation I've missed somewhere? There are several pages on the wiki, but nothing I've found is very complete (other than the source!). Should I just not be using the CLI much and scripting my workflow instead?
(also, please be wary of stray whitespace in patches)
I see that I left a space at the end of the middle 'warn(' line. Is that what you mean? I'm not a real dev, so this kind of clue is helpful.
John
On 04/22/2012 04:14 AM, John Morris wrote:
Yes, I do need something better. This raises a question I've had about workflow. The koji CLI is very simple. I think that most commands expose a single xmlrpc call (perhaps with a little sugaring). I haven't seen a document yet that describes workflow beyond the most basic steps. I often find myself doing cumbersome things, and think there must be an easier way. This example could be called 'list-tagged --rpms --nosigs':
koji list-tagged --rpms --sigs fc16-cadcam | \ sed '/^ /s/^/2ef86730/' | sort | uniq -u | sed 's/^[^ ]* //'
Is there some documentation I've missed somewhere? There are several pages on the wiki, but nothing I've found is very complete (other than the source!). Should I just not be using the CLI much and scripting my workflow instead?
Our documentation is somewhat lacking unfortunately. I'm told the source is fairly readable, though as one of the authors I am not fit to judge :)
Of course, koji is a command line tool and it is quite legitimate to process its output in some ways. Your list-tagged example is fine, though you probably want the --quiet option to avoid printing the column headers.
The boundary where best practice shifts from standard shell output processing to writing a python script is somewhat fuzzy. It depends on what you're trying to accomplish.
I see that I left a space at the end of the middle 'warn(' line. Is that what you mean? I'm not a real dev, so this kind of clue is helpful.
Yeah, that's the one. Stray whitespace is disliked by many developers, myself included. The git-apply and git-am tools complain when they find it.
While not applicable to this case, leading whitespace can be an major issue in python, particularly when it comes to mixing spaces and tabs (we don't use tabs in Koji's code, though a few have slipped in over the years).
I use vim options to make visibly distinguish certain types of whitespace (e.g. "set list lcs=tab:>- lcs+=trail:-"). It's quite helpful. I think other development-friendly editors have similar features.
buildsys@lists.fedoraproject.org
-
John Morris -
Mike McLean