I stumbled upon the same issue.

The reason why local imports don't work is that the "hook" script you write is meant to be executed as a standalone script, because it's actually a template that is processed by Jinja2, written to a temporary file (with an arbitrary name) and then executed.

How Can We Fix This?

To solve this situation, all files from the hooks directory would have to be generated (i.e. processed by Jinja2) and executed in the same (temporary) directory.

A positive "side-effect" of this would be that we would retain the filename of the hooks (that can then still be accessed via __file__, e.g. for initializing a Python logger). At the moment this is a temporary file name.

We could add the hooks directory to the PYTHONPATH envvar of the subprocess call?

@henrahmagix, @bittner: would either of you be interested in putting together a PR for this change?

@michaeljoseph Manipulating the PYTHONPATH only makes sense for a generated version of the hooks directory. In other words, we still must consider creating some temporary folder. Then again, we need to take care about when we process the hooks: If we process them all before the template generation but expect some value in the post-generate hook that is only available afterwards we're screwed. (Not sure if this is a valid case; I have little experience with cookiecutter.)

Re preparing a PR: I have accepted the way cookiecutter hooks work for the moment, and my main use case for a shared, locally imported util module has vanished. I would be ready to prepare a PR if I face the situation again. (Not now, sorry!)

@bittner, we don't need to generate all the files in hooks directory as long as any shared modules / non-hook files in the hooks directory don't require templating.

We have the cookiecutter template checked-out somewhere (<repo_dir>), the temporary generated hook file (/tmp/hook.py) and we execute the script with the cwd of the generated project directory (<project_dir>).
So, we'd end up with a command like:
cd <project_dir>; PYTHONPATH=<repo_dir>/hooks python /tmp/hook.py which would, I think, fix the ImportError generated by @henrahmagix's template?

@michaeljoseph Ack! My response email has been in my drafts! Sorry I didn't notice until now. Here it is...

would either of you be interested in putting together a PR for this change?

Alas, my Python skills are beginner and I haven't read through this project's code very much (yet!) So whilst I will certainly look (and have been looking) into it, I wouldn't be a reliable implementer =)

@theodesp would you like to have a go at implementing this? 🙏

OK I will give it a go

PR #980

Thanks @theodesp!

Hi, this issue is still exists?
I got the error like this
'''
Traceback (most recent call last):
File "/tmp/tmphdaz_9n_.py", line 41, in
from hooks.utils import log_module_name_warning
ModuleNotFoundError: No module named 'hooks'
ERROR: Stopping generation because pre_gen_project hook script didn't exit successfully
Hook script failed (exit status: 1)
'''

Any updates on this issue?

As discussed, I get around this by configuring the PYTHONPATH:

git clone https://github.com/org/template.git
export PYTHONPATH=$PYTHONPATH:`pwd`/template/hooks
cookiecutter ./template

It's not ideal for public templates though, preferably end users don't need to clone and delete the repository themselves. Automatically configuring the PYTHONPATH for the execution of the template would be awesome.