Conversation
|
@raphigaziano Just wanted to let you know that this is on my mind, and that I really appreciate the pull request. I will be reviewing this shortly... |
|
Currently working on this in https://github.com/audreyr/cookiecutter/tree/raphigaziano-hooks...just a partial checkin after merging with other changes. I'll continue to work on this in the morning. |
|
Almost done. Overall this is all really, really good. I'm just trying to figure out where my merge broke |
|
Done with the merge, now playing around with the hooks before bringing it into master. This is sooo cool! I am so excited! I think a Cookiecutter plugin system will practically write itself based on this change. I can see it all coming together. |
|
Cool =) Not sure i understand how this could turn into a plugin system. Do you mean that a plugin would simply be a collection of various hooks ? Also, regarding more "internal" hooks like the ones suggested by @pydanny in #29: Should those be run externally as well ? I'm thinking requiring those to be in python and to define a standardized function so that we could import and execute that function directly would be more efficient, but it feels a bit inconsistent to have two different ways to handle various kinds of hooks. |
|
A plugin could be as simple as a Python module containing function definitions (I think like what you just described). Installation instructions for a plugin could say what function call(s) (and initialization steps if needed) should be added to your pre and/or post hook file. About the more "internal"-style hooks in #29, looking at that again, that looks like an example of a pre-generate script which adds context. Let's not worry about implementing exactly that; I don't think it's necessary now with your hook system. I'm not sure if this is what you mean, but yes, it would be good to have a standard best-practice way to:
|
|
Merged into master, but not on PyPI yet |
|
Also, just a heads up that I moved |
Revised questions based on our first user testing sesh
I started experimenting with running optional external scripts before and after a project generation, as i suggested in #33. I ignored the initial idea of hooks acting on the context, as this seemed harder to integrate with the current code. I'm thinking the run_hook function could do some dispatching to handle those. The two hooks implemented here could be used to create a virtualenv, initiate a git repo, pip install dependencies...
The way i'm avoiding copying the
hooksdirectory is pretty ugly. This suggests that a more standardized way of ignoring some template files/directories could be handy.I'm still having trouble running tox, so i hope this doesn't break things under 2.6 or 3.*. The whole suite ran fine under 2.7.