[GRASS-dev] dateutil dependency killing GRASS 7

GRASS GRASS developer
1

A couple of things here.

  1. We need to be able to bundle dateutil or to have it bundled with Mac frameworks. Otherwise, temporal GIS doesn’t work apparently.
  2. The lack of dateutil for TGIS should not shut down the entire GUI. This is a serious problem. It could make part or all of TGIS not functional, but it is NOT needed for anything else. So it should not kill the entire interface. It needs to be walled off somehow.
  3. I thought that adding new dependencies was something that should be brought up in the dev group, at the very least to make everyone aware of it.

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

Hi Michael,
sorry to introduce something painful as a python-dateutil dependency.
My fault. I should have discussed this on the list indeed.

I have completely removed the dateutil dependency from the temporal
GIS in r53435. For now
only two types of calendar time stings are supported for parsing.

ISO dates and ISO dates with time:

2001-01-01
2001-01-01 12:30:00

Time zones are not supported.

You can extend the datetime string parser that is in use instead of
the dateutil parser in:
lib/python/temporal/datetime_math.py in function string_to_datetime()
for your needs.

Best regards
Soeren

2012/10/17 Michael Barton <Michael.Barton@asu.edu>:

A couple of things here.

1. We need to be able to bundle dateutil or to have it bundled with Mac
frameworks. Otherwise, temporal GIS doesn't work apparently.
2. The lack of dateutil for TGIS should not shut down the entire GUI. This
is a serious problem. It could make part or all of TGIS not functional, but
it is NOT needed for anything else. So it should not kill the entire
interface. It needs to be walled off somehow.
3. I thought that adding new dependencies was something that should be
brought up in the dev group, at the very least to make everyone aware of it.

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

3

Thanks very much Soren.

Perhaps datetutil is a great thing to have, but until we get the packaging thing worked work it is a big problem at least for Macs. It works without a hitch on my Mac, but I don't know how or where I got dateutil.

I suggested that other Mac users install MatPlotLib (also a great piece of software, but not a GRASS dependency). But it seems that it is not helping at least for some users, and GRASS 7 cannot be launched with a missing dateutil error.

I will compile and test your update as soon as possible (probably tonight). I and other Mac users (and maybe Windows users too?) appreciate your quick response.

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 Oct 17, 2012, at 6:21 AM, Sören Gebbert <soerengebbert@googlemail.com>
wrote:

Hi Michael,
sorry to introduce something painful as a python-dateutil dependency.
My fault. I should have discussed this on the list indeed.

I have completely removed the dateutil dependency from the temporal
GIS in r53435. For now
only two types of calendar time stings are supported for parsing.

ISO dates and ISO dates with time:

2001-01-01
2001-01-01 12:30:00

Time zones are not supported.

You can extend the datetime string parser that is in use instead of
the dateutil parser in:
lib/python/temporal/datetime_math.py in function string_to_datetime()
for your needs.

Best regards
Soeren

2012/10/17 Michael Barton <Michael.Barton@asu.edu>:

A couple of things here.

1. We need to be able to bundle dateutil or to have it bundled with Mac
frameworks. Otherwise, temporal GIS doesn't work apparently.
2. The lack of dateutil for TGIS should not shut down the entire GUI. This
is a serious problem. It could make part or all of TGIS not functional, but
it is NOT needed for anything else. So it should not kill the entire
interface. It needs to be walled off somehow.
3. I thought that adding new dependencies was something that should be
brought up in the dev group, at the very least to make everyone aware of it.

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

4

On Wed, Oct 17, 2012 at 2:42 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

Thanks very much Soren.

Perhaps datetutil is a great thing to have, but until we get the packaging thing worked work it is a big problem at least for Macs. It works without a hitch on my Mac, but I don't know how or where I got dateutil.

Just a simple question: could the /lib/datetime already available in
GRASS be used?
http://grass.osgeo.org/programming7/structDateTime.html
It also knows about time zones.

Markus

5

Hi,

2012/10/17 Markus Neteler <neteler@osgeo.org>:

On Wed, Oct 17, 2012 at 2:42 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

Thanks very much Soren.

Perhaps datetutil is a great thing to have, but until we get the packaging thing worked work it is a big problem at least for Macs. It works without a hitch on my Mac, but I don't know how or where I got dateutil.

Just a simple question: could the /lib/datetime already available in
GRASS be used?
http://grass.osgeo.org/programming7/structDateTime.html
It also knows about time zones.

