search

lukecyca / pyzabbix

Python Zabbix API
970 stars 313 forks source link

py-zabbix and pyzabbix conflict #164

Open AkvenJan opened 2 years ago

AkvenJan commented 2 years ago

Why both of your modules use the same pip install folders? I have server with several running scripts. Some of the scripts use pyzabbix module, and another ones py-zabbix module (scripts from the internet, I don't have time to review every one of them). And one bunch of them is always not working because of using the same name from another module.

Modules installation paths: py-zabbix (https://github.com/adubkov/py-zabbix) /usr/local/lib/python3.8/dist-packages/py_zabbix-1.1.7.dist-info/ /usr/local/lib/python3.8/dist-packages/pyzabbix/ /usr/local/lib/python3.8/dist-packages/zabbix/ pyzabbix (https://github.com/lukecyca/pyzabbix) /usr/local/lib/python3.8/dist-packages/pyzabbix-1.0.0.dist-info/ /usr/local/lib/python3.8/dist-packages/pyzabbix/*

I was able to fix it by installing pyzabbix, renaming its folder to pyzabbix2 and uninstalling and then installing py-zabbix and using "from pyzabbix2 import ZabbixAPI" for the first module But this is fundamentally wrong! Maybe you should somehow cooperate and use you own names/folders to avoid such conflicts?

lukecyca commented 2 years ago

This is the first I've heard of adubkov/py-zabbix). I agree that having two different projects using the same namespace is not great for anyone. I believe the package name should exactly reflect the namespace to which it installs itself.

My library has been around since 2011 and has been using the pyzabbix namespace that whole time. Adubkov/py-zabbix looks like it was started in 2015 using the zabbix namespace and then switched to using the pyzabbix namespace in 2016 (but according to their setup.py they are still installing something into both namespaces.

In adubkov/py-zabbix#132 this was brought up and @adubkov declined to change it. For the same reasons it would be difficult for us to change. We've been around even longer, have more stars/forks/contributors/etc... It would likely break a lot of scripts that people have made.

That said, I am not too active in maintaining this project anymore as I'm not currently even using Zabbix. For the last few years this project has been maintained by other contributors and seems to be going well. I simply publish a new version on PyPI periodically. I'm not opposed to merging the two libraries, passing this off to others who are more engaged, etc. I'll leave this open for discussion for a while.

jooola commented 2 years ago

If this package reach feature parity with py-zabbix, we might have a chance to merge the effort. Having a single library should benefit everyone.

adubkov commented 2 years ago

I also do not have time to actively work on py-zabbix, but I agree that if we can merge two projects without introducing braking changes for both, it would be ideal.

jooola commented 2 years ago

@adubkov I might be able to tackle this. Is that ok for you if I reuse some of your code and merge it in here ?

I don't know exactly how much difference there is between the 2 APIs, but it seem they both originate from the same library, so should be doable.

evilhamsterman commented 2 years ago

@AkvenJan I agree with you that the namespaces should be cleared up. But have you tried using python virtual environments to avoid the conflict. Virtual environments are specifically for solving problems like this.