On Thu, Aug 16, 2018 at 4:34 PM Jeremy Cline <[email protected]> wrote:
> On 08/16/2018 11:53 AM, Michal Novotny wrote: > > On Thu, Aug 16, 2018 at 11:43 AM Jeremy Cline <[email protected]> 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? > I don't really have any objections. I would just like to be able to read messages as simple language-native structures and don't depend on anything else than the base messaging framework when publishing or receiving messages. > > > -- > Jeremy Cline > XMPP: [email protected] > IRC: jcline >
_______________________________________________ infrastructure mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected]/message/ADBAJELLLYXU7SAHZFFHGJTOLD7OKRJF/