Unfortunately not. The string parser of the grass datetime library
only understands the grass specific datum format which is not ISO
compliant. Besides of that the datetime module in Python is much more
powerful and automatically transformed into the correct SQL object in
SELECT, INSERT and UPDATE operations. Also comparison functionality
(<=,>=, !=, ==) of Python datetime objects is easier to use,
especially when the algorithms should work with absolute and relative
(integer objects) time.

The reason why i introduced the dateutil module was to have a
sophisticated time string parser that understands plenty of datum
formats inclusively the correct use of the abstract Python datetime
time zone object. Now we have to do it our-self.

Best regards
Soeren

Markus

6

On 17/10/12 13:21, Sören Gebbert wrote:

Hi Michael,
sorry to introduce something painful as a python-dateutil dependency.
My fault. I should have discussed this on the list indeed.

I have completely removed the dateutil dependency from the temporal
GIS in r53435. For now
only two types of calendar time stings are supported for parsing.

Do you really have to remove it completely ? Can't you check for its presence and if not present fall back on the basic date version ? And put a hint in the manuals about its installation being strongly recommended ?

Moritz

7

Hi,

2012/10/17 Moritz Lennert <mlennert@club.worldonline.be>:

On 17/10/12 13:21, Sören Gebbert wrote:

Hi Michael,
sorry to introduce something painful as a python-dateutil dependency.
My fault. I should have discussed this on the list indeed.

I have completely removed the dateutil dependency from the temporal
GIS in r53435. For now
only two types of calendar time stings are supported for parsing.

Do you really have to remove it completely ? Can't you check for its
presence and if not present fall back on the basic date version ? And put a
hint in the manuals about its installation being strongly recommended ?

I was thinking about this, but skipped the idea because of my lack of
time to implement it.

Best regards
Soeren

Moritz

8

This seems like a good idea. Gives us time to think about the value and costs of using and bundling dateutil.

Michael Barton
School of Human Evolution &Social Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

On Oct 17, 2012, at 11:34 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 17/10/12 13:21, Sören Gebbert wrote:

Hi Michael,
sorry to introduce something painful as a python-dateutil dependency.
My fault. I should have discussed this on the list indeed.

I have completely removed the dateutil dependency from the temporal
GIS in r53435. For now
only two types of calendar time stings are supported for parsing.

Do you really have to remove it completely ? Can't you check for its presence and if not present fall back on the basic date version ? And put a hint in the manuals about its installation being strongly recommended ?

Moritz

9

I just tried grass7 binary compiled by Michael and the isosurfaces
indeed crash the gui. The attached screenshot shows the error message.

I did not have time to compile 6.4.3 and 7 on MasOSX 10.7.5 myself yet,
but as I mentioned before I have the isosurfaces running in GRASS7
compiled in august on 10.6 .

Helena

Also, When switching to 3d for the first time I get and error, but it
ran after switching to 2d and 3d again:

Starting 3D view mode...
Traceback (most recent call last):
  File "/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc
/gui/wxpython/mapdisp/toolbars.py", line 231, in
OnSelectTool

self.parent.AddNviz()
  File "/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc
/gui/wxpython/mapdisp/frame.py", line 299, in AddNviz

Map = self.Map, tree = self.tree, lmgr = self._layerManager)
  File "/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc
/gui/wxpython/nviz/mapwindow.py", line 154, in __init__

self.decoration['arrow']['size'] = self._getDecorationSize()
  File "/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc
/gui/wxpython/nviz/mapwindow.py", line 1177, in
_getDecorationSize

size = self._display.GetLongDim() / 8.
AttributeError
:
'NoneType' object has no attribute 'GetLongDim'

On Wed, Oct 17, 2012 at 3:09 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

This seems like a good idea. Gives us time to think about the value and costs of using and bundling dateutil.

Michael Barton
School of Human Evolution &Social Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

On Oct 17, 2012, at 11:34 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 17/10/12 13:21, Sören Gebbert wrote:

Hi Michael,
sorry to introduce something painful as a python-dateutil dependency.
My fault. I should have discussed this on the list indeed.

I have completely removed the dateutil dependency from the temporal
GIS in r53435. For now
only two types of calendar time stings are supported for parsing.

Do you really have to remove it completely ? Can't you check for its presence and if not present fall back on the basic date version ? And put a hint in the manuals about its installation being strongly recommended ?

Moritz

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

--
Helena Mitasova
Associate Professor
Department of Marine, Earth and Atmospheric Sciences
North Carolina State University
1125 Jordan Hall
NCSU Box 8208
Raleigh, NC 27695-8208
http://skagit.meas.ncsu.edu/~helena/

