Re: [GRASS-dev] dateutil dependency killing GRASS 7
So this is still a new dependency, at least for some systems then. Michael Barton School of Human Evolution &Social Change Center for Social Dynamics & Complexity Arizona State University ...Sent from my iPad On Oct 24, 2012, at 1:26 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> So now I'm confused. Does it come with the Python that comes with >> Macs and can be installed (normal install) on Windows? Or is it >> something that needs to be installed separately? > > It isn't part of Python itself, i.e. it isn't in the Python source > tree, or in any Python package built from it. It isn't in the official > Windows installer, or Gentoo's dev-lang/python package. On Gentoo, > it's in dev-python/python-dateutil. Regardless of platform, it will > get installed under site-packages. > > -- > Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
>So it comes on Mac but not on Windows? concerning windows, it's there in the osgeo4w-(build)-environment offered by matplotlib. - best regards Helmut -- View this message in context: http://osgeo-org.1560.n6.nabble.com/dateutil-dependency-killing-GRASS-7-tp5009133p5010816.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
Michael Barton wrote: > So now I'm confused. Does it come with the Python that comes with > Macs and can be installed (normal install) on Windows? Or is it > something that needs to be installed separately? It isn't part of Python itself, i.e. it isn't in the Python source tree, or in any Python package built from it. It isn't in the official Windows installer, or Gentoo's dev-lang/python package. On Gentoo, it's in dev-python/python-dateutil. Regardless of platform, it will get installed under site-packages. -- Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
So it comes on Mac but not on Windows? I think I now remember that one of the first students who reported problems was on Windows. Another was on the Mac, but maybe it is because she installed MacPython by mistake. 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 23, 2012, at 4:51 PM, William Kyngesburye wrote: > Well, on the Mac, it "comes with" the Python Apple provides, but as Glynn > says it is not a part of the standard Python package. It looks like it's > been included since Python 2.5 on OS X. > > On Oct 23, 2012, at 12:23 PM, Michael Barton wrote: > >> So now I'm confused. Does it come with the Python that comes with Macs and >> can be installed (normal install) on Windows? Or is it something that needs >> to be installed separately? >> >> Michael >> __ >> C. Michael Barton >> Director, Center for Social Dynamics & Complexity >> Professor of Anthropology, School of Human Evolution & Social Change >> Arizona State University >> Tempe, AZ 85287-2402 >> USA >> >> voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) >> fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) >> www: http://csdc.asu.edu, http://shesc.asu.edu >> http://www.public.asu.edu/~cmbarton >> >> On Oct 23, 2012, at 8:46 AM, Glynn Clements >> wrote: >> >>> >>> Michael Barton wrote: >>> I want to retract my concern over dateutil. Both William and Helena have shown that it IS available in the default Python distribution. >>> >>> It isn't, however, part of the Python standard library, so it needs to >>> be explicitly listed as a dependency, distinct from Python. >>> >>> I have no particular opinion as to whether or not dateutil should be >>> used, but it should not be an optional dependency. I.e. either require >>> it or don't use it, but don't offer two subtly-different APIs. >>> >>> -- >>> Glynn Clements >> >> ___ >> grass-dev mailing list >> grass-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-dev > > - > William Kyngesburye > http://www.kyngchaos.com/ > > The equator is so long, it could encircle the earth completely once. > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
Well, on the Mac, it "comes with" the Python Apple provides, but as Glynn says it is not a part of the standard Python package. It looks like it's been included since Python 2.5 on OS X. On Oct 23, 2012, at 12:23 PM, Michael Barton wrote: > So now I'm confused. Does it come with the Python that comes with Macs and > can be installed (normal install) on Windows? Or is it something that needs > to be installed separately? > > Michael > __ > C. Michael Barton > Director, Center for Social Dynamics & Complexity > Professor of Anthropology, School of Human Evolution & Social Change > Arizona State University > Tempe, AZ 85287-2402 > USA > > voice:480-965-6262 (SHESC), 480-727-9746 (CSDC) > fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) > www: http://csdc.asu.edu, http://shesc.asu.edu > http://www.public.asu.edu/~cmbarton > > On Oct 23, 2012, at 8:46 AM, Glynn Clements > wrote: > >> >> Michael Barton wrote: >> >>> I want to retract my concern over dateutil. >>> >>> Both William and Helena have shown that it IS available in the >>> default Python distribution. >> >> It isn't, however, part of the Python standard library, so it needs to >> be explicitly listed as a dependency, distinct from Python. >> >> I have no particular opinion as to whether or not dateutil should be >> used, but it should not be an optional dependency. I.e. either require >> it or don't use it, but don't offer two subtly-different APIs. >> >> -- >> Glynn Clements > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye http://www.kyngchaos.com/ The equator is so long, it could encircle the earth completely once. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
So now I'm confused. Does it come with the Python that comes with Macs and can be installed (normal install) on Windows? Or is it something that needs to be installed separately? Michael __ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Oct 23, 2012, at 8:46 AM, Glynn Clements wrote: > > Michael Barton wrote: > >> I want to retract my concern over dateutil. >> >> Both William and Helena have shown that it IS available in the >> default Python distribution. > > It isn't, however, part of the Python standard library, so it needs to > be explicitly listed as a dependency, distinct from Python. > > I have no particular opinion as to whether or not dateutil should be > used, but it should not be an optional dependency. I.e. either require > it or don't use it, but don't offer two subtly-different APIs. > > -- > Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
Michael Barton wrote: > I want to retract my concern over dateutil. > > Both William and Helena have shown that it IS available in the > default Python distribution. It isn't, however, part of the Python standard library, so it needs to be explicitly listed as a dependency, distinct from Python. I have no particular opinion as to whether or not dateutil should be used, but it should not be an optional dependency. I.e. either require it or don't use it, but don't offer two subtly-different APIs. -- Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
I want to retract my concern over dateutil. Both William and Helena have shown that it IS available in the default Python distribution. I am still not clear why some people have had the GUI not start up with a dateutil error. Perhaps it is due in part to the tr_init that you recently moved out of the initialization for GRASS. That is the only thing I can think of that could cause this problem, even if some people had problems with this Python module for some reason. I cannot test this for a couple days because I will need to update frameworks in order to also run tests about the volume display. 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 20, 2012, at 11:40 PM, Markus Neteler wrote: > On Sun, Oct 21, 2012 at 6:58 AM, Michael Barton > 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
I can confirm that I have it on my 10.6 Mac /System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib/python/dateutil Helena Helena Mitasova Associate Professor Department of Marine, Earth, and Atmospheric Sciences 2800 Faucette Drive, Rm. 1125 Jordan Hall North Carolina State University Raleigh, NC 27695-8208 hmit...@ncsu.edu "All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.” On Oct 21, 2012, at 11:53 AM, William Kyngesburye wrote: > System/Library/Frameworks/Python.framework/Versions/2.x/Extras/lib/python/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
Yes, it is in the system python lib folder on all the Macs I checked. /System/Library/Frameworks/Python.framework/Versions/2.x/Extras/lib/python/dateutil If compilation of matplotlib found it is missing, it would put it in the user site-packages folder (it does so for pytz and mpl_toolkits). On Oct 20, 2012, at 11:35 PM, Michael Barton wrote: > 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 > 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" >>> 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 >> http://www.kyngchaos.com/ >> >> The equator is so long, it could encircle the earth completely once. >> > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
On Sun, Oct 21, 2012 at 6:58 AM, Michael Barton 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
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 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" >> 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 > http://www.kyngchaos.com/ > > The equator is so long, it could encircle the earth completely once. > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
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 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" >> 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 > http://www.kyngchaos.com/ > > The equator is so long, it could encircle the earth completely once. > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
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" > 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 http://www.kyngchaos.com/ The equator is so long, it could encircle the earth completely once. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
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 ;-) Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
>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. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
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. :) 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 : > Hi Sören, > > On Wed, Oct 17, 2012 at 6:59 PM, Sören Gebbert > 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
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" 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
Re: [GRASS-dev] dateutil dependency killing GRASS 7
Hi, 2012/10/17 Moritz Lennert : > 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
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
Re: [GRASS-dev] dateutil dependency killing GRASS 7
Hi, 2012/10/17 Markus Neteler : > On Wed, Oct 17, 2012 at 2:42 PM, Michael Barton > 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
On Wed, Oct 17, 2012 at 2:42 PM, Michael Barton 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
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 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 : >> 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 >> >> >> >> >> >> >> >> >> >> >> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
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 : > 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 > > > > > > > > > > > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] dateutil dependency killing GRASS 7
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
