Python 2.4 killing commercial Windows Python development ?

[Nemesis]

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

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.

 

[Bengt Richter]

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

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]

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]

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

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

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]

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]

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

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

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

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]

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]

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

 

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