Python 2.4 killing commercial Windows Python development ?

[Michael Kearns]

I've been using python to write a simple 'launcher' for one of our Java
applications for quite a while now. I recently updated it to use python
2.4, and all seemed well.

Today, one of my colleagues noted that on her machine the launcher would
complain it was missing a DLL - msvcr71.dll

However, there's a very grey area concerning the redistribution of said DLL.

If you've been keeping up with the dev list, and some other web
discussions, you'll see that this has cropped up several times, but with
no conclusion in a legal fashion other than 'investigate it on your own
legal terms'.

I'm now going to have step back to using 2.3 until this issue is solved,
but judging by the way the dev list discussion just faded, I get the
impression that it may be a long wait.

I can't see how any company (or individual) can distribute an
application written in python, and then 'frozen' (I used py2exe) in any
way if they rely on the python24.dll that ships as standard. This is
surely a step backwards in usability.

I have no idea concerning the issues of rebuilding a different version
of python24.dll to be linked against the common msvcr.dll or whatever,
or changing the 'freeze' applications to do some magic, but I can't
believe it should be down to the end user to jump through legal or
compilation hoops when they're trying to use the language.

Apologies if this seems more aggressive than I intended it to be - I'm
just frustrated at having to stop following my language of choice for
the foreseeable future so far as my work is concerned.

Michael.

[Thomas Heller]

Michael Kearns <mi************@REMOVEsaaconsultants.com> writes:

I've been using python to write a simple 'launcher' for one of our
Java applications for quite a while now. I recently updated it to use
python 2.4, and all seemed well.

Today, one of my colleagues noted that on her machine the launcher
would complain it was missing a DLL - msvcr71.dll

However, there's a very grey area concerning the redistribution of said DLL.

If you've been keeping up with the dev list, and some other web
discussions, you'll see that this has cropped up several times, but
with no conclusion in a legal fashion other than 'investigate it on
your own legal terms'.

I'm now going to have step back to using 2.3 until this issue is
solved, but judging by the way the dev list discussion just faded, I
get the impression that it may be a long wait.

I can't see how any company (or individual) can distribute an
application written in python, and then 'frozen' (I used py2exe) in
any way if they rely on the python24.dll that ships as standard. This
is surely a step backwards in usability.

For commercial development, it should not be a problem to buy a license
for MSVC 7.1, which gives you the right to distribute msvcrt71.dll.

And maybe that's the reason that few people care about this issue?

Thomas

[Michael Kearns]

Thomas Heller wrote:

For commercial development, it should not be a problem to buy a license
for MSVC 7.1, which gives you the right to distribute msvcrt71.dll.

And maybe that's the reason that few people care about this issue?

Hi Thomas,

There are a few problems with this as I see it. In theory, the 'cost' of
MSVC 7.1 shouldn't be a problem for a big organisation. However, I
wouldn't expect to have to go and buy it purely because I'm developing
(perhaps) a shareware application using python - this isn't my case, but
I wasn't looking at it from just a big organisation perspective.

Also, I don't believe that just 'owning' MSVC 7.1 is enough. From
cursory glances at the various redist files, I would also have to ship
the EULA, and as an end-user (of python) I can't just redistribute the
files - perhaps I could write a place holder application in MSVC to
suggest that I was no longer an end-user, but this seems ridiculous as a
workaround.

There even seem to be 'exclude' clauses to redistribution concerning
open-source material, but IANAL and ran from the various paragraphs.

I would like to think that python would encourage as many folk as
possible to use the language wherever it fits best (and perhaps even
beyond) and yet this is going in the opposite direction.

