pythoncard-users

RE: [Pythoncard-users] Python distribution problems

[Schollnick, B. <Ben...@xe...>]

> > Python and Pythoncard/wxPython/insert favourite GUI toolkit here are
> > *never* going to make a huge impact on the Visual Basic=20
> market. IMHO,=20
> > though, that's not a valid reason to stop using them.
>=20
> growing number of VFP/VB users who are unhappy with Microsoft for the=20
> way they've been brushed aside in lieu of the latest Flavor of the=20
> Month. These people are looking to pick up something new to=20
> develop in,=20
> and many of them would prefer not to commit to another=20
> Microsoft tool.=20

Which is sensible....

I have not used or purchased another Microsoft language since they sold
QuickPascal v1.0.  They promised features that did not exist in v1.0 and
I never forgot that lesson.

> Cool tools such as PythonCard help to increase the chance that they=20
> move to Python instead of remaining on the Dark Side.  ;-)

True.

> 	That's why if you're looking to grow your user base,=20
> it's important to=20
> make things as familiar as possible to those folk.=20

Not necessarily.  What we need to supply is something that is overall
better than what they were using.  Yes, it should be a usable and
productive User Interface and Design... =20

But familiar does not necessarily mean better.

Can you give us a few examples? =20

For example, the Windows Registry.  That's familiar to Windows
programmers, but would you suggest that we a need a registry like
component in Python or PythonCard?

I think I can safely say that 90% of Python/PythonCard developers would
say "NO"....

Yes, it's absurd comparison...  But you did not include any examples...
As I mentioned, familiar does not necessarily equal better.  Just
familiar.

> They're leaving=20
> their former comfort zone for something foreign, and the fewer hoops=20
> they have to jump through, the more likely they might stick with your=20
> product, and evangelize it to others.=20

Yes, but it also is a situation where a better product may have a small
learning curve, but is worth the investment.

I think PythonCard needs better documentation, but for 90% of the
situations, the documentation is more than enough....

> So while the things you mention=20
> are not valid reasons for an existing PythonCard developer to *stop*=20
> using the tool, they would be sufficient for a new PythonCard=20
> developer coming from the VB world to never *start*.

The Pythoncard tutorial that I used to evaluate PythonCard was enough to
convince me to use the software.  I would assume that anyone that was
thinking of using it would attempt to use the tutorial and start basing
a decision on that.

I am unclear on what you are suggesting they are basing their decisions
on?  (The quote does not include it)  Presumably on the fact that they
need to instead Python, WxPython, and PythonCard?  Windows programmers
are fully aware of dependencies...  .Net anyone? =20

		- Benjamin

RE: [Pythoncard-users] Python distribution problems

[Schollnick, B. <Ben...@xe...>]

> >I am unclear on what you are suggesting they are basing=20
> their decisions=20
> >on?  (The quote does not include it)  Presumably on the fact=20
> >need to instead Python, WxPython, and PythonCard?  Windows=20
> programmers=20
> >are fully aware of dependencies...  .Net anyone?

> True - they are aware of them - but that doesn't mean they=20
> like them. I=20
> think it would be pretty cool to have the *option* of a=20
> single download=20
> and install to do Python, wxPython and Pythoncard in one easy=20
> operation.=20
> I have no idea how easy it would be to create that - but I suspect it=20
> would overcome some people's concerns about the complexity of getting=20
> started with Pythoncard.

The option might be nice....  But is it a reasonable option?

That's at least 6+ different archives.... (Windows, *Nix, MacIntosh) ...
That Kevin would have to maintain.  I don't even know if Kevin has all
of those systems....

Plus just python alone (without Source code) is 10 MB.  And that's a
dedicated installer (.MSI)....  It will be larger in this combined
installer....  WxPython is another 6 MB, and PythonCard is another 2...

SubTotal roughly 20Mb.

That is not including Python Source code, nor Win32 Extensions...
And is consists of 3 different installers....

1) This will be at least a 20 Mb download....
2) Who is liable for this?  If a problem occurs with <fill in the blank>
	is Kevin going to be forced to Fix it?  (WxPython Developer:
It's=20
	not a bug in our code, your installer goofed...)
3) How is all of this going to be packaged?  We have a .MSI installer,
	two .EXE installers...  Prepackage/ZIP everything up?  What if
	the person installing wants a non-standard path or library?

It maybe a good idea, but I think it is safer and smarter to use=20
approved installers directly from the authors...

A better suggestion, IMHO, is to suggest to Kevin to have a quick link
at the top pointing to each installer... =20

ie.
-----------------------------------------------------------------
PythonCard is currently at Version v0.81. =20

