Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

py-zabbix and pyzabbix conflict #164

Open
AkvenJan opened this issue Apr 18, 2022 · 5 comments
Open

py-zabbix and pyzabbix conflict #164

AkvenJan opened this issue Apr 18, 2022 · 5 comments

Comments

@AkvenJan
Copy link

AkvenJan commented Apr 18, 2022

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
Copy link
Owner

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 jooola pinned this issue Jul 23, 2022
@jooola
Copy link
Collaborator

jooola commented Jul 23, 2022

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
Copy link

adubkov commented Jul 23, 2022

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
Copy link
Collaborator

jooola commented Jul 23, 2022

@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
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants