If it did, I don't think we'd be getting the continuous updates.
Thought some more on the commute. The are a couple problems, overall, when
versioning.
The basic problem I think is avoiding the dll explosion when maintaining
side-by-side versions that are frequently updated. The explosion can happen
either in the GAC or outside of it (ie, in binaries-only deployments). The GAC
is less of an explosion. So, culture-wise, what can we do? I propose for the
sake of hearing myself type that we maintain multiple a.b versions in the GAC,
but only the latest of each (this follows what Microsoft has done, basically):
IronPython 1.0.3.1234
IronPython 1.0.5.5678 replaces 1.0.3.x, bug fix. 1.0.3 apps can be expected to
work correctly under 1.0.5. Correctly doesn't mean identically -- bug fixes
*are* bug fixes.
IronPython 1.1.0.9012 side-by-side with 1.0.x, API change. Assembly
redirection or recompilation of exes can be expected.
We limit the breaking API changes to infrequent drops.
The second problem -- the actual dll hell -- is that in the current CLR, you
cannot reference two different versions of the same (type.. assembly?). For
example, you make a reference to version 2 of foo.dll, and a reference to
bar.dll. Bar.dll makes a reference to the old version 1 foo.dll. Breakage
occurs. The solution to that problem is different, and IMHO not something to
solve independently of the rest of .NET.
________________________________
From: [EMAIL PROTECTED] on behalf of Bill64bits
Sent: Tue 1/23/2007 11:33 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Feedbackneededfor bug fix:Import pre-compiledmodules
When/If IronPython becomes stable won't IronPython.dll just disappear into the
.NET runtime?
----- Original Message -----
From: Keith J. Farmer <mailto:[EMAIL PROTECTED]>
To: Discussion of IronPython <mailto:[email protected]>
Sent: Tuesday, January 23, 2007 1:00 PM
Subject: Re: [IronPython] Feedback neededfor 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
