feat: add sender for Zabbix trapper items

[jooola]

Reach feature parity with adubkov/py-zabbix.

[szuro]

Just a thought: For some time now I'm developing and maintaining a package that implements most aspects of Zabbix protocol (sender included) over at: https://gitlab.com/szuro/zappix

It is pretty feature-rich: it supports PSK encryption and bulk sending from files with active node selection (for HA in Zabbix 6.0)and more on the way. Maybe it would be a better idea to import and wrap it instead of duplicating codebase?

[jooola]

Just a thought: For some time now I'm developing and maintaining a package that implements most aspects of Zabbix protocol (sender included) over at: https://gitlab.com/szuro/zappix

It is pretty feature-rich: it supports PSK encryption and bulk sending from files with active node selection (for HA in Zabbix 6.0)and more on the way. Maybe it would be a better idea to import and wrap it instead of duplicating codebase?

Oh didn't knew about this project. I am all for joining the different projects together. I think you are right we should probably merge your project instead of the one at adubkov/py-zabbix.

Do you have write permission on this repository ? If not maybe @lukecyca could give it to you so you still have a hand on your project. Would you deprecate you project if we merge it in here ? Do you have time to help out for the import ?

We might need to write some migrations guide for users coming from both py-zabbix or zappix.

[szuro]

Do you have write permission on this repository ? If not maybe @lukecyca could give it to you so you still have a hand on your project.

I do not have such permissions and it would be nice if I could keep developing it as I had up to this point.

Would you deprecate you project if we merge it in here ? We might need to write some migrations guide for users coming from both py-zabbix or zappix.

I'll most likely introduce some breaking changes during the import, so a guide would be in place. I the aim is to make pyzabbix the zabbix library, then yes I would deprecate that project and plaster it with warnings. It would also make sense to merge my other project: https://github.com/szuro/zabbix-enums

Are we aiming for any interface compatibility or are we going only for feature parity? This will impact some design decisions.

Do you have time to help out for the import ?

Depends on the deadline. If you want do finish it by the end of next week, then no. By the end of August? Sure.

Should we setup a gitter or something similar moving forward?

[jooola]

It would also make sense to merge my other project: https://github.com/szuro/zabbix-enums

Agreed, we have to think of a clean structure so we properly split/namespace each features. Maybe pyzabbix/api with the enums going in there ? And pyzabbix/sender pyzabbix/agent ? I haven't looked too much into details what zappix will bring, you probably have a better idea.

Are we aiming for any interface compatibility or are we going only for feature parity? This will impact some design decisions.

I think we should aim for unifying all the duplicate code bases. The initial idea was to reach feature parity with adubkov/py-zabbix so we could solve this namespace issue. But since they are other more advanced project such as yours that could fit instead, I am all for putting all the effort in a single package. I don't think pyzabbix should handle every use cases but having all the building blocks to easily work with zabbix is a good idea.

Depends on the deadline. If you want do finish it by the end of next week, then no. By the end of August? Sure.

We can plan some discussions to be on the same page and having this done by end august seem doable, but I am not sure I'll be able to follow a deadline if we set any. Not sure we need one.

Should we setup a gitter or something similar moving forward?

I am on matrix.org @ joola, but I think having a issue ticket with decisions and details on what is gonna happen would be a good idea so others know what is going on.

[szuro]

Given that we want to combine 3 projects into a single one, I'm worried that the namespace will be bloated. The most straightforward solution would go something like this:

pyzabbix
  |-api
  |  |-ZabbixAPI
  |  |-ZabbixException
  |  |-Other classes
  |  |-enums
  |      |-z60
  |      |   |-host
  |      |   |   |-HostStatus
  |      |   |-other objects
  |      |-other versions
  |-network(?)
      |-Sender,Get,Agent
      |-Data classes 

Would this be easy to use by everyone?

Good to know we're in no hurry to unify all packages - a rushed design would probably result in failure.

I think having a issue ticket with decisions and details on what is gonna happen would be a good idea so others know what is going on.

Should we move this discussion to a ticket then? A PR is not the obvious place to look for such discussions.