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: [EMAIL PROTECTED] 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 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. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith J. Farmer Sent: Monday, January 22, 2007 4:34 PM To: Discussion of IronPython Subject: Re: [IronPython] Feedback needed for bug fix: Import pre-compiledmodules """ "import lib" prefers loading lib.exe to lib.py, if neither ironpython.dll nor lib.py is newer than lib.exe. """ So: If lib.py doesn't exist, and lib.exe does, it'll import the exe. If lib.py does exist, it'll load lib.exe if the .exe is newer. (Assuming in both cases that ironpython.dll is older than the exe.) If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? How does this impact the upgraded-ironpython scenario for third-party dlls, or do you recommend sending source code to recompile with? ________________________________ From: [EMAIL PROTECTED] on behalf of Haibo Luo Sent: Mon 1/22/2007 4:13 PM To: users@lists.ironpython.com Subject: [IronPython] Feedback needed for bug fix: Import pre-compiledmodules We recently checked in a fix for codeplex work item# 358 (Implement import of pre-compiled modules <http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=358> ). If possible, please download the source, and try it with your scenarios to see whether it addresses your issue (since many of you voted for this item). Running ipy.exe with existing -X:SaveAssemlies switch saves all .py files to corresponding .exe files. For example, given 2 files, main.py, and lib.py # lib.py x = 10 # main.py import lib print lib.x "ipy.exe -X:SaveAssemblies main.py" will result in the creation of lib.exe and main.exe. Next time you run main.py (no switch necessary), "import lib" prefers loading lib.exe to lib.py, if neither ironpython.dll nor lib.py is newer than lib.exe. This is also supposed to enable the binary deployment: you can copy only exe's (with the package structure) along with ironpython binaries to run your IronPython app. A new switch "-X:NotImportCompiled" is provided to disable such pre-compiled module import. Just a reminder, you can always vote on bugs in codeplex <http://www.codeplex.com/IronPython/WorkItem/List.aspx> . Thanks! _______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
