On 08/16/2018 11:53 AM, Michal Novotny wrote:
> On Thu, Aug 16, 2018 at 11:43 AM Jeremy Cline <jeremy@jcline.org> wrote:
<snip>

>> The current solution is fedmsg-meta-fedora-infrastructure, a central
>> Python module where schema are poorly encoded by a series of if/else
>> statements. It also regularly breaks when message schema change. For
>> example, I have 2200 emails from the notifications system about how some
>> Copr and Bodhi messages are unparsable. No one remembers to update the
>> package, and it ultimately means their messages are dropped or arrive to
>> users as incomprehensible JSON.
>>
>
> Yup, on behalf of Copr, I am sorry for that. This was caused by some bugs in
> our code. But these things would be captured by the publisher validation in
> the new framework. By the way, we would also like to have validators like
> "NEVRA" available, maybe in a library, maybe we can implement it ourselves.
> In one of the instances, we weren't sending release (I think) and it broke
> the
> fedmsg-meta service. That service is kind of sensitive.
>

Yes, it is sensitive. And to be clear, I'm not pointing fingers here.
It's just a good example of how what we're doing now doesn't work. I
want to put the ability (and responsibility) to making a message
readable and documented in the hands of app maintainers.

>
>>
>> With the current approach, you can just implement a __str__ method on a
>> class you keep in the same Git repo you use for your project. You can
>> write documentation on the classes so users can see what messages your
>> projects send. You can release it whenever you see fit, not when whoever
>> maintains fedmsg-meta has time to make a release.
>>
>> It seems like your main objection is the Python package. Personally, I
>> think making a Python package is a trivial amount of work for the
>> benefit of being able to define an arbitrary Python API to work with
>> your messages, but maybe that's not a widely-shared sentiment. If it's
>> not and we decide the only thing we really want in addition to the
>> message is a human-readable string, maybe we could include that in the
>> message in a standard way.
>
>
> Might be also a way.

So, am I right in saying your main objection is the Python package? Or
do you object to then packaging that as an RPM?

--
Jeremy Cline
XMPP: jeremy@jcline.org
IRC:  jcline