Deployment woes (was: I will kill my Python)

[Grant Edwards]

In article <4DE7F9DB9399A3C1.D96FC6EFB3F2391E.88AD1775E4555FCA at lp.airnews.net>, Cameron Laird wrote:
>In article <WV0a6.745$eI2.252250 at ruti.visi.com>,
>Grant Edwards <grante at visi.com> wrote:
>>In article <947r18$rdt$1 at news.online.de>, Nils Hensel wrote:
>>
>>>If an exe is your single concern then perhaps you should better
>>>stick with VB.
>>
>>As if running an exe file generated by VB doesn't require that
>>a whole slew of DLLs and other cruft be installed.  It's no
>>different than Python.
>			.
>			.
>			.
>Is that true?  I thought the VB deployment was worse,
>in that *those* DLLs seem more likely to degrade an
>already-operational Win* host.

Perhaps I should have said that it's no better than Python. 

I too (though I don't use Windows very often) have had DLL
conflicts:  The installer that comes with some VB app replaces
an existing DLL and then other stuff stops working.

At least that's what somebody who understands the vagaries of
Windows told me.  The whole "DLL roulette" game that Windows
users play every time they install something seems a bit
ridiculous.  Under most Unix systems you can install as many
different revisions of a shared library as you want.

My experience distributing Python apps has so far been limited
to a fairly trivial case: I know the target system is Linux,
and I put a note in the man page that you have to have Python
and Tkinter installed.  

Nobody's complained so far, but I have no idea how many people
are actually using the program.

-- 
Grant Edwards                   grante             Yow!  .. I want to perform
                                  at               cranial activities with
                               visi.com            Tuesday Weld!!