Hooks skimage fix

[ryandeon]

starting skimage 0.20, I believe, many things are lazy-loaded. To get my project with skimage to work with pyinstaller, I had to upgrade lazy_loader -> 0.2 and include this hook file. hook file created by reading scikit-image/scikit-image#6772 (comment) and guessing.

Tests did not run for me. There is already a test_skimage in the suite, but pytest -k 'test_skimage' would either deselect all tests or (if I removed some decorators in front of test_skimage) run the function with a bunch of parameters that are not listed in the parametrize mark. I haven't used pytest before, so maybe someone else can figure it out.

[rokm]

Hmmm, while this undoubtedly sorts out all the problems with missing modules and data files, I would prefer to take a more fine-grained approach and not brute-force collect everything.

At a quick glance, the lazy_loader is used by skimage.data and skimage.filters (as well as in skimage itself, but it should be less problematic there except for having to collect the .pyi file). And there's new data that needs to be collected by skimage.morphology.

[ryandeon]

I definitely understand wanting to avoid overkill. I have some reasons for it, one bad and ...well, you can judge the others.
bad one: I didn't know which submodules might be lazy_loaded or not, I haven't really peered into the internals of skimage.
reason 2) if the hook targets just the ones that are currently lazy_loaded, I imagine that with each version, as skimage updates more submodules, they will convert more and more to using this new way. So the hook will have to be updated in lockstep. I don't actually know what their roadmap is, I'm just being pessimistic about it.
reason 3) I didn't find it added much to the overall build time in pyinstaller. If there are other reasons than wasted time to avoid this kind of overkill, let me know.

[ryandeon]

that being said, if you'd still prefer I pare it down to just the imports you mention, I can probably do that without a ton more effort.

[rokm]

I definitely understand wanting to avoid overkill. I have some reasons for it, one bad and ...well, you can judge the others. bad one: I didn't know which submodules might be lazy_loaded or not, I haven't really peered into the internals of skimage.

Yeah, that's fair, and totally fine when you're working around the issue in your application. For hooks that we supply, though, I prefer informed decisions, which sometimes require digging into packages' internals.

reason 2) if the hook targets just the ones that are currently lazy_loaded, I imagine that with each version, as skimage updates more submodules, they will convert more and more to using this new way. So the hook will have to be updated in lockstep. I don't actually know what their roadmap is, I'm just being pessimistic about it.

True, and this is a perennial problem. Not just with lazy-loading, but also with cythonized extensions (from which we cannot infer imports).

reason 3) I didn't find it added much to the overall build time in pyinstaller. If there are other reasons than wasted time to avoid this kind of overkill, let me know.

The primary reason is not so much the build time (after all, a single brute-force collect might have less overhead than checking for versions and performing fine-grained collection in individual hooks), but rather the build size. Which covers both unnecessary modules as well as unnecessary data files.

that being said, if you'd still prefer I pare it down to just the imports you mention, I can probably do that without a ton more effort.

I'll prepare my version of PR with fine-grained changes to supersede this one, but I'd ask to you test it with your application, to ensure that I haven't missed anything (that's not covered by the basic import tests).

[ryandeon]

I just tested your changes, and they worked in my project. Thanks for taking this on!