Would it be so difficult for a 'no legalese attached' version to be
provided on windows, or at the very least, some kind of statement
regarding what is and isn't allowed ? There seems nothing within the
python distribution stating the redistribution rights of the dll
(correct me if I'm wrong) which already seems contrary to the MS
requirements.

As much as I'd like to continue using it, because of the vague legal
situation, I can't, and that's unfortunate.

Michael.

[Tim Peters]

[Michael Kearns]

...
Also, I don't believe that just 'owning' MSVC 7.1 is enough. From
cursory glances at the various redist files, I would also have to ship
the EULA, and as an end-user (of python) I can't just redistribute the
files - perhaps I could write a place holder application in MSVC to
suggest that I was no longer an end-user, but this seems ridiculous as a
workaround.

There even seem to be 'exclude' clauses to redistribution concerning
open-source material, but IANAL and ran from the various paragraphs.

I would like to think that python would encourage as many folk as
possible to use the language wherever it fits best (and perhaps even
beyond) and yet this is going in the opposite direction.

Would it be so difficult for a 'no legalese attached' version to be
provided on windows, or at the very least, some kind of statement
regarding what is and isn't allowed ?
I think it would be difficult. "We" (the Python developers) didn't
write Microsoft's license, have no special insight wrt it, and aren't
lawyers either. If you want legally binding clarifications or
exemptions, I think they have to come from Microsoft (it's their
license).

It would be cool if commercial users got together, pursued this with
MS, and shared what they learned. Of course it would also be cool if
someone with no commercial MS interests did so, but the chance of that
happening seems nil.
There seems nothing within the python distribution stating the redistribution
rights of the dll (correct me if I'm wrong) which already seems contrary to the
MS requirements.
That's possible too. MS hasn't complained to the PSF yet, but that's
no guarantee they won't.
As much as I'd like to continue using it, because of the vague legal
situation, I can't, and that's unfortunate.

Maybe the Python Business Forum could take this on? I don't know
whether they're still active, and their site isn't working today (at
least not for me):

http://www.python-in-business.org/

If someone(s) volunteered to do the work, it's also possible (not
certain) that the PSF would pay for lawyer time.

[Nemesis]

Mentre io pensavo ad una intro simpatica "Michael Kearns" scriveva:

I've been using python to write a simple 'launcher' for one of our Java
applications for quite a while now. I recently updated it to use python
2.4, and all seemed well.
Today, one of my colleagues noted that on her machine the launcher would
complain it was missing a DLL - msvcr71.dll

I have the same problem. But I have a doubt, does Python installer ship
this dll?
What happens if I try to install Python2.4 on a system wich doesn't have
the dll?

--
The complete lack of evidence is the surest sign that the conspiracy is
working.

|\ | |HomePage : http://nem01.altervista.org
| \|emesis |XPN (my nr): http://xpn.altervista.org

[Do Re Mi chel La Si Do]

Hi !

This DLL come also with MS-JVM engine, who is free. Therefore...

--
Michel Claveau

[Martin v. Löwis]

Michael Kearns wrote:

There are a few problems with this as I see it. In theory, the 'cost' of
MSVC 7.1 shouldn't be a problem for a big organisation. However, I
wouldn't expect to have to go and buy it purely because I'm developing
(perhaps) a shareware application using python - this isn't my case, but
I wasn't looking at it from just a big organisation perspective.

For developers that need msvcr71.dll on the target system which don't
have a license to distribute it, the solution is simple: they just need
to advise their users to install python-2.4.1.msi. This comes with
msvcr71.dll included.

Regards,
Martin

[Martin v. Löwis]

Nemesis wrote:

I have the same problem. But I have a doubt, does Python installer ship
this dll?
It sure does.
What happens if I try to install Python2.4 on a system wich doesn't have
the dll?

It will just work. Python installs the DLL if it is missing, and leaves
it alone (just incrementing the refcount) if it is present on the target
system.

Regards,
Martin

[Peter Hansen]

Martin v. Löwis wrote:

Michael Kearns wrote:

There are a few problems with this as I see it. In theory, the 'cost' of
MSVC 7.1 shouldn't be a problem for a big organisation. However, I
wouldn't expect to have to go and buy it purely because I'm developing
(perhaps) a shareware application using python - this isn't my case, but
I wasn't looking at it from just a big organisation perspective.

For developers that need msvcr71.dll on the target system which don't
have a license to distribute it, the solution is simple: they just need
to advise their users to install python-2.4.1.msi. This comes with
msvcr71.dll included.

I believe there are no restrictions on us redistributing
python-2.4.1.msi either, which would suggest that it
could simply be included in an installer package, and
perhaps the relevant DLLs could even be extracted from
the msi file without having to install it... I seem
to recall someone ;-) was making progress on an msi
package for Python which might be capable of this
too.

Of course then you'd need Python installed already in
order to install your application. On the other hand,
you could always include a copy of Python 2.3 as well,
and use that to extract the DLLs from the MSI.

Or other equally insane approaches ...

-Peter

[Do Re Mi chel La Si Do]

And, also, with dotNET-framework

[Michael Kearns]

Martin v. Löwis wrote:

For developers that need msvcr71.dll on the target system which don't
have a license to distribute it, the solution is simple: they just need
to advise their users to install python-2.4.1.msi. This comes with
msvcr71.dll included.

I understand this, and it's obviously a solution. Unfortunately it
defeats the whole point of me 'freezing' my code in the first place.

The main feature (for me) of the way I could use this, was to create a
simple Java launcher that didn't require the user to install anything
extra, or end up with a whole stack of unused data on their machine.

They would see a .exe file, a dll and a pyd, and then the actual
application files, and that was it. It may be fine for a 'knowledgeable'
user to install python etc., but not for everyone.

Michael.

[Michael Kearns]

Do Re Mi chel La Si Do wrote:

Hi !

This DLL come also with MS-JVM engine, who is free. Therefore...

