[Python-Dev] Python for windows.

Koenig, Gerald gerald.koenig at hp.com
Wed Nov 26 23:11:35 CET 2008

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 :)


-----Original Message-----
From: python-dev-bounces+gerald.koenig=hp.com at python.org [mailto:python-dev-bounces+gerald.koenig=hp.com at python.org] On Behalf Of Koenig, Gerald
Sent: Wednesday, November 26, 2008 2:03 PM
To: mhammond at skippinet.com.au; python-dev at 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 :)


-----Original Message-----
From: Mark Hammond [mailto:skippy.hammond at gmail.com] On Behalf Of Mark Hammond
Sent: Wednesday, November 26, 2008 1:59 PM
To: Koenig, Gerald; python-dev at 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

>                 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...



Python-Dev mailing list
Python-Dev at python.org
Unsubscribe: http://mail.python.org/mailman/options/python-dev/gerald.koenig%40hp.com

More information about the Python-Dev mailing list