-
-
Notifications
You must be signed in to change notification settings - Fork 44
Command hooks #112
Command hooks #112
Conversation
480d416 to
f4aa400
Compare
|
Rebased on #110 . |
|
@astrofrog Does this look good for you for astropy/astropy#3166 ? I think it would mostly suffice to change the |
|
@embray - thanks for your work on this - this is awesome! I will try it out in astropy/astropy#3166 now :) |
f4aa400 to
91faa7e
Compare
|
Rebased to include ee59f09, so this should still work with astropy. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@embray: traceback isn't defined
|
Thanks for catching those. |
|
@embray - one more issue, I currently get the following traceback: Pyflakes also is warning me about a missing import for |
|
(it also looks like Travis is failing) |
|
The failures on travis are due solely to the SSL thing. |
|
Ok, see #113 for a fix for the SSL |
91bcea6 to
6833443
Compare
|
Should be really, truly fixed by 336997d. And this time I tested building astropy itself too ;) Just goes to show the wealth of open holes in the test suite for this package. |
|
I might actually consider adding a |
|
@embray - if this and astropy/astropy#3166 pass, can I go ahead and merge this PR tomorrow morning, or did you want to do more work on it? |
|
Just adding a changelog entry, then I'll merge. |
…d_packages and loop over all the setup_package modules twice in order to pick up pre-/post-command hooks.
…tate dict for the package cache rather than a normal global variable, so that it can be easily reset at the end of test runs--this was causing some tests to fail depending on the order in which they were run.
…his test restores its previous cwd.
setup_package modules (along with the other get_ functions they can provide. The hooks should be variables in the setup_package module with names like pre_<command_name>_hook. For example to implement a pre-build_ext hook there should be a pre_build_ext_hook defined in setup_package. Every setup_package module can provide hooks, though their run order should not be relied in. In other words, there is no way currently to ensure that hooks defined for the same command are run in a specific order. One can also define a post_<command_name>_hook. This also adds an optional srcdir option to register_commands so that it can be passed through to the find_packages call that register_commands now makes.
|
Ok, 👍 |
6833443 to
54a7285
Compare
|
Rebased once more and added changelog entry. Good to go. |
Add support for pre- and post-command hooks that can be provided by
setup_packagemodules (along with the other get_ functions they can provide.The hooks should be variables in the setup_package module with names like
pre_<command_name>_hook. For example to implement a pre-build_ext hook there should be a pre_build_ext_hook defined insetup_package.Every
setup_packagemodule can provide hooks, though their run order should not be relied in. In other words, there is no way currently to ensure that hooks defined for the same command are run in a specific order. One can also define apost_<command_name>_hook.This also adds an optional srcdir option to register_commands so that it can be passed through to the
find_packagescall thatregister_commandsnow makes.The
pre_<command_name>_hookvariable may either be a callable, or a string specifying the import path for some callable defined elsewhere. The callable must take a single argument, which is theCommandobject for the command being hooked. This provides access to all the command's options.If this is implemented there should probably also be an update to the developer docs to mention this feature. There might be some existing code that can make use of this feature as well, but I haven't looked in-depth yet. I kept this separate from #110 for now, but once that PR is merged I will rebase this on top of it.