Kallithea issues archive

Issue #341: 0.4.0: git hooks 'work' but outputs ImportError: No module named kallithea.lib.hooks

Reported by: Edmund Wong
State: resolved
Created on: 2019-04-02 08:25
Updated on: 2019-05-04 19:31

Description

After adding the patch from issue#333, and after pushing a change to a git repo, the following appears:

remote:     - /home/kali/tmp/src
remote: Traceback (most recent call last):
remote:   File "hooks/post-receive", line 26, in <module>
remote:     import kallithea.lib.hooks
remote: ImportError: No module named kallithea.lib.hooks
To http://ewong@127.0.0.1:5562/kali/testgit2
   c08fcdb..008fff4  master -> master

The steps to reproduce:

1) Create a new Git repo 2) Clone repo to client 3) make a change and push to the git repo (and assuming issue #333's patch is applied) 4) the error appears.

printing out the sys.path list, it does show the kallithea's venv's site-packages path in it, and the kallithea module is in that directory. So not sure what I missed.

Attachments

Comments

Comment by Thomas De Schampheleire, on 2019-04-02 09:19

Could you also report the interpreter that is present at the top of the post-receive hook? Thanks.

Comment by Mads Kiilerich, on 2019-04-02 10:12

I guess the problem might be that even though VIRTUAL_ENV is set while setting hooks (and the right python thus in PATH), the same PATH might not be set when the hook is run? We should probably always substitute with the absolute path of the python interpreter. Perhaps by using Mercurial findexe. Or perhaps we should use sys.executable in most cases. Perhaps only use special heuristics (or user configuration) in cases where we know sys.executable doesn't work (like uwsgi).

Comment by Thomas De Schampheleire, on 2019-04-02 11:52

uwsgi is not the only problem, also apache+mod_wsgi has this problem. This is what @ewongcc is using, and the original sys.executable resolves to /usr/bin/python, which in his case is Python 2.6 (not the right one).

Perhaps we should first investigate that problem, perhaps a bad configuration of mod_wsgi. It may turn out that uwsgi is indeed the only remaining problem for sys.executable.

@ewongcc : the fact that the interpreter of your git hooks uses /usr/bin/python needs to be investigated, because it should have pointed to your virtualenv's python. Did you install the git hooks via the UI (Admin>Settings>VCS) ? Can you post your configuration for apache+mod_wsgi and how it calls Kallithea?

Comment by Edmund Wong, on 2019-04-02 13:38

@patrickdepinguin Yes, I installed the git hooks via the UI.

I'll do a thorough investigation. At the moment, at the top, the pre-receive hook has:

#!/bin/env python2.7

Comment by Edmund Wong, on 2019-04-02 15:20

@kiilerix funny you should mention VIRTUAL_ENV. After adding the following before the import kallithea.lib.hooks:

for item in os.environ:
    print("    - %s:  %s" % (item, os.environ.get(item)))

I get a list of environment variables; but VIRTUAL_ENV doesn't exist in that list.

remote:   LANG: en_US.utf8
remote:   TERM: xterm
remote:   KALLITHEA_EXTRAS: {"username": "ewong", "scm": "git", "repository": "testgit2", "make_lock": null, "ip": "10.0.210.10", "locked_by": [n
ull, null], "server_url": "http://127.0.0.1:5562/kali", "action": "push", "confi
g": "/var/www/kali/srv/my.ini"}
remote:   SHLVL: 2
remote:   KALLITHEA_HOOK_VER: 0.4.0
remote:   PWD: /
remote:   GIT_DIR: .
remote:   HOME: /var/www/environments/kalivenv
remote:   PATH: /usr/libexec/git-core:/usr/libexec/git-core:/usr/bin:/var/www/en
vironments/kalivenv/bin:/sbin:/usr/sbin:/bin:/usr/bin
remote:   _: /usr/sbin/httpd
remote:   GIT_CONFIG_NOGLOBAL: 1
remote: Traceback (most recent call last):
remote:   File "hooks/post-receive", line 26, in <module>
remote:     import kallithea.lib.hooks
remote: ImportError: No module named kallithea.lib.hooks

I'm going to check out the dispatch.wsgi and see if I missed something vital.

Comment by Thomas De Schampheleire, on 2019-05-04 19:31

This should be solved via commits 1bafb2d07709 and 6df08d78f8e7.

This means: regenerate the config file so that the correct python interpreter is filled in, then rescan your repositories and reinstall git hooks. After these actions, your problem should be gone.