[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

Reply via email to