Re: [Pythoncard-users] thoughts on PIL and external packages

[Andy T. <an...@cr...>]

Kevin Altis wrote:
> The more I look at PIL, the more I think we might want to use PIL as our
> native image format and any conversion required by wxPython for displaying
> bitmaps on screen would be hidden by our wrapper classes. Has anyone on the
> list done a lot of work with either wxPython wxImage/wxBitmap and/or PIL?
> The biggest initial complication I can see is that the PIL ImageDraw module
> http://www.pythonware.com/library/pil/handbook/imagedraw.htm
> appears to be less capable than the wxPython device context drawing
> routines, but I haven't actually used them yet, so I could be wrong. Perhaps
> it will be enough to simply provide easy translation between formats as I
> originally planned and continue to use native wxPython draw methods?!
> 
I'll leave that question and its resolution to other, more qualified, 
people. As the packager du jour though, I'll share my thoughts below;

> Part of the reason I'm bringing this up is that PIL is an external package
> that we wouldn't distribute with PythonCard, even if it was required. We
> might also need NumPy and other packages in the future. We're already
> relying on PyCrust.
> 
> PyCrust 0.6 was released earlier this week in a variety of formats:
> http://sourceforge.net/project/showfiles.php?group_id=31263
> 
> Given that PyCrust now uses distutils and provides a binary installer for
> win32, we should probably not include PyCrust in the PythonCardPrototype
> distribution, but simply point people towards the PyCrust distribution.

Yes, we probably should for the prototype. Once I've ironed out a couple 
of 'kinks' we will also have a binary installer for Win32. I should 
hopefully have an announcement early next week.

> 
> Any thoughts on this? It will complicate the installation of PythonCard,
> which already requires Python 2.1.x and wxPython 2.3.x, but it will make the
> PythonCardPrototype distribution more like other Python packages.

This is fine for the prototype but I think we should take an alternative 
approach when we approach the mythical 1.0 release. As PythonCard is 
intended to allow users to "develop graphical applications quickly and 
easily with a minimum of effort" we should plan to have an integrated 
installer. We should package up all of the components that comprise 
PythonCard and make them available in platform specific distributions 
(.exe, rpm, deb, etc.) That is probably a monster project in itself but 
we have plenty of time to work on it ;-)

> 
> Python sure could use a generic Debian-like installer for packages that
> pulls down the required packages from the web and handles installation, sort
> of a super distutils. I'm now expecting Roman to email and tell me that if I
> would have bothered to read the source I would see that this is the -u
> option of distutils. ;-)

Alas, having had a scout around the code I couldn't find that magical 
switch. This subject crops up on c.l.p on a regular basis and I think we 
are all agreed that we need a Pythonic version of CPAN (or Debian, which 
looks nicer to me). Sadly, no one (to my knowledge) has come up with a 
concrete proposal and implementation yet. Maybe someone should write a 
PEP? On that subject there are a couple of PEPs in the pipeline which 
should help the distributor's nightmare;

PEP 206 (batteries included) at 
http://python.sourceforge.net/peps/pep-0206.html is something we should 
be targetting. Making PythonCard part of a 'sumo' distribution is a good 
first step to becoming the defacto GUI development framework.

See also PEP 250 (Using site packages on Windows) at 
http://python.sourceforge.net/peps/pep-0250.html, which should help 
distributing modules somewhat by making the process on Windows more like 
Unix ones.
> 
> ka
> 
> 

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Hit me with your fax machine, baby" - Francis Dunnery, "Because I Can"