[Python-Dev] Python for windows.

[Koenig, Gerald]

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