Limiting (Remove) pyi_rth_win32comgenpy hook

[arossert]

The purpose of this hook is to fix an issue with old versions of pywin32 with creating the gen_py cache directory in the site-packages, nowadays this is not the case, this hook is always creating the gen_py file even if my app is not using win32com.

So my question is if we can remove this hook or limit the runtime to older versions of pywin32?
Maybe we can add something like

if check_requirement('pywin32 >= ?'):
    _pyi_rthook()
    del _pyi_rthook

(I don't really know if these helper functions are available in runtime hooks, if not we can change it to something else)

I don't mind creating the PR if this solution is acceptable, I have some experience with adding hooks but not runtime hooks 😃

[rokm]

If your app isn't using win32com, wouldn't it be easier to just exclude the module (via --exclude or excludes argument to Analysis) in the first place?

As for the hook... it seems that the change in pywin32 to use temporary directory was done a long time ago (mhammond/pywin32@8fee320), so perhaps we really should remove the hook altogether.

On the other hand, the logic for selection of __gen_path__ still seems to contain paths that might end up favoring the package's directory. So just in case this is still a possibility, we might instead limit the hook by checking whether original win32.__gen_path__ points inside sys._MEIPASS and if it does, relocate it. I think this would more surefire than checking for version (which I'm not sure we can obtain without collecting metadata, and might not be a good criterion if path selection is condition-based rather than version-based).

[rokm]

To be clear, it's these two we never want to be used?

Yeah. I think these two actually amount to the same thing, because if that win32com\gen_py directory existed, win32com.genpy would be a namespace package under contemporary python versions. So even those two codepaths themselves seem to be redundant (likely a left-over from times before PEP420 namespace packages).

There isn't a gen_py directory in the (unfrozen) package so __gen_py__ would as far as I can tell always eventually be set to C:\\users\\brenainn\\Temp\\gen_py\\3.11. In which case, most of that module and our hook working around it is dead code?

Indeed. If __gen_py__ already points to temporary directory, it makes little sense for us to force our ephemeral temporary directory for it (unless we specifically care that frozen applications use isolated, ephemeral temporary directories for that cache).

We can choose between keeping the run-time hook but rendering it mostly no-op (by checking if original __gen_py__ is rooted in sys._MEIPASS), which gives us chance to revert to old behavior in case win32com\gen_py happens to exist for whatever reason.

Or, simply remove the whole thing, and see if anyone complains; and only if they do, investigate that scenario and possibly re-instate the hook.

[bwoodsend]

Removing the whole thing sounds best to me.

[arossert]

@bwoodsend Should I create a PR?

[bwoodsend]

Sure, go for it!

[arossert]

Done
#8313