[GRASS-dev] PIL needs to be a GRASS dependency

GRASS GIS GRASS GIS developer
1

Since the Python Imaging Library (PIL) is needed to fully use the cartographic composer, this needs to be a dependency of GRASS, just like numpy. Since both of these packages do not come with the standard Python distribution, it would be good if we could package/bundle them in binary distributions. Otherwise, stuff will not work. This is needed for GRASS 6.4 as well as GRASS 7. I’m not sure what is needed for this to happen, but it will be helpful to users (and very frustrating to them if not there).

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

2

Well, I have Mac PIL and Numpy packages. I don't think Python modules are something you should be bundling in GRASS binaries, since users may already have them installed.

If the GRASS installer (at least on OS X) could check for dependencies it wouldn't such a problem, since GRASS would simply not install and tell you what is missing. That's been a low priority on my list to do for a while - add some mechanism for extending the installer creation in the bindist target, to allow packagers to specify dependency checks (it's not something that's easy or practical to do automatically based on configured dependencies).

On Nov 22, 2011, at 9:16 PM, Michael Barton wrote:

Since the Python Imaging Library (PIL) is needed to fully use the cartographic composer, this needs to be a dependency of GRASS, just like numpy. Since both of these packages do not come with the standard Python distribution, it would be good if we could package/bundle them in binary distributions. Otherwise, stuff will not work. This is needed for GRASS 6.4 as well as GRASS 7. I'm not sure what is needed for this to happen, but it will be helpful to users (and very frustrating to them if not there).

Michael

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence....

- the wisdom of Tarzan

3

Thanks William.

Your package makes this work OK. I had only been able to install PIL for Python 2.7, but had compiled GRASS 7 with Python 2.6. This left the cartographic composer only partly workable. This could be a problem for others. These extra python packages not only need to be installed, but need to be installed for whatever version of Python that GRASS is compiled with. This is a similar issue to what we ran into with wxPython. I don't know how this is handled in Windows, but could potentially be a problem there too.

I'm not sure how to best handle this.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Nov 22, 2011, at 9:05 PM, William Kyngesburye wrote:

Well, I have Mac PIL and Numpy packages. I don't think Python modules are something you should be bundling in GRASS binaries, since users may already have them installed.

If the GRASS installer (at least on OS X) could check for dependencies it wouldn't such a problem, since GRASS would simply not install and tell you what is missing. That's been a low priority on my list to do for a while - add some mechanism for extending the installer creation in the bindist target, to allow packagers to specify dependency checks (it's not something that's easy or practical to do automatically based on configured dependencies).

On Nov 22, 2011, at 9:16 PM, Michael Barton wrote:

Since the Python Imaging Library (PIL) is needed to fully use the cartographic composer, this needs to be a dependency of GRASS, just like numpy. Since both of these packages do not come with the standard Python distribution, it would be good if we could package/bundle them in binary distributions. Otherwise, stuff will not work. This is needed for GRASS 6.4 as well as GRASS 7. I'm not sure what is needed for this to happen, but it will be helpful to users (and very frustrating to them if not there).

Michael

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence....

- the wisdom of Tarzan

4

On Nov 23, 2011, at 12:03 AM, Michael Barton wrote:

Thanks William.

Your package makes this work OK. I had only been able to install PIL for Python 2.7, but had compiled GRASS 7 with Python 2.6. This left the cartographic composer only partly workable. This could be a problem for others.

Actually, this is am oversight by me. While I install for python 2.6 AND 2.7 on Lion with my frameworks (osgeo.gdal, pysqlite), I forgot to do the same for non-framework python modules. Easily fixed.

These extra python packages not only need to be installed, but need to be installed for whatever version of Python that GRASS is compiled with. This is a similar issue to what we ran into with wxPython. I don't know how this is handled in Windows, but could potentially be a problem there too.

I'm not sure how to best handle this.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Nov 22, 2011, at 9:05 PM, William Kyngesburye wrote:

Well, I have Mac PIL and Numpy packages. I don't think Python modules are something you should be bundling in GRASS binaries, since users may already have them installed.

