Fix interpreter selection in the ansible-cmdb wrapper - #4
Open
gdevenyi wants to merge 2 commits into
Open
Conversation
The src/ansible-cmdb wrapper searched for an interpreter with
'which -a python'. On Debian 11 (bullseye) and later, and on recent
Ubuntu, there is no unversioned 'python' binary unless python-is-python3
is installed, so the search returned nothing and the wrapper aborted with:
No suitable python version found (v2.7 or higher required). Aborting
Search 'python3 python2 python' instead. The existing version check in
the loop already prefers Python 3, and listing python3 first means it is
found without relying on a distro-provided compatibility symlink.
Original patch by oxivanisher in fboender#240.
There was a problem hiding this comment.
Pull request overview
Updates the src/ansible-cmdb shell wrapper’s interpreter discovery so it works on modern Debian/Ubuntu systems that don’t provide an unversioned python binary by default, preventing false “No suitable python version found” aborts.
Changes:
- Searches for
python3, thenpython2, thenpythonwhen locating a usable interpreter (while retaining the existing version-selection logic).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The wrapper searches $PATH for an interpreter, so an installed
'<venv>/bin/ansible-cmdb' invoked by its absolute path finds the *system*
python rather than the venv's, and dies before it does anything useful:
$ .venv/bin/ansible-cmdb --version
ModuleNotFoundError: No module named 'ansiblecmdb'
It only works when the venv happens to be activated, which is easy to
miss because activating it makes the problem disappear.
Check for a python3/python sitting next to the wrapper first. In a
virtualenv that is the interpreter the package was installed for, and
the only one that can import ansiblecmdb. When there is no sibling --
a system-wide install, or running from the source tree -- it falls
through to the existing $PATH search, so those paths are unchanged.
gdevenyi
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two independent ways the
src/ansible-cmdbwrapper picks the wrong interpreter — or none at all. Both are one-liners infind_py_bin().1. No unversioned
pythonon modern distrosFixes fboender/ansible-cmdb#240, and as a side effect #189.
The search was:
Debian 11+ and recent Ubuntu ship no unversioned
pythonunlesspython-is-python3is installed, so this finds nothing and the wrapper aborts:...on a system with a perfectly good Python 3. Now searches
python3 python2 python.This also resolves fboender#189. The loop accepts the first candidate that is Python 3 or Python ≥2.7, so where
/usr/bin/pythonis 2.7 it won that race and you got missing-dependency failures. Listingpython3first means it is tried first.2. Installed venv binaries fail unless the venv is activated
Because the search only consults
$PATH, an installed wrapper invoked by absolute path finds the system python:That's easy to misdiagnose, because activating the venv makes it disappear.
The wrapper now prefers a
python3/pythonsitting next to itself. In a virtualenv that's the interpreter the package was installed for, and the only one that can importansiblecmdb. With no sibling — system-wide install, or running from the source tree — it falls through to the$PATHsearch unchanged.Testing
python3but no barepython: old code finds nothing, new code resolvespython3.<venv>/bin/ansible-cmdb --versionby absolute path with the venv not activated: fails before, works after.$PATH.sh -nclean.No conflicts with the other open PRs — this branch only touches
src/ansible-cmdb.