email: hmitaso@ncsu.edu
ph: 919-513-1327 (no voicemail)
fax 919 515-7802

(attachments)

grass7voxelcrash.png

10

Moritz Lennert wrote:

> sorry to introduce something painful as a python-dateutil dependency.
> My fault. I should have discussed this on the list indeed.
>
> I have completely removed the dateutil dependency from the temporal
> GIS in r53435. For now
> only two types of calendar time stings are supported for parsing.

Do you really have to remove it completely ? Can't you check for its
presence and if not present fall back on the basic date version ? And
put a hint in the manuals about its installation being strongly
recommended ?

Then it would become a /de facto/ mandatory dependency.

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

11

Here is some additional info on the NVIZ crash.

In the current version of GRASS, I can display a horizontal slice. BUT if I go to change the configuration of the slice (reduce it in the horizontal x or y direction or change the tilt), it crashes the GUI.

Trying to display a vertical slice or isosurface crashes the display.

In r48000 (and maybe in r50000 too), I can display a horizontal or vertical slice and manipulate its position. However, attempting to display an isosurface will crash the GUI.

I want to try r47000, but have not had a chance yet.

But the problem seems to be getting worse over the past year--worked OK about 15 months ago, partly worked 12 months ago, does not work by 3 months ago and maybe earlier.

I tried compiling without building for OSX 10.6 (OSX 10.8 and python 12.7) and it is just as bad. I have not tried building for a single architecture (32 or 64 bit) yet.

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 Oct 17, 2012, at 3:17 PM, Helena Mitasova <hmitaso@ncsu.edu> wrote:

I just tried grass7 binary compiled by Michael and the isosurfaces
indeed crash the gui. The attached screenshot shows the error message.

I did not have time to compile 6.4.3 and 7 on MasOSX 10.7.5 myself yet,
but as I mentioned before I have the isosurfaces running in GRASS7
compiled in august on 10.6 .

Helena

Also, When switching to 3d for the first time I get and error, but it
ran after switching to 2d and 3d again:

Starting 3D view mode...
Traceback (most recent call last):
File "/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc
/gui/wxpython/mapdisp/toolbars.py", line 231, in
OnSelectTool

self.parent.AddNviz()
File "/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc
/gui/wxpython/mapdisp/frame.py", line 299, in AddNviz

Map = self.Map, tree = self.tree, lmgr = self._layerManager)
File "/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc
/gui/wxpython/nviz/mapwindow.py", line 154, in __init__

self.decoration['arrow']['size'] = self._getDecorationSize()
File "/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc
/gui/wxpython/nviz/mapwindow.py", line 1177, in
_getDecorationSize

size = self._display.GetLongDim() / 8.
AttributeError
:
'NoneType' object has no attribute 'GetLongDim'

On Wed, Oct 17, 2012 at 3:09 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

This seems like a good idea. Gives us time to think about the value and costs of using and bundling dateutil.

Michael Barton
School of Human Evolution &Social Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

On Oct 17, 2012, at 11:34 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 17/10/12 13:21, Sören Gebbert wrote:

Hi Michael,
sorry to introduce something painful as a python-dateutil dependency.
My fault. I should have discussed this on the list indeed.

I have completely removed the dateutil dependency from the temporal
GIS in r53435. For now
only two types of calendar time stings are supported for parsing.

Do you really have to remove it completely ? Can't you check for its presence and if not present fall back on the basic date version ? And put a hint in the manuals about its installation being strongly recommended ?

Moritz

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
grass-dev Info Page

--
Helena Mitasova
Associate Professor
Department of Marine, Earth and Atmospheric Sciences
North Carolina State University
1125 Jordan Hall
NCSU Box 8208
Raleigh, NC 27695-8208
http://skagit.meas.ncsu.edu/~helena/

email: hmitaso@ncsu.edu
ph: 919-513-1327 (no voicemail)
fax 919 515-7802
<grass7voxelcrash.png>

12

On 17/10/12 22:20, Glynn Clements wrote:

Moritz Lennert wrote:

sorry to introduce something painful as a python-dateutil dependency.
My fault. I should have discussed this on the list indeed.

I have completely removed the dateutil dependency from the temporal
GIS in r53435. For now
only two types of calendar time stings are supported for parsing.

Do you really have to remove it completely ? Can't you check for its
presence and if not present fall back on the basic date version ? And
put a hint in the manuals about its installation being strongly
recommended ?

Then it would become a /de facto/ mandatory dependency.

Is it illegitimate to propose basic functionality, thus allowing the user to use the modules, but forcing them to be more rigorous about date format, etc, but offer the user a way to more "comfort" by installing an additional dependency ?

