Problem Python 2.6.1 vs 2.6 & pyWin32

[Guest]

Hi, all!

I have several softwares using Python+PyWin32, often as COMèserver. Ok
with Python 2.5.x. I want migrate to Python 2.6.
But when I install python-2.6.1.msi + pywin32-212.win32-py2.6, my softs
don't run.
Tried on five machines (two XP & three Vista).

But... if I install python-2.6.msi , IT'S OK!!!

And, if I installl 2.6.1 once again, after 2.6, ... don't run ???!!!
;-(((

In reality, soft run, but COM server can not be used. I get these
messages :

File "C:\Python26\Lib\site-packages\win32com\server\policy.py", line
728, in resolve_func
module = _import_module(mname)
File "C:\Python26\Lib\site-packages\win32com\server\policy.py", line
747, in _import_module
__import__(mname)
File "C:\Ponx\ponx.py", line 54, in <module>
import socket
File "C:\Python26\lib\socket.py", line 46, in <module>
import _socket
<type 'exceptions.ImportError'>: DLL load failed: Le module spécifié est
introuvable.


"Erreur non spécifiée" (with call from JScript test, or VBScript test).
(These tests run OK with 2.6 or 2.5.x)


I am very disappointed. Help me, please.
Thanks in advance.

*** and sorry for my bad english ***


@-salutations

 

[Martin v. Löwis]

I am very disappointed. Help me, please.

Try installing Python 2.6.1 "for all users".

Regards,
Martin

 

[Pekka Klärck]

Try installing Python 2.6.1 "for all users".

Could you clarify why that's needed? Link to a relevant bug report or
something similar is enough. We've got some weird problems installing
Python packages (win32.exe) on Windows with Python 2.6 and would like
to know are these problems related.

One thing we noticed (I'm not sure has this been yet submitted to
bugs.python.org yet) was that installing packages created with Python
2.5 to Python 2.6 failed unless Python was in %PATH% [1]. Even then
output printed by postinstall scripts wasn't visible in the installer.
Another pretty severe problem was that installers created with Python
2.6 didn't work at all with older versions [2].

[1] http://code.google.com/p/robotframework/issues/detail?id=150
[2] http://code.google.com/p/robotframework/issues/detail?id=163

Cheers,
.peke

 

[Martin v. Löwis]

Try installing Python 2.6.1 "for all users".

Could you clarify why that's needed?

I didn't say it's needed. I said that he should try that, perhaps it
helps.

One thing we noticed (I'm not sure has this been yet submitted to
bugs.python.org yet) was that installing packages created with Python
2.5 to Python 2.6 failed unless Python was in %PATH% [1].

In general, that's not supported at all. You will have to rebuild all
packages for Python 2.6, unless they are pure-python packages (in
which case PATH should be irrelevant).

If the .pyd files would have loaded, Python would have complained that
they originate from the wrong Python version.

Another pretty severe problem was that installers created with Python
2.6 didn't work at all with older versions [2].

That's not a bug, either. It has been that way since Python 1.4 or so:
..pyd files built for X.Y won't work for X.(Y+1), and vice versa.

It seems that you mean something specific with the word "installer";
I think you should elaborate what precisely you are referring to.

Regards,
Martin

 

[Guest]

Hi!

Thank you very much for your answer. I appreciate many to receive an
answer of somebody as you.

But I, always, install Python 2.6.1 "for all users" (and, on Vista, UAC
is always deactivated).

After some tests, the problem seems a bit more complex: call the
Python-COM-servers run OK, from Python-Scripts. But it is not possible
from others languages (but, I only try JScript, VBScript, JS.Net,
ObjectPAL, Autoit).

For the moment, I back my install procedures to Python 2.6 ; and, I hope
a "global" solution for 2.6.1

@-salutations

 

[Guest]

Hi!

I noted, also, than, in some cases, Python26.dll is not copied in
%WINDIR%\system32
After that, external softs don't find the DLL.
But it's a detail, because it's easy to copy the DLL with install
scripts.

@-salutations

 

[Martin v. Löwis]

I noted, also, than, in some cases, Python26.dll is not copied in

%WINDIR%\system32
After that, external softs don't find the DLL.

Right. Only in "for all users" installations, python26.dll is put into
system32. In a "just for me" installation, the user is not expected to
have permissions to system32, hence the DLL is put into c:\python26.

Regards,
Martin

 

[Pekka Klärck]

Could you clarify why that's needed?

I didn't say it's needed. I said that he should try that, perhaps it
helps.

One thing we noticed (I'm not sure has this been yet submitted to
bugs.python.org yet) was that installing packages created with Python
2.5 to Python 2.6 failed unless Python was in %PATH% [1].

This must have actually been caused by the Python26.dll not being in
PATH. Unfortunately I don't have all the details since these problems
didn't bite me personally, but I assume this has been a single user
installation.

In general, that's not supported at all. You will have to rebuild all
packages for Python 2.6, unless they are pure-python packages (in
which case PATH should be irrelevant).

If the .pyd files would have loaded, Python would have complained that
they originate from the wrong Python version.

The question was about a pure-python package. Based on my very limited
knowledge on .pyd files they aren't related to the problem.

Another pretty severe problem was that installers created with Python
2.6 didn't work at all with older versions [2].

That's not a bug, either. It has been that way since Python 1.4 or so:
.pyd files built for X.Y won't work for X.(Y+1), and vice versa.

It seems that you mean something specific with the word "installer";
I think you should elaborate what precisely you are referring to.

Sorry for not being explicit. With "installer" I meant the binary
Windows installer you create with command "python setup.py
bdist_wininst". In the past we've been able to use
"package-version.win32.exe" files created with Python 2.5 on older
version, but that doesn't seem to be case with 2.6.

Cheers,
.peke

 

[Martin v. Löwis]

Sorry for not being explicit. With "installer" I meant the binary

Windows installer you create with command "python setup.py
bdist_wininst". In the past we've been able to use
"package-version.win32.exe" files created with Python 2.5 on older
version, but that doesn't seem to be case with 2.6.

I see. This has nothing to do with the OP's question, then.

For Python 2.6, we switched to VS 2008. Apparently, the bdist_msi
installers now get linked with the VS 2008 CRT (msvcr90.dll), which
must be present on the system (in WinSxS) for the installer to run;
one way of installing the CRT is to install Python for all users,
another is to install it "just for me", and put \python26 into PATH
(so that the installer can find msvcr90.dll).

Regards,
Martin

 

[John Machin]

I see. This has nothing to do with the OP's question, then.

For Python 2.6, we switched to VS 2008. Apparently, the bdist_msi
installers now get linked with the VS 2008 CRT (msvcr90.dll), which
must be present on the system (in WinSxS) for the installer to run;
one way of installing the CRT is to install Python for all users,
another is to install it "just for me", and put \python26 into PATH
(so that the installer can find msvcr90.dll).

Hi Martin,

Unfortunately this solution can't be used where the user is not permitted to
upgrade Python to 2.6 or where there appears to be an incompatible version of
msvcr90.dll in C:\windows\winsxs.

For example a user with no admin privileges on his work PC and stuck with Python
2.4.2 on Windows XP SP2 (not SP3) has the following problem when trying to run a
bdist_wininst .exe that was created for a pure-Python package using Python 2.6.1:
"""
the error message is the same as stated in this article:
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/xp-wont-run.html
"""
presumably (given his locale) the German version of the error message, complete
with MS misspelling.

It would appear that the safest cover-most-bases option for a developer/packager
of pure-Python packages (especially one intended to be runnable on older
versions of Python, some as far back as 2.1) is to use Python 2.5 to make the
bdist_wininst (the exe is linked against msvcr71.dll which is widely available
and doesn't have SxS problems). Do you agree? If so, where is the best place to
propagate this advice?

Cheers,
John

 

[Mark Hammond]

It would appear that the safest cover-most-bases option for a developer/packager
of pure-Python packages (especially one intended to be runnable on older
versions of Python, some as far back as 2.1) is to use Python 2.5 to make the
bdist_wininst (the exe is linked against msvcr71.dll which is widely available
and doesn't have SxS problems).

Hi John,

Note that fairly recently (IIRC, 2.6.2/3.1), the bdist_wininst stub
installers moved to linking the CRT statically, so should avoid this
problem. Indeed, if you use the correct magic, you should be able to
use this version of distutils to build binaries for much earlier
versions of Python and to allow the installer itself for that version to
avoid depending on any msvcrt...

Cheers,

Mark

 

[John Machin]

Hi John,

Note that fairly recently (IIRC, 2.6.2/3.1), the bdist_wininst stub
installers moved to linking the CRT statically, so should avoid this
problem.

Hi Mark,

Indeed, if you use the correct magic, you should be able to
use this version of distutils to build binaries for much earlier
versions of Python and to allow the installer itself for that version to
avoid depending on any msvcrt...

This all sounds good. I presume that "this version of distutils" means
the 2.6.2/3.1 version.

In the meantime, until 2.6.2 final is released, is my suggestion of
using Python 2.5 to build installers reasonable? Is there a better
approach?

BTW, the user with the problem has not only confirmed that he did indeed
receive the misspelled German version of the error message but
also has successfully installed the package using a 2.5-built installer
that I provided. It's curious that out of over 250 downloads of the
2.6-built installer, there's been only 1 report of the installer not
working. Comments?

Cheers,
John

 

[Mark Hammond]

This all sounds good. I presume that "this version of distutils" means
the 2.6.2/3.1 version.
Yep.


In the meantime, until 2.6.2 final is released, is my suggestion of
using Python 2.5 to build installers reasonable?
Yep.

Is there a better approach?

Not that I'm aware of - hence the fixing of the installer to avoid the
crt completely.

BTW, the user with the problem has not only confirmed that he did indeed
receive the misspelled German version of the error message but also
has successfully installed the package using a 2.5-built installer that
I provided. It's curious that out of over 250 downloads of the 2.6-built
installer, there's been only 1 report of the installer not working.

IIRC, the installer would work OK if a 'public' or shared copy of the vc
runtime was installed - but it would seem unusual that 249 out of 250
people would have that...

Cheers,

Mark

 

[John Machin]

Not that I'm aware of - hence the fixing of the installer to avoid the
crt completely.


IIRC, the installer would work OK if a 'public' or shared copy of the vc
runtime was installed - but it would seem unusual that 249 out of 250
people would have that...

Hi again, Mark,

If your recollection is correct, with the implication that a significant
proportion of installers made by 2.6.1? 2.6.0? 2.6.any? (which?) would
fail, then given the numbers of windows installers being produced, I
would have expected a lot more visibility for this problem.

I have just replaced the 2.6.1-made exes on PyPI with 2.5.4-made exes
for two packages: xlrd (the one in question above) had 282 downloads
since 11 March, and xlwt had 231 downloads since 4 March.

So that's 512 out of 513 which have what characteristic? I suggest that
the main common factor is that no problem was reported. In fact I only
found out about this problem because my OP was asking some other
question and I suggested he used the latest version and his response was
that he had tried that first and got the infamous message -- his
workaround was to download the wininst exe for an old version :-0 ...
perhaps others have done the same or used the zip sdist.

Cheers,
John