Hi Mark, See below my answers, We install your installer, for people to use python are the main language script on the system. My team recommend others team to use this as the main scripting languages for different software's, Due to that we use the standard install and people developed their script on the systems. We also leave it on the system for our customer later if they want to use special function of our consumer desktop like application drivers recovery for example. As it is on the system it would need to be passing those requirement for OEM ready because we use python like an application in our case to developed script / programs using your normal installer. This is the main reason we have it on all our system since over 10 years now :) Gerald -----Original Message----- From: python-dev-bounces+gerald.koenig=hp.com@python.org [mailto:python-dev-bounces+gerald.koenig=hp.com@python.org] On Behalf Of Koenig, Gerald Sent: Wednesday, November 26, 2008 2:03 PM To: mhammond@skippinet.com.au; python-dev@python.org Subject: Re: [Python-Dev] Python for windows. Hi Mark, Well we are having a lot of our teams using python are the script languages :) It is not only one team using it That why we use the normal installer :) Gerald -----Original Message----- From: Mark Hammond [mailto:skippy.hammond@gmail.com] On Behalf Of Mark Hammond Sent: Wednesday, November 26, 2008 1:59 PM To: Koenig, Gerald; python-dev@python.org Subject: RE: [Python-Dev] Python for windows.
I completely understand that this is a volunteer organization. That why I am already proposing that HP will submit for your guys after we figure out how to fix the issues if it is possible to fix them of course.
I don't fully understand why it is in HPs interests to install a normal python.dev installer, and have their other bundled software rely on it working forever. IMO it is likely people will not understand the association, and may upgrade or remove the package. Wouldn't it make more sense for HP to treat Python as a "private" tool and bundle it hidden away inside their applications? This is the exact approach many applications written in Python take - I can't think of any commercial applications that rely on the standard installer - think the Python implemented IDEs, the various Zope windows binaries, etc. Or obviously I'm missing some key point :)
The OEM Ready program is: http://msdn.microsoft.com/en- us/windowsvista/cc315067.aspx Personally I am ready to do the job of submitting and testing if you pass all the tests.
You can find some info about all those test here also:
http://www.codeproject.com/KB/vista/Certified_for_Vista.aspx?display=Pr intAll&fid=406261&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26
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. In other words: Python implemented apps should meet the guidelines, but as such apps shouldn't use the standard installer, there is no need for Python itself to meet them.
- Some of the executable deliver in the python package It does not have manifest that is compliant with UAC guidelines.. c:\program files\python\lib\distutils\command\\wininst- 6.0.exe c:\program files\python\lib\distutils\command\\wininst- 7.1.exe c:\program files\python\lib\distutils\command\\wininst- 8.0.exe
These are stubs for installers. It is the installers created from these stubs that need the manifest, as the manifest requirements will differ for each use of the stub. 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.
We could add a manifest manually outside the executable if there is no manifest at all in those.
See above - we don't know ahead of time what an appropriate manifest is. I agree manifests need thought and work for Python, but I'm fairly sure the answer isn't to try and come up with them ahead of time and assume they apply universally.
- This c:\windows\installer\{110eb5c4-e995-4cfb-ab80- a5f315bea9e8}\python_icon.exe do not answers to the Restart Manager Aware
That sounds like something nice to have, but assuming we recommend against using the standard Python installer for 3rd party applications, this is a problem for the application installer, not ours. In other words, I'm sure we'd welcome a fix to this, but I'd still recommend against using our installer anyway!
- Last one is some of your executable do not contain any version numbers inside.
If the binaries don't currently include the python version number, I'd agree that would be a nice addition. Maybe your and others lives would be made easier if the Python MSI installer was split up to support "merge modules"? That way you could roll your own installer that met any guidelines or requirements that mattered to you, while still ensuring you got all the files that the official installer would have installed. I'm hand-waving a little here, but it sounds like we can do more to help *others* meet guidelines for their Python based apps instead of trying and meet it for our installer... Cheers, Mark _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/gerald.koenig%40hp.com