Re: fedora-review JSON API
On 08/07/2012 03:47 PM, Mikolaj Izdebski wrote:
Hi,
> Let me know what you think...
First of all let me begin with my motives. I think that Fedora Review
can be useful not only for doing initial package reviews but also to
perform regular QA checks of existing packages. It's especially useful
if you are maintaining many packages of the same type (like Java or
Perl packages) for which you can write many automated tests.
Writing single checks should be easy and shouldn't require knowing any
complex API so that any user could write their own checks. I think that
simple shell script is good enough in most of the cases. Some
variables like pkg name, version etc would be exported as
environmental variables, more complex things would be extracted on
disk (as F-R does now, but more things could be extracted too). So my
goal was creating a layer that could integrate those shell scripts
with Fedora Review. Some proof of concept will be available soon.
I wrote a JSON plugin instead of native python plugin only because I
don't know Python, but I talked to Stano and we considered
reimplementing that in Python to overcome some limitations of JSON
API.
[cut]
One simple question is if we should drop the API.... I'm not convinced
myself, but want's to raise the issue.
The arguments to drop it are obvious. First of all, it's doesn't seem to
be used. We (well, I) actually broke the API completely in 0.2.0 (see
issue #84), but there is just one bug report from Mikolaj so far. Also,
to maintain an API like the JSON is far more complex than ,maintaining a
python plugin interface. And our maybe only API user is thinking of
reimplementing in python anyway according to above...
OTOH, the idea that e. g., the perl community make their tests in perl
(or whatever language they prefer) is attractive, I can see that.
Keeping a simple API usable from e. g. bash is also in line with
mizdebsk's reasoning above.
One thing is definitely sure: if the API should be used, it must be
updated at least to handle attachments and get a unit test. There is
probably more just to make it match the current python interface. And
maybe even more to fit more general usecases as described by Mikolaj
above (which is kind of an exciting idea).
Thoughts?
--alec