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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [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 >>>>>> >>> [snip] >>> >> J. Merrill / Analytical Software Corp >> >> >> _______________________________________________ >> users mailing list >> [email protected] >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> _______________________________________________ >> users mailing list >> [email protected] >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > > J. Merrill / Analytical Software Corp > > > _______________________________________________ > users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
