[IronPython] Feedbackneeded for bug fix:Import pre-compiledmodules
Michael Foord
fuzzyman at voidspace.org.uk
Wed Jan 24 15:34:47 CET 2007
On Jan 24, 5:30 am, "Keith J. Farmer" <kfar... at thuban.org> wrote:
> It's not what I assumed. Most .NET applications in my experience
don't package the framework when they're distributed. In fact, I tend
to feel offended when I find an app has packaged the entire runtime it
needs and included it in the install. Zope really annoyed me in this
way, and don't get me started on the Starry Night updater -- it packages
all of Java and that's not even for the main application. It means
wasted space for me, as well as multiple versions lying about. It's a
reinforcement of the old dll hell when people are hard at work trying to
put it to rest.
>
Distributing IronPython DLLs isn't quite analagous to distributing the
'whole framework'.
Also, compiled executables have to have *some* dependency on the version
of IronPython they were compiled for. Imagine if you have an executable
compiled for IronPython 1.2 and the user has IronPython 1.1 in the GAC
or somewhere else in their path. Surely *that's* DLL hell.
Having a very strict dependency on version requires you to distribute
the DLLs and recompile when you upgrade your Python version, *but* it
reduces that kind of DLL hell.
A globally installed IronPython is cool, having it a packaged part of
the .NET framework is cooler - but won't that stop the kind of rapid
development that the IronPython team have been doing ? After all they've
been pushing out new versions every few weeks, which they couldn't
really do if each version change had big ramifications for third party
developers (us).
Being only dependent on which version we choose to use, rather than
whichever version the user has installed, seems like a better situation
to me.
> There should be a better means for cooperation between third party
apps and the runtime as regards version. I don't make the claim that
it's an easy problem to solve, but the solution shouldn't be at odds
with the native support, nor should it put a burden on the end-user.
>
> My ideal, for example, would be to have IronPython-on-Windows
included as a component via Microsoft Update, and serviced through those
channels. This would mean, then, that IronPython apps would have to be
safe against revisions. Perhaps under Vista.
>
Its finding a way to make apps safe against revisions that is difficult.
If the only solution is for the IronPython team to keep backwards
compatible with previous releases it might lead to the sources and the
binaries growing a horrible amount of cruft.
I don't see the downside of having to distribute DLLs with applications
(and having a strong name dependency) in quite the same way you do, but
if a solution can be found... great.
Michael
http://www.voidspace.org.uk/python/articles.shtml
>
> My ideal, for example, would be to have IronPython-on-Windows included as a component via Microsoft Update, and serviced through those channels. This would mean, then, that IronPython apps would have to be safe against revisions. Perhaps under Vista.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Tuesday, January 23, 2007 3:26 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython]Feedbackneeded for bug fix:Import pre-compiledmodules
>
> Keith J. Farmer wrote:
>
>> I was just latching myself onto the shipping-binaries-only blurb in the original email. :)
>>
>> My personal biases are against shipping source code, if for no other reason than it avoids the problems of office-chair programmers modifying code they don't actually understand. That, and the deployment tends to feel, well, cleaner.
>>
>> I don't think that -- as incredibly intelligent as she is -- we can expect my retired english teacher to understand how versioning works. She'll expect it to just work, modulo installing the latest IronPython, which may be newer than the exe.
>>
>> (Interesting feature to add to the exe -- option to include a way to automatically download and install the required version of IronPython...)
>>
>>
>>
> Why not distribute the required dlls with your application ? Isn't it
> assumed that this is what most IronPython applications will do ?
>
> Michael Foord
> http://www.voidspace.org.uk/ironpython/index.shtml
>
>
>>
>>
>> ________________________________
>>
>> From: users-bounces at lists.ironpython.com on behalf of Dino Viehland
>> Sent: Tue 1/23/2007 12:00 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Feedbackneeded for bug fix:Import pre-compiledmodules
>>
>>
>>
>>
>> One interesting question is why are people interested in this feature? Is it primarily for the improved performance that loading the cached DLL gives or is it for enabling the shipping of binary-only EXEs that run against arbitrary versions of IronPython.dll? It'd be interesting to see what most people want out of this feature to gauge how we should evolve this and the level of compatibility we should maintain between versions.
>>
>>
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer
>> Sent: Tuesday, January 23, 2007 11:01 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules
>>
>> I could be wrong (I certainly have been in the past), but the current scheme seems to pre-empt the built-in mechanisms.
>>
>> There are several ways you can get a reference to an assembly -- file name, name space without strong name, name space and version, name space and public key, etc. This works well enough for most (not all) purposes. If you want .NET to load the most recent version of an assembly, you just need to ask for it. If you require a certain version, or culture, you can ask for those as well.
>>
>> Consider an addin approach, where the IronPython.dll is the addin rather than a compile-time reference. If you did that, then the exe could have a bootstrapper that merely asks for the runtime without specifying strong names. It loads IronPython, potentially obeying any of the standard redirection declarations in exe.config. The exe then casts the IP runtime to IIronPython_1_0_1, and starts calling methods.
>>
>> In versioning IronPython, if a breaking change needs to happen, we can use explicit interfaces:
>>
>> public int IIronPython_1_0_0.Add(int x, int y) { return x + y + 0.1; }
>> public int IIronPython_1_0_1.Add(int x, int y) { return x + y; // bug fix }
>>
>> .. I'm just doing this off the top of my head at the moment, but I think it'd at least alleviate some of the problem.
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill
>> Sent: Tuesday, January 23, 2007 7:22 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules
>>
>> I'm not arguing with you -- just playing devil's advocate. Isn't "everyone has to use the same centrally maintained copy of a DLL" the recipe for "DLL hell" that .Net is supposed to let us avoid? In the specific scenario you provide -- you update a DLL used by an existing EXE -- .Net is designed to keep using the old version of the DLL unless you either re-compile to re-build the EXE, or add an entry to the EXE's .config file that tells it that it's ok to use the newer one. (That only applies for DLLs in the GAC, as I understand it.)
>>
>> .Net isn't supposed to load app X that references DLL Y unless the "identity" of Y is the identity listed in the manifest for app X. Changing the identity of a DLL can be done by changing its version number; unfortunately, unless the DLL is installed in the GAC, you can't have two copies of the same DLL differing only in their version and have "the right one" (the one referenced by the EXE, or pointed to by the EXE's config file) load.
>>
>> Sigh.
>>
>> At 12:38 AM 1/23/2007, Keith J. Farmer wrote
>>
>>
>>> Why do you assume the deployment will involve dropping IronPython in the application directory? Sure, you *could*, but it's unreasonable, I think, to force the end user to have Yet Another Copy of a dll when it could just reference the latest-and-greatest at a central location.
>>>
>>> The situation I see is:
>>>
>>> Install IronPython.
>>> Install a binaries-only IP app.
>>> Update IronPython to change a spelling error in a resource -- suddenly the app doesn't even load.
>>>
>>> So, for binaries-only, the situation's just plain broken. Granted, I'd wager that most Python is distributed with source (if not as source).
>>>
>>> Another alternative? Use explicit interfaces in the IronPython runtime to allow side-by-side versioning of the API. The exe's bootstrapper can load IronPython.dll without using the strong name, grab the runtime, cast to that interface and deal with versioning issues for some period of time before obsoletion. This would also allow developers to switch compatibility levels when testing their programs.
>>>
>>> -----Original Message-----
>>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill
>>> Sent: Monday, January 22, 2007 8:03 PM
>>> To: Discussion of IronPython
>>> Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules
>>>
>>> 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
>>>
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>> J. Merrill / Analytical Software Corp
>>
>>
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
More information about the Ironpython-users
mailing list