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

Issue #341 resolved
Edmund Wong created an issue

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

Comments (6)

  1. Thomas De Schampheleire

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

  2. Mads Kiilerich

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

  3. Thomas De Schampheleire

    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?

  4. Edmund Wong reporter

    @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
  5. Edmund Wong reporter

    @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": "", "locked_by": [n
    ull, null], "server_url": "", "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
    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.

  6. Thomas De Schampheleire

    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.

  7. Log in to comment