This is very true (and the .NET suggestion as well). However, why should
I require an end-user to install MS-JVM or the .NET framework, purely
for a simple little launcher application ?

The main application it launches is Java, but there's no way it would
run on the MS-JVM, and .NET just gives a load more technology that we
don't really need (and is a bigger install than the entire application).

Michael.

[Fredrik Lundh]

Martin v. Löwis wrote:

What happens if I try to install Python2.4 on a system wich doesn't have
the dll?

It will just work. Python installs the DLL if it is missing, and leaves
it alone (just incrementing the refcount) if it is present on the target
system.

installs it where? the MS docs seem to indicate that they want you to install
it in the program directory, rather than in a "shared" location:

http://support.microsoft.com/default...b;en-us;326922

</F>

[Jeff Epler]

I'm sorry that this is going to come out sounding like a flame, but it
seems to me that there today only a few technical problems remaining
with Python when built with mingw32.

If one of the people who has expressed such deep concern about this
"msvcr71.dll" problem would simply install the Free tools and start
putting patches on sourceforge, it's quite possible that for the next
2.4.x release the mingw32 "port" could be a first-rate one, and suitable
for the uses that the posters in this thread have mentioned.

Since mingw32 is Free (gpl and other licenses for tools, public domain
libraries and copyrighted headers with "no restrictions for programs"
built using the headers) anyone can install and use these tools and
mingw creates no new problems with distribution of the resulting binary,
whether the final product is Free or proprietary.

(Admittedly I don't know anything about whether "win32all" builds under
mingw32, and it's not clear whether binary compatibility with extensions
built by microsoft compilers is an easy goal either)

http://www.mingw.org/

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFCW9BaJd01MZaTXX0RAjSUAJ9rQ9iPncKGReearcIiAG aiE2pVCgCfbx39
eRPFXirdDedIlhyhXrs42RU=
=QgCW
-----END PGP SIGNATURE-----

[Terry Reedy]

"Michael Kearns" <mi************@REMOVEsaaconsultants.com> wrote in message
news:42***********************@news.gradwell.net.. .

I understand this, and it's obviously a solution. Unfortunately it defeats
the whole point of me 'freezing' my code in the first place. The main feature (for me) of the way I could use this, was to create a
simple Java launcher that didn't require the user to install anything
extra, or end up with a whole stack of unused data on their machine.

I guess I don't understand some people's determination to not have users
install fully useable Python on their Windows machines. Doing so seems no
different to me than having to install (or upgrade) Shockwave, or Apple's
Quicksomething for Windows (not used so much anymore), or RealPlayer, or
the lastest upgrade for DirectX, or DivX, or a zip decoder, or any other
3rd party software, to run .xxx files or specialized .exe programs. (And I
left out the most direct analogy of a java system.)

In other words, it seems to me that most Windows users should be familiar
with the idea of having to install a player or platform to run something
built on top of that player or platform. Bundling a private Python
interpreter with every Python script is much like bundling a private
Shockwave player with every Schockwave script. I think most people would
prefer having one copy of each.

To put it another way, needing a Python interpreter to run .py files is no
different from, for instance, needing a movie player to run .mpg files, and
all Windows users are or need to become familiar with that general concept.

Also, I think it a bit 'anti-social' to hide usage of Python. If all
Python Windows programs ran with a normal, communally installed Python,
then users would gradually get the idea that having Python installed is
much like having Shockwave and other utility platforms installed, and that
is is part of a 'fully loaded' Windows system to have a .py player
installed.

If there is something about the default install of Python on Windows that
makes it less desireable or less easy than other platforms, then maybe that
can be fixed. To make installation easier, maybe someone could write a
small .exe that could be frozen with scripts or run with installers and
that would detect the presence/absence of the needed Python version and
offer an auto download and install if needed.

At least one thing in Python's favor is the lack of having to 'register'
before downloading (or after installation) and the ability to redistribute
the installer free and without special license.

Terry J. Reedy

[Thomas Heller]

"Terry Reedy" <tj*****@udel.edu> writes:

[...]

Also, I think it a bit 'anti-social' to hide usage of Python. If all
Python Windows programs ran with a normal, communally installed Python,
then users would gradually get the idea that having Python installed is
much like having Shockwave and other utility platforms installed, and that
is is part of a 'fully loaded' Windows system to have a .py player
installed.
Isn't it a bit harsh to call this 'anti-social'?

If there is something about the default install of Python on Windows that
makes it less desireable or less easy than other platforms, then maybe that
can be fixed. To make installation easier, maybe someone could write a
small .exe that could be frozen with scripts or run with installers and
that would detect the presence/absence of the needed Python version and
offer an auto download and install if needed.
Sure. Someone.

At least one thing in Python's favor is the lack of having to 'register'
before downloading (or after installation) and the ability to redistribute
the installer free and without special license.

