On Dec 28, 2007 6:41 AM, Ross Ridge <[EMAIL PROTECTED]> wrote: > Ross Ridge writes: > > As I said before, I know how futile it is to argue that Python should > > change it's behaviour. I'm not going to waste my time telling you what > > to do. If you really want to know how side-by-side installation works, > > you can try reading the Windows SDK documentation. > > <[EMAIL PROTECTED]> wrote: > > I did, and determined that it's not possible. We would have to use > > assembly manifests, and can't, as the tool chain doesn't support them. > > Your choice to use a tool chain that doesn't support side-by-side > assemblies does not make it impossible. >
It's worth pointing out that when the choice was made,Windows didn't support SxS at all and there was no toolchain for it. > >> No, simply by changing the name you've prevented backwards compatiblity > >> with the old DLL. > > > >First, the requirement for backwards compatibility is not normative. > >Section 2.6 is entitled "Install any shared files that are not > >side-by-side to the correct locations". python25.dll, as a matter of > >fact, *is* a shared file that is not side-by-side; the *only* location > >I can install in according to 2.6 is the System folder. > > No, the only thing that the guidelines require to be installed in the > system directory are services and drivers. The only exception for other > kinds of applications is when necessary for backwards compatibility. > You're not reading the document correctly. The "backwards compatability" is supporting non SxS libraries. > >> You can't argue you're trying to maintain backwards > >> compatibilty with an old DLL when you've already broken compatibility > >> with it. > > > >Furthermore, it says "to ensure backward compatibility with those > >applications", not "to ensure backward compatibility with the old DLL". > > Now you're just trying play pointless semantic games. If you change > the DLL's name, the DLL is no longer compatibile with those applications. > Python 2.5 already exists and has shipped. > >> Since the existing applications have to be rebuilt to use the > >> new DLL they also can be changed to use it from a new shared location. > > > >No, they can't, because there is not enough manpower available to change > >them. > > And that's what this all really comes down to. Because neither you nor > anyone else is willing to do the work necessary to do the "Right Thing", > you have chosen not to follow Microsoft's recommended best practices > for installing Windows applications. It's not because it's impossible, > it's because you're unwilling. > You're persisting in calling Python an "application", which it clearly isn't. How relevant these guidelines are at all, since they're targeted toward end-user boxed software and not toward developers of third party libraries, is questionable, but lets see what it says. Section 2.6 *clearly* states that non side by side dlls (which Python is) can (and, in fact *must*) be placed in the System directory. Note that making your libraries SxS is *not* a requirement. So if we're going to follow this (questionable) document at all, Python is absolutely compliant. -- http://mail.python.org/mailman/listinfo/python-list
