[IronPython] Feedback needed for bug fix:Import pre-compiledmodules

[J. Merrill]

Could IP just ignore the timestamp on ironpython.dll and let the .Net runtime figure out if there are any references to no-longer-present mechanisms within the binary?

Keith, is it really the case that your clients without Python source are going to download new versions of IP and (this is important) put them in the directory with your software?  That is, assuming that you put IP.DLL in the directory with the EXEs/DLLs you built, even if they're doing their own IP development elsewhere on the machine and updating it regularly, won't your executables use the old IP.DLL until you give them the new one (and presumably matching recompiled EXEs/DLLs)?

At 09:24 PM 1/22/2007, Keith J. Farmer wrote
>the upgraded-ironpython scenario
>
>>>> I do not think this is supported. The pre-compiled module has much dependency on IronPython.dll. Some emitted calls in those modules could be changed (or removed) in the next version of IronPython.dll.
>
> 
>That makes me itch...  I understand runtime dependencies, but the binaries-only deployment scenario just dropped in value if they are completely invalidated because the runtime undergoes a minor rev (or is otherwise touched).
> 
>Would it be possible for the runtime to query the assembly to determine if it's compatible or not?  Some sort of poor man's static analysis (eg, a manifest of API dependencies could be generated when the assembly is stored to disk, and if the runtime doesn't find any in the list that match any breaking change from the producing version, it accepts it).
> 
>
>________________________________
>
>From: users-bounces at lists.ironpython.com on behalf of Haibo Luo
>Sent: Mon 1/22/2007 4:44 PM
>To: Discussion of IronPython
>Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules
>
>
>
>If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? 
>
>>>> Yes
>
>[snip]


J. Merrill / Analytical Software Corp