ansible-cmdb icon indicating copy to clipboard operation
ansible-cmdb copied to clipboard

prefering python2 causes failure because of missing dependancies

Open archf opened this issue 6 years ago • 5 comments
trafficstars

This logic in /usr/local/bin/ansible-cmdb makes it that python2 is picked even when python3 is available and as dependencies got installed under python3 it will fail:

# Find python binary
PY_BIN=$(which python)
if [ -z "$PY_BIN" ]; then
    PY_BIN=$(which python3)
fi
if [ -z "$PY_BIN" ]; then
    echo "No python found. Aborting"
    exit 1
fi

e.g:

archf@wm ~/r/w/g/m/o/scripts master?> /usr/local/bin/ansible-cmdb -h
Traceback (most recent call last):
  File "/usr/local/bin/../lib/ansiblecmdb/ansible-cmdb.py", line 19, in <module>
    from mako import exceptions
ImportError: No module named mako

I think it should try python3 first. My operating system is Ubuntu 18.04. I suspect it might be working only on Fedora,RHEL,CentOS as of now.

Regards, Thanks for coding this software.

archf avatar Jan 09 '19 20:01 archf

Hi Felix!

Sorry for the late reply! I've been very busy.

There's a very good chance that this will be fixed by the pull request in #190. I'll try that one out soon, and if it fixes this problem, I'll update this ticket.

fboender avatar Mar 06 '19 21:03 fboender

Hi Ferry,

No worry and no rush. If you knew how I left some PR dangling too. Opensource is volunteering after all and we all have other priorities...

I got it to work hacking the shell script in place...

Regards,

On Wed, Mar 6, 2019, 16:19 Ferry Boender, [email protected] wrote:

Hi Felix!

Sorry for the late reply! I've been very busy.

There's a very good chance that this will be fixed by the pull request in #190 https://github.com/fboender/ansible-cmdb/issues/190. I'll try that one out soon, and if it fixes this problem, I'll update this ticket.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/fboender/ansible-cmdb/issues/189#issuecomment-470280970, or mute the thread https://github.com/notifications/unsubscribe-auth/AGSSfFIQzTAdAD2mIJAR4-z9O9f-6HfXks5vUDDrgaJpZM4Z4SkL .

archf avatar Mar 07 '19 12:03 archf

@fboender we're running into this issue on systems with "python" and "python3" where the former is python2. I think the current implementation in https://github.com/fboender/ansible-cmdb/blob/master/src/ansible-cmdb will not fix the issue at hand. https://github.com/fboender/ansible-cmdb/blob/master/src/ansible-cmdb#L14 will still only see one python interpreter, which on most systems is just python2.

My personal preference would be to check for an environment variable to refer to the python interpreter to use. If it's set use the one defined, otherwise run the detection logic.

Even if you would run "which -a python python3" (to cover the most common interpreter) you would still default to the first one, which might or my not be a good choice for the current user.

hoexter avatar Sep 23 '19 15:09 hoexter

I got the same bug in my CI/CD i fixed by adding a symlink from python3 to python ln -s /usr/bin/python3 /usr/bin/python I guess something is looking for python and not python3.

iacgg avatar Jun 08 '21 14:06 iacgg

I guess this line could be improved a bit https://github.com/fboender/ansible-cmdb/blob/8e7f8d2a422f80cb2c43b1eaea2f2d9450834c10/src/ansible-cmdb#L14 its a little old school to only look for "python" but i have not looked much into it, hope it can help. Simple one that could be tested which -a python python3

iacgg avatar Jun 08 '21 14:06 iacgg