The win32com.gen_py directory now defaults to under site.getusersitepackages

[mhammond]

(fixes #1666)

@kxrob WDYT?

[kxrob]

Just had a quick look so far, didn't test or fully overlook the further effects (only little time ATM for some days) :

The __gen_path__ seems to be pre-choosen as a single location (of 4) - which may still be write blocked (or makedirs already failed) when needed? In case, is there a fallback necessary at write time (-> usersite -> TEMP )? Or the user has to live with a final error?

[mhammond]

Or the user has to live with a final error?

Yeah, the user has to live with the error, which I think is OK. It's not clear that only handling explicit "no permission" errors would catch everything that might happen, and certainly catching all write errors isn't going to do the right thing. We can always adjust if we get feedback that it should be further improved.

[kxrob]

So far it was possible to pre-freeze / zip and use typelibs like this, to avoid / limit code generations at binary user site,
e.g. with py2exe options: includes="win32com.gen_py.C866CA3A-32F7-11D2-9602-00C04F8EE628x0x5x4"
( compare / test __import__('win32com.gen_py.C866CA3A-32F7-11D2-9602-00C04F8EE628x0x5x4') )

1 . Is this still possible? 2. while other generations still can happen principally?

[mhammond]

So far it was possible to pre-freeze / zip and use typelibs like this, to avoid / limit code generations at binary user site,
e.g. with py2exe options: includes="win32com.gen_py.C866CA3A-32F7-11D2-9602-00C04F8EE628x0x5x4"
( compare / test __import__('win32com.gen_py.C866CA3A-32F7-11D2-9602-00C04F8EE628x0x5x4') )

1 . Is this still possible?

I think so - I haven't actually prevented any of the "old" schemes working, just changed the new default which is only used if the previously supported schemes don't exist.

2. while other generations still can happen principally?

Sorry, but I don't understand this question.

[kxrob]

I haven't actually prevented any of the "old" schemes working, just changed the new default which is only used if the previously supported schemes don't exist.

The import win32com.gen_py is now missing and, not using the import mechanisms, with a zip (the isdir() fails and) gen_py may always become the artifical gen_py = types.ModuleType("win32com.gen_py") before there is a chance to import the frozen modules.
But didn't try that so far. (In a while I may do a 2to3 of a prog & freeze which uses that.)

---

When there is an existing win32com/gen_py detected in admin-only-write install location, and python run as simple user does the current method still fail when new gen's have to be written.?
Similary - in the frozen case (when working again) and new gen's?

---

Maybe a way to get all these and other potential problems solved: When win32com.gen_py becomes simply an ordinary installed package (win32com/gen_py/__init__.py) , even if empty in most future default cases, and the __gen_path__ would simply be added to its .__path__ (inserted as 1st ) when different, all this may work more seamlessly and without the ModuleType() hack, allow freezing / zip import machinery and other (pre-)installation / distribution / admin options ?