> 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/archive%40mail-archive.com