Thomas

[Dave Brueck]

Terry Reedy wrote:

I guess I don't understand some people's determination to not have users
install fully useable Python on their Windows machines. [snip] To put it another way, needing a Python interpreter to run .py files is no
different from, for instance, needing a movie player to run .mpg files, and
all Windows users are or need to become familiar with that general concept.

Also, I think it a bit 'anti-social' to hide usage of Python. If all
Python Windows programs ran with a normal, communally installed Python,
then users would gradually get the idea that having Python installed is
much like having Shockwave and other utility platforms installed, and that
is is part of a 'fully loaded' Windows system to have a .py player
installed.

If there is something about the default install of Python on Windows that
makes it less desireable or less easy than other platforms, then maybe that
can be fixed. To make installation easier, maybe someone could write a
small .exe that could be frozen with scripts or run with installers and
that would detect the presence/absence of the needed Python version and
offer an auto download and install if needed.

I mostly agree with the sentiment, but it does break down a little in practice.
At least currently it does - like you said, this is fixable, but nobody has
signed up to fix it yet.

The main thing that's needed is a zero-input Python distribution - a Python
runtime, if you will - that (1) gets installed to a "good" place (2) does so
without asking the user to do anything, (3) can coexist with different versions
of the runtime, and (4) is easily detectable by applications wanting to use it.

One other minor component is a small launcher executable, because on Windows
it's non-trivial to find out which "python.exe" in the task manager is running
which Python script. Anyway, each app would have a small launcher that
bootstraps the actual Python script[1]. (Or, if there's some way to trick the
task manager into displaying something besides "python.exe", that'd work too)

In order to "fit" into the expectations of a typical Windows user, an
application installer needs the ability to check for the presence of a
particular version of the Python runtime, and then install it if it's not
present, and do so without asking the user to do anything.

With that much in place, a lot of the need for freezing Python apps goes away
(definitely not all of it, but a lot of it). Here's stuff that still needs to be
considered though:

1) A way for apps to specify their compatibility with different versions of the
runtime - "I work with pyrt2.3.3 through 2.4.1"

2) A way for apps to register their dependency on that runtime, so that if the
user uninstalls it, there is at least an indication of what programs might break.

3) (this is a nice-to-have, but not 100% required) A way to download additional
libraries once and use them for multiple programs, e.g. the installer could see
if ctypes is present, and if not, go get it. Later programs would take advantage
of it already being installed. Like I said, not a 100% requirement, and some of
the ongoing work with code CPAN-like code repositories would shoehorn into this.

4) The security implications, e.g. an innocent app installs pywin32 and enables
Python client-side scripting in Internet Explorer, and later this is used as a
big door for malicious users to use.

Most of these tasks don't require a lot of work; indeed this has been on my "one
of these days" lists for awhile. The main reasons it hasn't been done yet:

1) The code freezing tools like py2exe are *very* good and convenient
(especially since loading code from zip archives was added - even if you include
all of Python, it's only a few files on disk, and now they're all in the same
directory)

2) Storage space and download speeds continue to increase at a rate much faster
than the rate at which the size of Python is growing - a download of a few MB
isn't too bad these days, who cares if your app takes 4MB on disk, and so what
if it doesn't fit on a floppy, for example.

3) As soon as you get started on such a project, almost immediately you will be
overwhelmed with a desire to create a CPAN-like system while you're at it, at
which point your project's status will shift from "making good progress!" to "in
quagmire, developers MIA". :)

-Dave

[1] I built a hacky one of these launcher exe's for one project, and it was
fairly reusable for apps in the same vein. Basically, the exe would would look
to see what its name was, and then load a Python module of the same name. So if
you have MyGame.py, you'd just take the generic launcher.exe, copy it to the
same directory as your .py files, and rename it to MyGame.exe. On launch, it'd
load the interpreter, load MyGame.py, and pass it the command-line args.

[Thomas Heller]

Dave Brueck <da**@pythonapocrypha.com> writes:

Terry Reedy wrote:

If there is something about the default install of Python on Windows
that makes it less desireable or less easy than other platforms,
then maybe that can be fixed. To make installation easier, maybe
someone could write a small .exe that could be frozen with scripts
or run with installers and that would detect the presence/absence of
the needed Python version and offer an auto download and install if
needed.
I mostly agree with the sentiment, but it does break down a little in
practice. At least currently it does - like you said, this is fixable,
but nobody has signed up to fix it yet.

The main thing that's needed is a zero-input Python distribution - a
Python runtime, if you will - that (1) gets installed to a "good"
place (2) does so without asking the user to do anything, (3) can
coexist with different versions of the runtime, and (4) is easily
detectable by applications wanting to use it.

