But these are written with applications in mind - Python isn't an application - its used to *write* applications. I don't see a good reason to support these guidelines. I do see a reason to help support people ensure their Python implemented applications can meet the guidelines, but I'd never advise such people to install the python.org installer and have their application use Python from that directory.
I disagree. While it might not be really necessary for HP to have Python comply to a formal test suite, I'm sure other users do need to pass these test suites for whatever reason, and they are unhappy if they don't pass out of the box.
IIUC, the test suite is about having the Python installer certified as "OEM Ready", which means a few special things - including, IIUC, the "right" to be installed in a new PC. My broader point is that I would advise against any application vendor reusing the standard Python installer for their application, as it exposes the ability for the user to remove it, thereby breaking the application. I would recommend that the application vendor take full control of the Python they rely on and install a "private" copy (either in their own directory or in a directory named other than "Python X.X".) In other words, I'm all for helping application vendors in every way to have their installers meet such guidelines, but I see having the Python installer itself meet such guidelines as effectively pointless as no one would actually need it. Obviously I'm wrong here though - HP obviously *is* wanting to install it as is, and doesn't mind that the user could accidently break their scripts. I'm very surprised by that, but I have to accept it :) On the other hand, I'd really like to ensure they understand the risks and for me to understand why those risks are acceptable...
Ditto for python.exe etc - its impossible to add a reasonable manifest, as the manifest requirements would depend entirely on what the python program itself does. There is no way python.exe can know what it will be asked to do.
FWIW, python.exe *does* have a manifest. The manifest is primarily about static linking. I don't know what other uses a manifest may have,
The issue is regarding the Vista "user access control" flags, but yes, I see that python.exe does include a UAC entry in its manifest. As I mentioned, it will obviously not be approriate for all Python apps, but it is there and that is what matters for this discussion.
Can you please elaborate? What specific elements of the manifest are you thinking of that are not universally correct for python.exe?
A specific Python script may need a different UAC flag to work correctly in all cases - specifically one that requires elevation. If the manifest was appropriate for that script Windows would automatically elevate, but as things stand, the user would need to manually elevate before executing that script.
Perhaps. I wouldn't go so far, though. It's surely puzzling if a system comes with a pre-installed Python, but if that Python actually works, I don't think that does much damage.
Agreed. I'm just surprised app authors are willing to take the risk this implies. I still occasionally get email from people (presumably via my email addy which used to be in Pythonwin) saying "I've got this Python thing installed on my PC - is it a virus? Can I remove it?". I tend to say "itÂ’s a programming language - if you don't know you need it, you probably don't, so sure, uninstall it".
Of course, anybody embedding Python *should* integrate it into his own application and installation procedure. If we really want this guideline to be followed, we should document explicitly how one does that (and no, pointing people to py2exe is not sufficient).
Actually, I don't think its that hard. Just plonk what you need (or *everything* except what you know you don't need, eg docs) in the same directory structure, test, rinse and repeat. Ideally you would also tweak the resource in pythonxx.dll which tells it the registry key to use too. If you had special UAC requirements you might even make a copy of python.exe which is identical except for the manifest, but now we are starting to get into app specific requirements... Cheers, Mark