[Python-Dev] Python for windows.

[Koenig, Gerald]

Hi all,


Yes we spend the time and resources to do those tests.

You do not have to worry about that :) and We will submit to Microsoft instead of you like that you do not have to worry about it. Microsoft is totally fine with it. I already asked them if it was fine.
Unless you do not want us to do it.

We do it for 2 reasons:

        We are trying to have all our systems OEM ready Compliant.

        Second all our customers will not have to worry about it, as it is already passing.

I can promise you Python on our system Python work perfectly. We use it very often as our main scripting/programming tool like some other would use jscript or C#.
We also follow your license agreement to never change anything from the packages.

That why I went to this development board to see if some change can be done to make it OEM ready :)
I didn't want to change anything by myself.

So out of the three issue:

        - The three executable could be change to .dat ?

        - So if I understand well python_icon.exe is only stocking all the icon for python ?

        - I just checked for the version number it is not required expect for the uninstalled key which is already clean.




GErald

-----Original Message-----
From: "Martin v. Löwis" [mailto:martin at v.loewis.de]
Sent: Wednesday, November 26, 2008 2:32 PM
To: mhammond at skippinet.com.au
Cc: Koenig, Gerald; python-dev at python.org
Subject: Re: [Python-Dev] Python for windows.

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

Cleary, "we" (python-dev) would never run any of these test suites; it's
to much effort to buy them, run them, and study the results. So I'm
really glad HP spends the time on that stuff - not because HP needs it,
but because "smaller" users might run into it, and then frustrate
because they can't resolve the issues (rather than contacting us).

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

See my other message. This "obviously" comes from a formal test suite.
So it's not necessary to convince the operator of the test suite that
the test is flawed, but to convince the test suite to look elsewhere.
I think we can do that.

> 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, but if
it makes the test suite happy that python.exe has a manifest, then I'm
happy myself also.

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

Can you please elaborate? What specific elements of the manifest are you
thinking of that are not universally correct for python.exe?

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

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

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

If this list of complaints was complete, I don't find it too difficult
to comply. If a merge module would contain the entire library (including
distutils), then the wininst.exe issue would still exist for the merge
module (for example).

OTOH, if somebody wanted to contribute a procedure that builds merge
modules (in whatever granularity) along with the msi file - that would
also be appreciated.

Regards,
Martin