[Python-Dev] Python for windows.

["Martin v. Löwis"]

> 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