Very well, leaving linux aside, I don't see why this: /win32mount/trunk/PCbuild/ /x64mount/trunk/PCbuild/
Is any different from /winmount/trunk/PCBuild/win32 /winmount/trunk/PCBuild/x64
I don't understand this extraordinary reluctance to add a single extra directory. The windows build process is different from any other build process, so even If all the other platforms live one directory higher, why must windows?
It doesn't need to, and reluctance is not wrt. to the proposed new layout, but wrt. changing the current one. Tons of infrastructure depends on the files having exactly the names that they have now, and being located in exactly the locations where they are currently located. Any change to that, whatever minor, will cause problems to some people. So for the change to be made, the advantages must clearly outweigh the incompatibility of the change in the first place.
I say let's just admit that tools can compile for more than one target. Let's adapt to it and we will all be happier. You might be; I will be sad. It comes for a price, I well understand the benefits, I use it all the time, but the price still eludes me. how can a different name for the output folder for a different platform be such a big problem?
When running Python now, I type (after having changed to the source directory in the cmd.exe window) PCb<tab>pyt<tab><tab> or some such. To navigate to a subdirectory, I need many more keystrokes. I find it very painful to invoke python.exe from the PCbuild8 directory. I don't want that pain to be the default.
Yes, that is correct. Well, there is a CRT .exe redist if you want to deploy this into the SxS cache, it just has to be run as part of the install process. But that may or may not be problematic, I don't know.
Microsoft recommends to use the merge module (.msm), and I think this is what should be done (if feasible).
Why should there be versioning problems with python25.dll? Are there any past issues with incompatibilities with any python2x.dll release? Someone could replace the python25.dll that we ship with their own patched version, thereby gaining backdoor access to the software. The way windows searches for old style dlls makes this easy. Using the SxS signed loading scheme, you can protect yourself up to a point from such attacks. Of course, this doesn't have to be a problem for vanilla python, we can do this on our own for the patched python25 that we employ, but it still might be something others could find useful.
I personally think that if hostile users can replace DLLs on your system, you have bigger problems than SxS installation of pythhonxy.dll, but perhaps that's just me.
Install in the ProgramFiles folder. Only over my dead body. *This* is silly. Bill doesn't think so. And he gets to decide.
He can decide not to give Python the "Vista ready" logo. If so, I don't want it. He cannot decide to make the Python installer to install into a directory with a space in its name by default.
I mean we do want to play nice, don't we?
Nice to users of Python, sure. I would not have said a word if the standard directory would have been, say "\usr\bin". However, they happened to chose "Program Files", making it language dependent, and putting a space in the name. That space has caused numerous problems to Python scripts, and I expect changing the default would cause a lot of problems to end users.
What about the registry? I don't know about the registry, what is it used for?
For two things, with different importance to different users: 1. File extensions are registered there, e.g. .py and .pyc. With two binaries installed, the will stomp over each other's file associations; only one of them can win. 2. Python installs keys under HL{LM|CU}\Software\Python\PythonCore\<version>, namely InstallPath InstallGroup PythonPath Documentation Modules For some of these, add-on libraries and applications may modify these keys, and the interpreter will pick up the changes. Again, there can be only one installation on the system "owning" these settings; two simultaneous installations will stomp on each other's settings.
64 bit windows already ships with dual versions of some apps, notably explorer.exe so that shouldn't be a big problem.
The two versions of MSIE actually *are* a big problem, that's why MS only runs the 32-bit IE, even on Win64 (otherwise, ActiveX controls downloaded from the net wouldn't work). Also, while they are both shipped, you can't the two versions of explorer.exe simultaneously (without trickery), so its far from simple.
But that's not a problem, is it? Writing silently "fails", i.e. it just won't save the pyc files. Happens all the time on Unix. It may not silently fail, depending on your user status. An admin might get a confirmation window, for example.
Can you describe the precise scenario which makes that happen? To my knowledge, Vista will *not* open a confirmation window when Python attempts to write a .pyc file. Regards, Martin