Project-specific releaser hooks in setup.cfg #17
Conversation
…having to read it repeatedly for hooks).
…c hooks listed in setup.cfg first, then calls the old run_entry_points to run any globally-installed entry points.
| logger.warning('cannot find %s hook: %s; skipping...', | ||
| hook_name, e.args[0]) | ||
| for hook in hooks: | ||
| hook(data) |
There was a problem hiding this comment.
Might be nice to add some additional error handling for when hooks fail; ditto for entry_points.
|
I like the idea and I can see its use. Simple fix that works well. One thing I dislike is the 'package_dir' name: it is a bit too generic. The term as such is right, but it doesn't tell you that it is really for the hooks. 'extra_package_dir_for_hooks' is a bit long, though. Do you have an alternative here? So... the approach is right, so could you add that test you mentioned? And perhaps a two-line note in the readme? |
|
Cool, I'm glad you like it. As for I'll see about coming up with some tests, and adding docs. |
|
By the way, I don't know if this is the best place to mention this, but I'll probably be submitting a number of patches over the coming weeks. I've been using zest.releaser for like a year now and rather like it. And while I agree with most of the default assumptions, there are some annoyances. Most of my patches will be geared toward making it a little easier to customize its behavior (while keeping the existing defaults, since I understand they're chosen for what works for Zest software). But if some of my patches aren't accepted for whatever reason is there any problem with me releasing a fork of some sort under a different name? |
|
hook_package_dir is fine. Regarding forking: it is all GPL, so you can fork to your heart's delight and release it under a different name. It ought to work just fine for most projects, though. I set it up with an eye on the Plone codebase and extensions and whatever of that time, so it is not just zest software's default. There are a couple of things I know of that aren't supported, but mostly because nobody bothered to implement it. So... could you add the points you have as tickets? Perhaps they're easy to support anyway. |
… a little less vague
|
I'm not really a Zope/Plone guy so I'm not entirely familiar with this test framework. I understand how it works, but I'm wondering: What's the best way to run a single test from the suite, rather than having to run the entire suite just to test the test? As for forking, I know it's GPL but I still think it's polite to ask :) I'll see about adding tickets for the other issues I want to bring up. Thanks again! |
|
To run only the tests in the git.txt file, run
|
|
Thanks--I'm not used to finding tests in text files like that, though I guess that should have been fairly clear. And no, I haven't abandoned this, just got side-tracked by work and stuff :) |
…r. Added a test (based on the functional-git.txt test with some redundancies removed) that tests whether the hooks are run and in the right places.
|
I have just merged this. Sorry it took so long. One thing I am wondering though: can we not use the existing package_dir option from setup.py instead of hook_package_dir in setup.cfg? |
|
No problem--thanks for merging. I have other stuff I wanted to submit for zest.releaser but haven't had time to work on it :/ Hopefully soon. The setup.py package_dir option could be used. The reason I added a separate option is that one might hypothetically want to put releaser hooks in a separate directory outside their main package, since there's not necessarily any reason to install them with the package. But the package_dir might not be bad to include as a default? |
|
Seems a good default yes. |
|
I have finally released 3.42 with this pull request. |
This pull request adds a feature I've been wanting a long time which is the ability to list project-specific releaser hooks in the setup.cfg for a project under the
[zest.releaser]section.Each hook point (prereleaser.before, etc) is given as one or more fully qualified Python function names. Just as with the entry_points, each hook function takes the data dict as its sole argument. entry_points are still run, but only after the project-specific hooks. This eliminates the annoyance of having to install my project just so that the correct entry_points are installed in order to do a release.
No tests yet, but if this approach looks good I'll add some. FWIW I tested this with one of my own projects and it works as expected.