The effbot.exe platform (or how it's called) ?
One other minor component is a small launcher executable, because on
Windows it's non-trivial to find out which "python.exe" in the task
manager is running which Python script. Anyway, each app would have a
small launcher that bootstraps the actual Python script[1]. (Or, if
there's some way to trick the task manager into displaying something
besides "python.exe", that'd work too)

exemaker?

Thomas

[Dave Brueck]

Thomas Heller wrote:

Dave Brueck <da**@pythonapocrypha.com> writes:

Terry Reedy wrote:

If there is something about the default install of Python on Windows
that makes it less desireable or less easy than other platforms,
then maybe that can be fixed. To make installation easier, maybe
someone could write a small .exe that could be frozen with scripts
or run with installers and that would detect the presence/absence of
the needed Python version and offer an auto download and install if
needed.

I mostly agree with the sentiment, but it does break down a little in
practice. At least currently it does - like you said, this is fixable,
but nobody has signed up to fix it yet.

The main thing that's needed is a zero-input Python distribution - a
Python runtime, if you will - that (1) gets installed to a "good"
place (2) does so without asking the user to do anything, (3) can
coexist with different versions of the runtime, and (4) is easily
detectable by applications wanting to use it.

The effbot.exe platform (or how it's called) ?

Yep - something along those lines, plus some docs for app developers. I don't
know if it installs all the stdlib, or just what effbot apps need, but I assume
the former.

One other minor component is a small launcher executable, because on
Windows it's non-trivial to find out which "python.exe" in the task
manager is running which Python script. Anyway, each app would have a
small launcher that bootstraps the actual Python script[1]. (Or, if
there's some way to trick the task manager into displaying something
besides "python.exe", that'd work too)

exemaker?

Something similar to that, yes. You'd need an option to generate a console
launcher or a Windows app launcher (maybe his latest version already has this?),
and a way to figure out which version of the runtime to use (rather than specify
the path ahead of time, you'd specify version requirements, and then at runtime
use registry entries to figure out where that runtime is), but the general idea
is the same.

-Dave

[Nemesis]

Mentre io pensavo ad una intro simpatica "Martin v. Löwis" scriveva:

What happens if I try to install Python2.4 on a system wich doesn't have
the dll?

It will just work. Python installs the DLL if it is missing, and leaves
it alone (just incrementing the refcount) if it is present on the target
system.

OK, so the python installer _does_ ship this dll. So also the win
installer has the redistribution problem, or does they pay for
redistributing msvcr71.dll?

--
Computers follow your orders, not your intentions.

|\ | |HomePage : http://nem01.altervista.org
| \|emesis |XPN (my nr): http://xpn.altervista.org

[Nemesis]

Mentre io pensavo ad una intro simpatica "Fredrik Lundh" scriveva:

It will just work. Python installs the DLL if it is missing, and leaves
it alone (just incrementing the refcount) if it is present on the target
system.

installs it where? the MS docs seem to indicate that they want you to install
it in the program directory, rather than in a "shared" location:

As far I remember the Python installer copies this dll in the system32
folder if you install Python as Administrator, instead it leaves the
dll inside the Python folder if you install Python as User.

--
As a computer, I find your faith in technology amusing.

|\ | |HomePage : http://nem01.altervista.org
| \|emesis |XPN (my nr): http://xpn.altervista.org

[Bengt Richter]

On Tue, 12 Apr 2005 08:42:54 -0500, Jeff Epler <je****@unpythonic.net> wrote:

--7iMSBzlTiPOCCT2k
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

I'm sorry that this is going to come out sounding like a flame, but it
seems to me that there today only a few technical problems remaining
with Python when built with mingw32.

If one of the people who has expressed such deep concern about this
"msvcr71.dll" problem would simply install the Free tools and start
putting patches on sourceforge, it's quite possible that for the next
2.4.x release the mingw32 "port" could be a first-rate one, and suitable
for the uses that the posters in this thread have mentioned.

Since mingw32 is Free (gpl and other licenses for tools, public domain
libraries and copyrighted headers with "no restrictions for programs"
built using the headers) anyone can install and use these tools and
mingw creates no new problems with distribution of the resulting binary,
whether the final product is Free or proprietary.

(Admittedly I don't know anything about whether "win32all" builds under
mingw32, and it's not clear whether binary compatibility with extensions
built by microsoft compilers is an easy goal either)

http://www.mingw.org/

+1
But credit where due. Someone has stepped up to a large chunk of the problem:

http://jove.prohosting.com/iwave/ipython/pyMinGW.html

I am running a usable-for-most-purposes version of 2.4, that with the help of
an older version of the above (I should upgrade all those tools, but ;-)
I succeeded in building. It was the only way I could go from 2.3 to 2.4, since
the MS .msi installer stuff from MS does not itself install successfully on my NT4 ;-/

I am thinking that I'd like to make a script that would ease pulling all the pieces
from the net (urllib, and md5 checks to download stuff, a state log that would
permit easy resuming when something glitches, and automated dialogs for typical
installer info re locations preferences etc. But I got to thinking about sourceforge's
downloading interface choosing mirrors, and thought "later" ;-)

Well, when I get my next system ;-) But it may be moot, 'cause it will probably be Linux
or BSD (both of which I have on another old box which is too slow for X ;-)

Trouble is, I have banged on the pinching spots in my old NT shoes long enough
to where they are relatively comfy for my regular ambulations ;-)

Regards,
Bengt Richter

[Jeff Epler]

On Tue, Apr 12, 2005 at 08:25:58PM +0000, Bengt Richter wrote:

But credit where due. Someone has stepped up to a large chunk of the problem:

http://jove.prohosting.com/iwave/ipython/pyMinGW.html

Yay. I'm glad somebody *is* doing this. Maybe all that is needed is to
"get the word out". Some prepackaged binaries would be nice, however.

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFCXDjsJd01MZaTXX0RAtnNAJ9G16udrgm8/JmGLxOsdhh0chb6rwCgiWJe
zIMDnLoXV07iAmiSnL/xRTg=
=qpDX
-----END PGP SIGNATURE-----

[Peter Hansen]

Nemesis wrote:

OK, so the python installer _does_ ship this dll. So also the win
installer has the redistribution problem, or does they pay for
redistributing msvcr71.dll?

The last I recall reading in this forum was that the regular
distribution is compiled with a copy of the compiler
*provided by* Microsoft.

Whether they really have in a mind a devious strategy
involving getting lots of people to ship software with
the msvcr71.dll file (and the other one: both are needed)
and then sue the pants off them is anyone's guess...

-Peter

[Peter Hansen]

Peter Hansen wrote:

The last I recall reading in this forum was that the regular
distribution is compiled with a copy of the compiler
*provided by* Microsoft.

On re-reading, I see this might not be clear enough.

By 'provided by' I meant *donated by*, as in given
free (apparently) to the PSF or at least to one of
the core developers for the purpose of compiling
Python itself. Given the nature of Python, one
might see this as an implicit comment about the
status of the two key DLL files in question and
how concerned Microsoft is (or is not) about their
possible widespread distribution in software whose
authors didn't directly pay MS for the compiler.

A Google search might reveal the message in which
I read that, posted a few months ago I believe.

-Peter

[Martin v. Löwis]

Peter Hansen wrote:

The last I recall reading in this forum was that the regular
distribution is compiled with a copy of the compiler
*provided by* Microsoft.

[...] By 'provided by' I meant *donated by*, as in given
free (apparently) to the PSF or at least to one of
the core developers for the purpose of compiling
Python itself.

Just for the record: While I do have received such a copy,
this copy isn't actually used to build the binaries. Instead,
I use a copy of the compiler that my employer has licensed
(not that this matters much).

I cannot personally see much difference between using VC6
or VC7.1. One key reason for me to push the change for VC7.1
is that VC7.1 has updated SDK headers, which in turn means
that Python 2.4 supports IPv6 (which wasn't really possible
with VC6). Also, many people who build Python extensions
cannot get a copy of VC6 anymore (because MS stopped selling
it), so if Python was built with VC6, many people could
not build Python extensions.

I cannot see much of a difference because Python would have
to include the CRT in *either* case - whether it is mscvrt4.dll,
or msvc71.dll. Neither of these DLLs is guaranteeed to be
shipped with the operating system; that people got away with
not distributing mscvrt4.dll is only because so much other
software distributes it that it is available on virtually
every system. I predict the same will happen with mscvr71.dll
over time (and then with the CRT that will be shipped with
the next release of VC).

Regards,
Martin

[Roger Binns]

"Terry Reedy" <tj*****@udel.edu> wrote in message news:ma**************************************@pyth on.org...

I guess I don't understand some people's determination to not have users install fully useable Python on their Windows machines.
Ok, here is how you install BitPim which contains a frozen Python:

- Download and run the setup.exe from www.bitpim.org (The
instructions are the equivalent on Linux and Mac)

This is how you would do it if a "fully usable" Python had to be put on a
machine.

- Download and install Python from www.python.org
- Download and install wxPython from www.wxpython.org making sure to
get the correct platform, Python version, wxPython version and Unicode
setting
- Download and install pyserial from pyserial.sf.net for your platform
- Download and install win32all making sure you get the right Python
version (Windows only)
- Download and install DSV from sf.net/projects/python-dsv
- Download and install APSW from www.rogerbinns.com/apsw.html
(Non-Windows users will also have to compile SQLite 3)
- Download and install the BitPim code
- There are a few other components which non-Windows users typically need
and Windows users don't (eg USB library)
- Now launch the main Python script to start BitPim

The uninstall instructions have the same corresponding lengths. Now for the
second part, you could make some arguments:

- I shouldn't be using other components in order to reduce dependencies
and should instead re-invent the wheel myself.
- I could make some sort of installer that did all the non-Python interpretter
pieces and it would have to be compatible with anyone else doing the same
thing.

The first is a waste of my time and effort, and I do the second except I also
include the Python interpretter meaning there are no dependencies.
Also, I think it a bit 'anti-social' to hide usage of Python.

http://www.bitpim.org/testhelp/3rdparty.htm

The reality is that users don't care what language your program was written in,
what development methodology you use, how hard it was to write, what editor you
use or how your environment enlightens your mind. They do care that what you
produce works as expected. In fact if it works really well, they may decide
to dig in deeper and try to emulate your language, methodology, procedures,
editors in what they do or may contribute to your project if it is open source.
That is the point at which Python matters.

In all these matters I think it is better to lead by example rather than try
to make people aware of things early in order to perform some sort of attempt
to gain mindshare.

Roger

[kosh]

On Wednesday 13 April 2005 9:11 pm, Roger Binns wrote:

"Terry Reedy" <tj*****@udel.edu> wrote in message
news:ma**************************************@pyth on.org...

I guess I don't understand some people's determination to not have users
install fully useable Python on their Windows machines.

Ok, here is how you install BitPim which contains a frozen Python:

- Download and run the setup.exe from www.bitpim.org (The
instructions are the equivalent on Linux and Mac)

Here is the situation I see. I use debian linux systems. Installing all the
dependencies is trivial and if your program has a debian package it would be
a single command. The reason I don't like these programs that built the
runtime, static link in a bunch of stuff etc is that it is a pain to upgrade
later. If there is a security fix to python 2.4 I know there is ONE copy
installed on the system and that updating it will fix it. If there is a
problem with libpng, libjpeg, kdelibs, zope, apache etc the same is still
true, there is only ONE copy of those items on the system and with a single
command all of them can be updated and fixed.

Under windows I can see why you would want stand alone binaries since it has
no method for dealing with dependencies the way that the bsds and linuxes
can. However for a unix product I always want items to be in their seperate
parts since it makes my life as a programmer and admin a heck of a lot
easier. Actually I tend to avoid any software that is not in the debian main
archives since then it is more of a pain to deal with later.

Keeping track of security updates, feature updates etc for a bunch of
computers with a lot of software from different locations is a royal pain in
the neck. With windows it is worse since you don't even have a centralized
update system.

[Roger Binns]

> Here is the situation I see. I use debian linux systems. Installing all the

dependencies is trivial and if your program has a debian package it would be
a single command.
Note that there is *nothing* precluding running using the system Python
other than you have to have the dependencies present. In fact that is how
all the developers run. The binary/frozen packages are provided as a
convenience to the users who just want to use the program and I don't
see any need for them to jump through hoops.
The reason I don't like these programs that built the
runtime, static link in a bunch of stuff etc is that it is a pain to upgrade
later.
True. People on both Gentoo and Debian have told me they are making
proper ebuild/dkpg for BitPim. In both cases nothing came of it
which is why I tell people on those systems to just use the rpm.

As far as I can tell, they failed at two hurdles. One is that there
is a new BitPim release every two weeks and they can't really keep up
with that. (eg it takes around two weeks for packages with a lot of
attention on Gentoo to become stable and often is a lot longer)

The second is dealing with the dependencies. The packager is trying
to do BitPim and finds they have to work with others or need assistance
to deal with the dependencies. Gentoo is months out of date for wxPython
and I have no idea how far behind Debian is. Typically other dependencies
aren't even packaged at all, even though they use distutils (ie all it
takes is figuring out how to do 'python setup.py install' in a way that
keeps the packaging system happy).
If there is a security fix to python 2.4 I know there is ONE copy
installed on the system and that updating it will fix it. If there is a
problem with libpng, libjpeg, kdelibs, zope, apache etc the same is still
true, there is only ONE copy of those items on the system and with a single
command all of them can be updated and fixed.
True. Noone forces you to install/run anything. Right now someone on Debian
who wants to use BitPim has one of these choices:

- Fix Debian's packaging so that it contains all of the dependencies and
BitPim itself with the latter being updated every two weeks. This will
keep your scenario above on the right track.

- Bypass Debian's packaging and install the various dependencies manually
and run from "source"

- Use alien and the rpm
Keeping track of security updates, feature updates etc for a bunch of
computers with a lot of software from different locations is a royal pain in
the neck.

True. And the reality is that various Python packages are backwaters/low
priority for the packagers. All it takes is one missing dependency to
throw a spanner in the works.

And as I told the person who originally wanted to package BitPim for Debian,
I will supply all the help and make changes as necessary. Someone from the
distros has to step forward to complete it.

Roger

[Martin v. Löwis]

Roger Binns wrote:

- I could make some sort of installer that did all the non-Python interpretter
pieces and it would have to be compatible with anyone else doing the same
thing.

The first is a waste of my time and effort, and I do the second except I also
include the Python interpretter meaning there are no dependencies.

If that works for you and your users, fine - the main point of this
thread is that some users complain they can't do that anymore, because
they have no license to distribute msvcr71. For those users: what is
the reason not to use the approach of shipping an application that
requires a certain version of Python pre-installed on the target
machine?

Regards,
Martin

[Peter Lee]

>>>> Terry Reedy writes:

To put it another way, needing a Python interpreter to run .py files is no
different from, for instance, needing a movie player to run .mpg files, and
all Windows users are or need to become familiar with that general concept.

The problem for windows users isn't that they have to download a movie
player to play .mpg files... it's that they also have to download and
install python/java runtime to "play" the player because it was written
in python/java. Most won't bother and will download/install native
win32 app instead.

[Stefan Behnel]

Roger Binns schrieb:

As far as I can tell, they failed at two hurdles. One is that there
is a new BitPim release every two weeks and they can't really keep up
with that. (eg it takes around two weeks for packages with a lot of
attention on Gentoo to become stable and often is a lot longer)

This is why many open source projects include (possibly outdated) .spec
files directly in their tree. Makes it easy to just adapt them and run
rpmbuild. Similar for Debian package specs.

With Python sources it is even easier (most of the time) since you can run
python setup.py bdist_rpm
which spits out a readily baken RPM, ready to be nailed into the system.
Sadly, this doesn't exist for Debian and it doesn't work for all Python
packages (Twisted, that is).

Stefan

[Roger Binns]

"Stefan Behnel" <be*******@gkec.informatik.tu-darmstadt.de> wrote in message news:d3**********@lnx107.hrz.tu-darmstadt.de...

Roger Binns schrieb:

As far as I can tell, they failed at two hurdles. One is that there
is a new BitPim release every two weeks and they can't really keep up
with that. (eg it takes around two weeks for packages with a lot of
attention on Gentoo to become stable and often is a lot longer)
This is why many open source projects include (possibly outdated) .spec files directly in their tree. Makes it easy to just adapt
them and run rpmbuild. Similar for Debian package specs.

Funnily enough there is an ebuild file in the BitPim source. However
it has to be munged for each release since Gentoo requires the ebuild
filename to include the version number. I don't bother releasing that
file due to the onerous non-automated SourceForge file upload process.
(And many of the dependencies aren't in Portage anyway so this would
have to be quite a number of ebuilds).
With Python sources it is even easier (most of the time) since you can run
python setup.py bdist_rpm
which spits out a readily baken RPM, ready to be nailed into the system. Sadly, this doesn't exist for Debian and it doesn't work
for all Python packages (Twisted, that is).

The distutils approach is mainly useful for packages and libraries,
not for applications. And of course it still has the prerequisites
issues mentioned earlier.

Roger

[Jarek Zgoda]

Roger Binns napisa³(a):

The distutils approach is mainly useful for packages and libraries,
not for applications. And of course it still has the prerequisites
issues mentioned earlier.

This reminds me, that there is still no clear direction as to where
install Python applications on Linux if one wants to be FHS-compliant.
Teoretically, one may try to install to /opt/appname hierarchy, but many
distributions simply refuse such packages (as it was the case with my
JPA in PLD Linux).

--
Jarek Zgoda
http://jpa.berlios.de/ | http://www.zgodowie.org/

[long.in.the.tooth]

Just to add my voice to those suffering because of this issue...

For me the main problem is going to a two step install. Also, it makes
my application much bigger.

Responding to earlier comments, you know what's really frustrating? So
far, every pc which has failed to install my app has actually had a
copy of this dll someplace. One is tempted to script the installer to
search for the thing and then copy it over. One wonders that the
install failure rate would be then. BUT, this would still be an
unacceptable risk. Nothing makes customers more angry than install
problems.

Bottom line: If MS wants to support an open source programming
language, they have to do more than give away a tool chain. They also
have to license their libraries in a compatible way.

Further, (well aware that as the recipeient of a free tool my
complaints might be properly dumped in the trash) if PDF wants to
distribute same, they need to ensure that users will be free to do
programming language type activities, like package and distribute
applications.

So I've got some time before I actually have to distribute, but I do
hope for a solution to this problem.

Thanks very much for all your hard work,

Sean Cavanagh

[ucntcme]

It would be *really* nice if it worked for Python itself for making an
RPM distribution of Python.