If the use of dateutil creates a whole lot of new, additional functionality (beyond increase in comfort) which you don't get without, then I agree with you.

Moritz

13

Hi Moritz,
i would like to share with you a conversation about this topic that i
had with Pietro offlist.

[snip]

Then it would become a /de facto/ mandatory dependency.

Is it illegitimate to propose basic functionality, thus allowing the user to
use the modules, but forcing them to be more rigorous about date format,
etc, but offer the user a way to more "comfort" by installing an additional
dependency ?

If the use of dateutil creates a whole lot of new, additional functionality
(beyond increase in comfort) which you don't get without, then I agree with
you.

Moritz

Hi Pietro,
its not only about the simplicity how to handle imports in Python ...
well i wasn't aware that its so easy. :slight_smile:

I had in mind to allow the user to select the dateutil dependency at
compile time so he is aware if grass is build with or without
dateutil, listed in the summary of the configure script. So i need to
add a configure check for dateutil ... . Besides of that, when we make
it optional, we will have the situation of users that have dateutil
and user that don't. This will result in help/tutorial/scripts that
work only with dateutil but not without ... IMHO a mess. Since
dateutil causes obviously so much trouble on Mac OS and Windows (i
wasn't aware of that since i am an ignorant Linux person) i will only
add it if it works on these systems out of the box.

Good night
Sören

ps.:
May i share your thoughts on the list?

2012/10/17 Pietro <peter.zamb@gmail.com>:

Hi Sören,

On Wed, Oct 17, 2012 at 6:59 PM, Sören Gebbert
<soerengebbert@googlemail.com> wrote:
[snip]

Do you really have to remove it completely ? Can't you check for its
presence and if not present fall back on the basic date version ? And put a
hint in the manuals about its installation being strongly recommended ?

I was thinking about this, but skipped the idea because of my lack of
time to implement it.

maybe I miss the point...

I have written a small patch that check if dateutil is available
prease have a look to the attached file.

good night!

pietro

14

Since
dateutil causes obviously so much trouble on Mac OS and Windows (i
wasn't aware of that since i am an ignorant Linux person) i will only
add it if it works on these systems out of the box.

regarding the windows-side of the world, within osgeo4w, dateutil is
available by matplotlib and already activated for the nightly
wingrass7-standalone builds.

for the osgeo4w-wingrass7, dateutil can be activated as dependency and
installed automatically.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/dateutil-dependency-killing-GRASS-7-tp5009133p5009540.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

15

On 18/10/12 10:13, Sören Gebbert wrote:

I had in mind to allow the user to select the dateutil dependency at
compile time so he is aware if grass is build with or without
dateutil,

How does a python module play a role at build-time ? You could build grass on a system that doesn't have dateutil, but then run it on one that does and it should work...

listed in the summary of the configure script. So i need to
add a configure check for dateutil ... . Besides of that, when we make
it optional, we will have the situation of users that have dateutil
and user that don't. This will result in help/tutorial/scripts that
work only with dateutil but not without ... IMHO a mess.

That's the real question. If functionality is so different that docs have to be fundamentally different then it's an issue, IMHO. Is that the case ?

If however, dateutil just provides more convenient date input options, can't you just write the docs with having non-dateutil users in mind, with a hint somewhere about what using dateutil offers as extras ?

ps.:
May i share your thoughts on the list?

We are on the list :wink:

Moritz

16

I just got some time to briefly look at this - dateutil IS in OS X Python, 2.6 and 2.7. (checked OS X Lion and Snow Leopard)

So if Mac users are having problems with a missing dateutil, then maybe they have another Python installed, like from python.org or MacPorts or Homebrew. Then it's really a problem of installing dateutil in that other distribution.

On Oct 17, 2012, at 2:09 PM, Michael Barton wrote:

This seems like a good idea. Gives us time to think about the value and costs of using and bundling dateutil.

Michael Barton
School of Human Evolution &Social Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

On Oct 17, 2012, at 11:34 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 17/10/12 13:21, Sören Gebbert wrote:

Hi Michael,
sorry to introduce something painful as a python-dateutil dependency.
My fault. I should have discussed this on the list indeed.

I have completely removed the dateutil dependency from the temporal
GIS in r53435. For now
only two types of calendar time stings are supported for parsing.

Do you really have to remove it completely ? Can't you check for its presence and if not present fall back on the basic date version ? And put a hint in the manuals about its installation being strongly recommended ?

Moritz

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

The equator is so long, it could encircle the earth completely once.

17

Moritz Lennert wrote:

>> Do you really have to remove it completely ? Can't you check for its
>> presence and if not present fall back on the basic date version ? And
>> put a hint in the manuals about its installation being strongly
>> recommended ?
>
> Then it would become a /de facto/ mandatory dependency.
>

Is it illegitimate to propose basic functionality, thus allowing the
user to use the modules, but forcing them to be more rigorous about date
format, etc, but offer the user a way to more "comfort" by installing an
additional dependency ?

It depends. If the end result is that people start sharing scripts or
distributing data files which only work if you have dateutil
installed, then it's a problem.

IMHO, there should be one "standard" for date formats. Either that
standard includes the formats which require dateutil to parse, in
which case dateutil is a mandatory dependency, or it doesn't, in which
case data which doesn't conform to the standard format should at a
minimum result in a visible warning.

Simply documenting the standard format while silently accepting
non-standard data is asking for trouble.

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

18

Are you sure it is there originally? Or is it present because you have installed other python apps like MatPlotLib?

Thinking about this, it is really odd that it would somehow stop the GUI from loading at startup. Is there some kind of test for dateutil that happens at startup?

Even if dateutil is missing, there should not be a crash or error until one of the modules that needs it is run and 'import datetuil' generates an error.

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 Oct 18, 2012, at 6:43 AM, William Kyngesburye <woklist@kyngchaos.com> wrote:

I just got some time to briefly look at this - dateutil IS in OS X Python, 2.6 and 2.7. (checked OS X Lion and Snow Leopard)

So if Mac users are having problems with a missing dateutil, then maybe they have another Python installed, like from python.org or MacPorts or Homebrew. Then it's really a problem of installing dateutil in that other distribution.

On Oct 17, 2012, at 2:09 PM, Michael Barton wrote:

This seems like a good idea. Gives us time to think about the value and costs of using and bundling dateutil.

Michael Barton
School of Human Evolution &Social Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

On Oct 17, 2012, at 11:34 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 17/10/12 13:21, Sören Gebbert wrote:

Hi Michael,
sorry to introduce something painful as a python-dateutil dependency.
My fault. I should have discussed this on the list indeed.

I have completely removed the dateutil dependency from the temporal
GIS in r53435. For now
only two types of calendar time stings are supported for parsing.

Do you really have to remove it completely ? Can't you check for its presence and if not present fall back on the basic date version ? And put a hint in the manuals about its installation being strongly recommended ?

Moritz

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

The equator is so long, it could encircle the earth completely once.

19

One more thing, when GRASS starts up now, there is the following message from the TGIS modules...

Default TGIS driver / database set to:
driver: sqlite
database: $GISDBASE/$LOCATION_NAME/PERMANENT/tgis.db

Where is this coming from? It seems pretty innocuous, though I'm not sure that this is needed as a message at startup. Is this coming from some kind of initialization module for TGIS that could be trying to do something with dateutil?

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 Oct 18, 2012, at 6:43 AM, William Kyngesburye <woklist@kyngchaos.com> wrote:

I just got some time to briefly look at this - dateutil IS in OS X Python, 2.6 and 2.7. (checked OS X Lion and Snow Leopard)

So if Mac users are having problems with a missing dateutil, then maybe they have another Python installed, like from python.org or MacPorts or Homebrew. Then it's really a problem of installing dateutil in that other distribution.

On Oct 17, 2012, at 2:09 PM, Michael Barton wrote:

This seems like a good idea. Gives us time to think about the value and costs of using and bundling dateutil.

Michael Barton
School of Human Evolution &Social Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

On Oct 17, 2012, at 11:34 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 17/10/12 13:21, Sören Gebbert wrote:

Hi Michael,
sorry to introduce something painful as a python-dateutil dependency.
My fault. I should have discussed this on the list indeed.

I have completely removed the dateutil dependency from the temporal
GIS in r53435. For now
only two types of calendar time stings are supported for parsing.

Do you really have to remove it completely ? Can't you check for its presence and if not present fall back on the basic date version ? And put a hint in the manuals about its installation being strongly recommended ?

Moritz

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

The equator is so long, it could encircle the earth completely once.

20

On Sun, Oct 21, 2012 at 6:58 AM, Michael Barton <Michael.Barton@asu.edu> wrote:

One more thing, when GRASS starts up now, there is the following message from the TGIS modules...

Default TGIS driver / database set to:
driver: sqlite
database: $GISDBASE/$LOCATION_NAME/PERMANENT/tgis.db

Where is this coming from?

I have fixed a debug level in
http://trac.osgeo.org/grass/changeset/53518
and no longer get that debug message.

Markus