Pythoncard requires the following software:

	* Python v2.3.x or later
	  Tested with Version v2.3.888 (download Installer) on xx/xx/xx

	* WxPython v2.x.x or later (Unicode and Non-Unicode versions)
	  Tested with Version v2.3.888 (download Installer) on xx/xx/xx

-------------------------------------------------------------------

Each development environment is going to be different, some people will
want WxPython with Unicode support, some without...  Some will need
WxPython vxx.yy.zz and some want to be using the CVS nightly builds...

There is no sensible way to allow of that to be bundled without a huge
amount of effort.

		- Benjamin

[Pythoncard-users] Re: Python distribution problems

[normanwinn <nor...@on...>]

ka wrote:
> Secondly, once we have a viable 1.x release, I would like to have a 
> single installer option for Python, wxPython, and PythonCard on the 
> Windows platform

The very fact that you should need to contemplate this demonstrates the 
severity of the problem. I already have versions of Python that came 
with Zope, with Open Office, then I'll have another with PythonCard and 
another with Dabo. Where will this stop? Each time I want to upgrade I 
end up upgrading n versions of Python? This is folly.

What is the alternative? I can't have an answer as I am not at the 
interior of an open source effort. Perhaps a standard test suite for 
Python? Perhaps co-ordinated upgrade days? Perhaps sterner control over 
the standard Python library?

Then the exe tools. With py2exe I ended up with the tcl library in my 
'exe' package when compiling a command line tool! I don't know how many 
megabytes I had to distribute. I didn't bother. I then found exemaker:

http://effbot.org/downloads/index.cgi/exemaker-1.2-20041012.zip/README

but this, while being very handy on a system that has Python, is not a 
standalone exe so can't be distributed.

Please accept that I am not knocking (does that translate into 
American). I hope my observations can contribute to a process that will 
make Python tools available to all,

Norman Winn


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.2 - Release Date: 05/04/2005

Re: [Pythoncard-users] Re: Python distribution problems

[Phil E. <ph...@li...>]

On Tue, 2005-04-05 at 08:48, normanwinn wrote:
> ka wrote:
> > Secondly, once we have a viable 1.x release, I would like to have a 
> > single installer option for Python, wxPython, and PythonCard on the 
> > Windows platform
> 

hmmm...not sure I can fully see the benefit of this. You only need to
install these if you are planning to write your own apps, in which case
downloading and installing them individually wouldn't present any kind
of technical challenge.

For distributing finished applications, then I would contend that you
explicitly *don't* want to have to install Python/wxPython/PythonCard -
you should be using the existing tools to bundle up your program into an
installer.

> The very fact that you should need to contemplate this demonstrates the 
> severity of the problem. I already have versions of Python that came 
> with Zope, with Open Office, then I'll have another with PythonCard and 
> another with Dabo. Where will this stop? Each time I want to upgrade I 
> end up upgrading n versions of Python? This is folly.
> 
> What is the alternative? I can't have an answer as I am not at the 
> interior of an open source effort. Perhaps a standard test suite for 
> Python? Perhaps co-ordinated upgrade days? Perhaps sterner control over 
> the standard Python library?
> 

No, no, no, absolutely not. There is *no reason whatsoever* to have
multiple versions of Python on a machine, unless that is specifically
what you want for development purposes, etc.

> Then the exe tools. With py2exe I ended up with the tcl library in my 
> 'exe' package when compiling a command line tool! I don't know how many 
> megabytes I had to distribute. I didn't bother. I then found exemaker:
> 
> http://effbot.org/downloads/index.cgi/exemaker-1.2-20041012.zip/README
> 

If py2exe is anything like McMillan Installer, then whether to include
Tcl/TK is simply a command line option - it's set to 'on' by default due
to TkInter being the de-facto GUI library for Python for a long, long
time.

You've have made a number of valid and well-reasoned points in your
posts on this thread, but IMHO this one is just nit-picking. I think
you're just going to have to accept that the process of developing,
distributing and maintaining software to a 'professional' standard is
damned hard work, and then just make a decision as to whether to live
with that or not.

I must say, though, that I am enjoying this thread - it's probably the
most vigorous and refreshing discussion we've had on here for months,
well done Norman! ;-)

-- 

Regards

Phil Edwards
Brighton, UK

Re: [Pythoncard-users] Re: Python distribution problems

[Kevin A. <al...@se...>]

On Apr 5, 2005, at 12:48 AM, normanwinn wrote:

