Actually, your further explanation makes sense and I'm happy enough
with what you have written now. The further refinement I suggested is
not needed. Thanks for taking the time to work this through with me,
though.
Anthony
On Mon, Sep 22, 2008 at 12:49 AM, Thomas Heller <[EMAIL PROTECTED]> wrote:
> [Resending, the first answer seemed to get lost somewhere]
>
> Anthony Tuininga schrieb:
>> > On Thu, Sep 18, 2008 at 10:44 AM, Thomas Heller <[EMAIL PROTECTED]> wrote:
>>> >> Thomas Heller schrieb:
>>>> >>> Here's the next idea that I have for the version checking: Version
>>>> >>> check inside
>>>> >>> the generated modules, but using code outside:
>>>> >>>
>>>> >>> So, inside the generated module:
>>>> >>>
>>>> >>> '''
>>>> >>> from comtypes import check_wrapper_version
>>>> >>> check_wrapper_version('42')
>>>> >>> '''
>>>> >>>
>>>> >>> comtypes.check_wrapper_version() would compare against the code
>>>> >>> generator version,
>>>> >>> and in the simplest case raise an ImportError("version mismatch"). In
>>>> >>> a more
>>>> >>> sophisticated implementation it could regenerate and reload the module.
>>>> >>>
>>> >>
>>> >> I have implemented this now; the code simply compares the actual and the
>>> >> required
>>> >> version and raises an ImportError if they are unequal.
>> >
>> > Looks good.
>> >
>>> >> Also I must admit that I have reintroduced the os.stat() calls on the
>>> >> typelib files
>>> >> and the generated module files, this is too damn convenient for me. The
>>> >> code is much
>>> >> simpler now, and if the generated module's timestamp is less than the
>>> >> typelib's timestamp
>>> >> an ImportError is also raised. If any of the os.stat() calls fail then
>>> >> the import succeeds.
>> >
>> > Hmm, you have added a "coder generator" version inside the generated
>> > module. Perhaps you could also add the "type library timestamp" inside
>> > the generated module as well and compare that with the os.stat() on
>> > the type library? The type library file should always exist, right?
>> > Its the module that may not exist or rather be buried inside a zip
>> > file. If you put the type library timestamp inside the generated
>> > module that would work in both the "script" and "frozen" situations.
>> > What do you think of that concept?
>
> To be honest, the current code does *exactly* what I want:
>
> """
> def _check_version(actual):
> from comtypes.tools.codegenerator import version as required
> if actual != required:
> raise ImportError("Wrong version")
> if not hasattr(sys, "frozen"):
> g = sys._getframe(1).f_globals
> mod_path = g.get("__file__")
> tlb_path = g.get("typelib_path")
> try:
> mod_mtime = os.stat(mod_path).st_mtime
> tlib_mtime = os.stat(tlb_path).st_mtime
> except (WindowsError, TypeError):
> return
> if mod_mtime < tlib_mtime:
> raise ImportError("Typelib newer than module")
> """
>
> On the development machine, the code running as Python script,
> 'hasattr(sys, "frozen")' is False, and the timestamps are checked.
> Regenerating a module
> because a typelib has been recompiled from idl - even if the version number
> has not changed -
> is what I want; this makes sure that the generated code is correct.
>
> On the end user machine my code runs from within py2exe, 'hasattr(sys,
> "frozen")' is True,
> and I do not want to regenerate the code because I trust the typelib version
> number in this
> case. The generated modules bundled within the executable should be used in
> this case.
>
> There are probably other possible ways to distinguish a developer and an
> end-user machine,
> if they are preferred.
>
>>> >> I wonder if there should be a way in comtypes to enable/disable this
>>> >> timestamp check?
>>> >> Currently I've enabled this code only when a script is run, in other
>>> >> words only when
>>> >> hasattr(sys, "frozen") is False.
>> >
>
> I was thinking of having a config variable in comtypes\__init__.py so that
> users (like you?)
> who would like to avoid the os.stat() calls, and who do not compile
> typelibaries themselves,
> would be able to skip this check completely by changing this variable. Maybe
> by editing
> a comtypes.cfg file somewhere, maybe programmatically.
>
> -- Thanks, Thomas
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> comtypes-users mailing list
> comtypes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/comtypes-users
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
comtypes-users mailing list
comtypes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/comtypes-users