If the GRASS installer (at least on OS X) could check for dependencies it wouldn't such a problem, since GRASS would simply not install and tell you what is missing. That's been a low priority on my list to do for a while - add some mechanism for extending the installer creation in the bindist target, to allow packagers to specify dependency checks (it's not something that's easy or practical to do automatically based on configured dependencies).

On Nov 22, 2011, at 9:16 PM, Michael Barton wrote:

Since the Python Imaging Library (PIL) is needed to fully use the cartographic composer, this needs to be a dependency of GRASS, just like numpy. Since both of these packages do not come with the standard Python distribution, it would be good if we could package/bundle them in binary distributions. Otherwise, stuff will not work. This is needed for GRASS 6.4 as well as GRASS 7. I'm not sure what is needed for this to happen, but it will be helpful to users (and very frustrating to them if not there).

Michael

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence....

- the wisdom of Tarzan

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.

5

Michael Barton wrote:

Since the Python Imaging Library (PIL) is needed to fully use the
cartographic composer, this needs to be a dependency of GRASS, just like
numpy. Since both of these packages do not come with the standard Python
distribution, it would be good if we could package/bundle them in binary
distributions. Otherwise, stuff will not work. This is needed for GRASS
6.4 as well as GRASS 7. I'm not sure what is needed for this to happen,
but it will be helpful to users (and very frustrating to them if not
there).

We should not be trying to bundle either Python or any of its
libraries.

If the user already has a suitable version of Python on their system,
GRASS should use it (in 7.0, there isn't really any choice, as Windows
will have associated the .py extension with the installed version),
and any libraries will need to be compatible with that version (i.e.
if the user has Python 2.7, 64-bit, providing libararies for 2.6 or
32-bit won't work).

Also, GUI components should fail gracefully in the absence of required
libraries, i.e. a lack of PIL should result in the cartographic
composer not working (at worst), not the GUI not working.

BTW: what does PIL offer that wxImage doesn't? wxPython is already a
required dependency, so PIL seems a bit gratuitous. Apart from its
image format readers and writers, most of PIL'S other functionality is
easily (and often better) performed using NumPy.

--
Glynn Clements <glynn@gclements.plus.com>

6

On Wed, Nov 23, 2011 at 8:31 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Michael Barton wrote:

Since the Python Imaging Library (PIL) is needed to fully use the
cartographic composer, this needs to be a dependency of GRASS, just like
numpy. Since both of these packages do not come with the standard Python
distribution, it would be good if we could package/bundle them in binary
distributions. Otherwise, stuff will not work. This is needed for GRASS
6.4 as well as GRASS 7. I'm not sure what is needed for this to happen,
but it will be helpful to users (and very frustrating to them if not
there).

We should not be trying to bundle either Python or any of its
libraries.

If the user already has a suitable version of Python on their system,
GRASS should use it (in 7.0, there isn't really any choice, as Windows
will have associated the .py extension with the installed version),
and any libraries will need to be compatible with that version (i.e.
if the user has Python 2.7, 64-bit, providing libararies for 2.6 or
32-bit won't work).

Also, GUI components should fail gracefully in the absence of required
libraries, i.e. a lack of PIL should result in the cartographic
composer not working (at worst), not the GUI not working.

BTW: what does PIL offer that wxImage doesn't? wxPython is already a
required dependency, so PIL seems a bit gratuitous. Apart from its
image format readers and writers, most of PIL'S other functionality is
easily (and often better) performed using NumPy.

Map Composer needs PIL to read PostScript (created by ps.map). If it's
not available, 'preview' is not possible, however the rest of composer
works.

Anna

--
Glynn Clements <glynn@gclements.plus.com>

7

Anna Kratochvílová wrote:

> BTW: what does PIL offer that wxImage doesn't? wxPython is already a
> required dependency, so PIL seems a bit gratuitous. Apart from its
> image format readers and writers, most of PIL'S other functionality is
> easily (and often better) performed using NumPy.

Map Composer needs PIL to read PostScript (created by ps.map).

Like most image libraries, PIL uses Ghostscript to render PostScript
to a raster image format (in the case of PIL, PPM), then reads the
resulting image.

PostScript support doesn't, in itself, warrant the addition of PIL
(which has a binary component, meaning that it has to match the the
version and architecture of the installed Python).

--
Glynn Clements <glynn@gclements.plus.com>