> ka wrote:
>> Secondly, once we have a viable 1.x release, I would like to have a 
>> single installer option for Python, wxPython, and PythonCard on the 
>> Windows platform
>
> The very fact that you should need to contemplate this demonstrates 
> the severity of the problem. I already have versions of Python that 
> came with Zope, with Open Office, then I'll have another with 
> PythonCard and another with Dabo. Where will this stop? Each time I 
> want to upgrade I end up upgrading n versions of Python? This is 
> folly.
>
> What is the alternative? I can't have an answer as I am not at the 
> interior of an open source effort. Perhaps a standard test suite for 
> Python? Perhaps co-ordinated upgrade days? Perhaps sterner control 
> over the standard Python library?
>
> Then the exe tools. With py2exe I ended up with the tcl library in my 
> 'exe' package when compiling a command line tool! I don't know how 
> many megabytes I had to distribute. I didn't bother. I then found 
> exemaker:
>
> http://effbot.org/downloads/index.cgi/exemaker-1.2-20041012.zip/README
>
> but this, while being very handy on a system that has Python, is not a 
> standalone exe so can't be distributed.
>
> Please accept that I am not knocking (does that translate into 
> American). I hope my observations can contribute to a process that 
> will make Python tools available to all,
>
> Norman Winn
>

Actually, what I was talking about was more like an uber installer that 
would install Python, wxPython, and PythonCard in one shot, so people 
didn't have to download up to 3 different EXEs and run each installer 
separately. Another way to think of it would be Python that included 
wxPython and PythonCard as part of the distribution. This wouldn't be a 
special copy of Python like you have with some Zope/Plone and 
OpenOffice installs. Furthermore, the individual PythonCard release 
zip, tar.gz, and EXE installer would still be there. I'll be adding a 
Mac disk image installer of the PythonCard distribution as soon as I 
figure that one out. :)

This is a separate issue from building standalones for end-users. 
py2exe and py2app both do their best to figure out required modules. In 
the case of PythonCard, there is an import of the Image (PIL) module to 
support easy display of PIL images in PythonCard apps, so a generic 
standalone build using py2exe will bring in PIL and thus tkinter and 
its Tcl code. But it is simple enough to exclude modules and libraries 
that you know you're app doesn't use and this is even documented in the 
minimalStandalone example. The standaloneBuilder tool will likely have 
options for excluding common extra libs that most apps wouldn't use.

One of the biggest problems with all standalone applications is simply 
the size of the distribution. It is definitely nicer if you're able to 
just distribute the plain Python code of a normal PythonCard 
application, so in a controlled environment I would recommend that 
people go ahead and install the base Python, wxPython, and PythonCard 
packages, especially in a computer lab or enterprise installation.

On Windows, if there is a security concern over people double-clicking 
a .py, .pyw, .pyc, .pyo, etc. file then it is simple enough to remove 
that file association. A lnk file can be used to provide a full path to 
Python and the executable script with any command-line args, so that 
can be used instead of a double-clickable exe.

ka

Re: [Pythoncard-users] Python distribution problems

[Alex T. <al...@tw...>]

Schollnick, Benjamin wrote:

>
>I am unclear on what you are suggesting they are basing their decisions
>on?  (The quote does not include it)  Presumably on the fact that they
>need to instead Python, WxPython, and PythonCard?  Windows programmers
>are fully aware of dependencies...  .Net anyone?  
>
True - they are aware of them - but that doesn't mean they like them. I 
think it would be pretty cool to have the *option* of a single download 
and install to do Python, wxPython and Pythoncard in one easy operation. 
I have no idea how easy it would be to create that - but I suspect it 
would overcome some people's concerns about the complexity of getting 
started with Pythoncard.

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 30/03/2005

Re: [Pythoncard-users] Python distribution problems

[Kevin A. <al...@se...>]

On Apr 4, 2005, at 10:03 AM, Alex Tweedly wrote:

> Schollnick, Benjamin wrote:
>
>>
>> I am unclear on what you are suggesting they are basing their 
>> decisions
>> on?  (The quote does not include it)  Presumably on the fact that they
>> need to instead Python, WxPython, and PythonCard?  Windows programmers
>> are fully aware of dependencies...  .Net anyone?
> True - they are aware of them - but that doesn't mean they like them. 
> I think it would be pretty cool to have the *option* of a single 
> download and install to do Python, wxPython and Pythoncard in one easy 
> operation. I have no idea how easy it would be to create that - but I 
> suspect it would overcome some people's concerns about the complexity 
> of getting started with Pythoncard.
>

First of all, I just want to make sure everyone actually found the 
install instructions at:

http://pythoncard.sourceforge.net/installation.html

Those are step by step and are supposed to be bullet proof. If there is 
a problem with them, like needing more images, more explanation at a 
particular step, please provide specifics on the needed changes.

Secondly, once we have a viable 1.x release, I would like to have a 
single installer option for Python, wxPython, and PythonCard on the 
Windows platform; Robin Dunn and I talked about doing this almost four 
years ago, but it doesn't make any sense until the parts of the big 
package are at a stable point like the combo of Python 2.3.5, wxPython 
2.6, PythonCard 1.0, etc. On the Mac, it will just be wxPython and 
PythonCard, since Macs already include Python. Given the various 
versions and combinations of Python and wxPython, the single installer 
will only support one combination. If possible, we'll do the same for 
Linux.

The installer scripts for py2exe (Windows) and py2app (Mac) are almost 
identical, in fact, Bob Ippolito sent me a script variation to deal 
with both in a single script. So, once the new standaloneBuilder tool 
is updated to support py2exe and py2app creating PythonCard standalones 
should be relatively painless. At Pycon, Bob fixed an earlier problem 
with how py2app renames the startup module, so people that have had 
problems with py2app should find that the latest version in cvs works 
correctly now with PythonCard; I don't know if/when he will have a new 
release of that outside of cvs.

ka

Re: [Pythoncard-users] Python distribution problems

[Phil E. <ph...@li...>]

On Mon, 2005-04-04 at 18:25, Kevin Altis wrote:

> The installer scripts for py2exe (Windows) and py2app (Mac) are almost 
> identical, in fact, Bob Ippolito sent me a script variation to deal 
> with both in a single script. So, once the new standaloneBuilder tool 
> is updated to support py2exe and py2app creating PythonCard standalones 
> should be relatively painless. At Pycon, Bob fixed an earlier problem 

I'll need some help with this, as I have no experience with py2exe - my
current code relies entirely on McMillan Installer and Inno Setup. I'm
still working on adding the finishing touches to standaloneBuilder and I
expect to be checking in the finished version towards the end of this
week.

I'm just about to go off and sign up to the Pythoncard-devel mailing
list, so I'll post an announcement there when I think it's ready.

-- 

Regards

Phil Edwards
Brighton, UK

Re: [Pythoncard-users] Python distribution problems

[Steve C. <stn...@xm...>]

Alex Tweedly wrote:
> Schollnick, Benjamin wrote:
> 
> >
> >I am unclear on what you are suggesting they are basing their decisions
> >on?  (The quote does not include it)  Presumably on the fact that they
> >need to instead Python, WxPython, and PythonCard?  Windows programmers
> >are fully aware of dependencies...  .Net anyone?  
> >
> True - they are aware of them - but that doesn't mean they like them. I 
> think it would be pretty cool to have the *option* of a single download 
> and install to do Python, wxPython and Pythoncard in one easy operation. 
> I have no idea how easy it would be to create that - but I suspect it 
> would overcome some people's concerns about the complexity of getting 
> started with Pythoncard.

So, something similar to the Enthought Python distribution?

    http://www.enthought.com/downloads/downloads.htm

I'm not sure how much work was required to bundle all those into a single
distribution, or how often they update the entire package. 

As someone mentioned down-thread, tracking all the options and
dependencies and creating distributions will be a big job.


What about some sort of wizard interface that would step the user
through the process? Sort of like the cygwin setup script. e.g. a tool
written in PythonCard that'd allow the user to select versions of
python/wxPython, unicode flavors, etc. 

Rather than PythonCard distributing a huge bundle, the PythonCard
website would distribute a URLs to the 'good' installers, download the
binaries via urllib and launch the install process for
python/wxpython/pythoncard.

Still a big job, but it might be more managable than the alternative.


-Steve

Re: [Pythoncard-users] Python distribution problems

[Ed L. <ed...@le...>]

On Apr 4, 2005, at 6:24 PM, Steve Christensen wrote:

> I'm not sure how much work was required to bundle all those into a 
> single
> distribution, or how often they update the entire package.

	It's pretty straightforward in Windows, using py2exe and InnoSetup - 
that's how I created the standalone runtime for Dabo. Ieven bundle the 
Dabo code seperately, so that it isn't compiled into the DLLs, so that 
people can update the Dabo classes as often as we do.

	It's much harder under Linux, due to dynamic libraries. I've tried 
building everything statically, and it simply doesn't seem possible. 
Fortunately most Linux users aren't too afraid of compiling stuff on 
their own.

	I haven't spent much time trying this for the Mac yet, but from what 
I've read, it's somewhere in between, given that you can assume certain 
base installs (Panther, Jaguar, etc.) and build for these.

	FWIW, the Dabo runtime for Windows will run nearly any wxPython 
program, including PythonCard. Feel free to use it as base for 
PythonCard distribution, if you like.

      ___/
     /
    __/
   /
  ____/
  Ed Leafe
  http://leafe.com/
  http://dabodev.com/