Re: Activestate PPMs for DateTime?
On Mon, 1 Nov 2004, Yitzchak Scott-Thoennes wrote: Not that I'm blaming DateTime; there's plenty of blame to go around. ActiveState is to blame for (as rumor has it) having someone maybe sometime completely rewrite their build scripts, instead of just quickly addressing this deficiency. DateTime is to blame for using a build method that doesn't yet have support from a sizable segment of the potential user base. Module::Build is to blame for not coming up with a way to have dependencies honored by Makefile.PL-friendly tools; indeed, for not listing itself a dependency at all. And lastly and most importantly, ExtUtils::MakeMaker is to blame for having such a hokey mechanism for dependencies in the first place (to whit: run Makefile.PL and parse out the PREREQ line from the generated Makefile). Oh, and lets not leave out CPAN::FirstTime; everything might work out ok if it would have a default mirror option; see http://ppm.activestate.com/BuildStatus/5.8-windows/windows-5.8/DateTime-Locale-0.09.txt Clearly the easiest for AS is to simple install Module::Build and its dependencies before trying to build PPMs. What's the way forward in all this? I don't know. I do know that the Module::Build people are working on what I assume will be a separate module to parse complex dependency information out of META.yml. We'll see how it goes, and if various tools will adopt it. I don't hold my breath. You hold your breath on it getting written, or getting adopted? It'll get written, I'm sure. Whether people will adopt it is up to them. -dave /*=== VegGuide.Org Your guide to all that's veg. ===*/
Re: Activestate PPMs for DateTime?
On Tue, Nov 02, 2004 at 10:48:19AM -0600, Dave Rolsky wrote: Clearly the easiest for AS is to simple install Module::Build and its dependencies before trying to build PPMs. Agreed. But IIRC it has no non-core dependencies. What's the way forward in all this? I don't know. I do know that the Module::Build people are working on what I assume will be a separate module to parse complex dependency information out of META.yml. We'll see how it goes, and if various tools will adopt it. I don't hold my breath. You hold your breath on it getting written, or getting adopted? It'll get written, I'm sure. Whether people will adopt it is up to them. Sorry to be unclear. I know they are motivated to get it written. I meant whether it will be adopted. Module::Build already has it's own way to tell about dependencies but afaik no one uses it except CPANPLUS.
Re: Activestate PPMs for DateTime?
Yitzchak Scott-Thoennes wrote: Module::Build already has it's own way to tell about dependencies but afaik no one uses it except CPANPLUS. And what is worse is that the Module::Build dependencies are treated as /suggestions/, and will not throw an error if one is not met. I just got a cpantester's report for one of my modules which only works with Perl 5.8.1 or better. Even though I added 'perl = 5.8.1' to the dependencies, Module::Build happily went on to try and build/test the module on a 5.6.1 machine. I actually have to add 'use 5.8.1' to the top of the Build.PL file to correctly bail out. :( John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
[OT] Re: Activestate PPMs for DateTime?
On Tue, 2 Nov 2004, John Peacock wrote: Module::Build already has it's own way to tell about dependencies but afaik no one uses it except CPANPLUS. And what is worse is that the Module::Build dependencies are treated as /suggestions/, and will not throw an error if one is not met. I just got a cpantester's report for one of my modules which only works with Perl 5.8.1 or better. Even though I added 'perl = 5.8.1' to the dependencies, Module::Build happily went on to try and build/test the module on a 5.6.1 machine. I actually have to add 'use 5.8.1' to the top of the Build.PL file to correctly bail out. Actually, M::B is no different fom EU::MM in this regard. EU::MM will install a module which has unmet dependencies. It's CPAN or CPANPLUS that do the enforcement. If they're not enforcing them properly with M::B modules, that obviously needs to be corrected. -dave /*=== VegGuide.Org Your guide to all that's veg. ===*/
DateTime::Format::Strptime defaults to UTC
I noticed that DateTime::Format::Strptime defaults to returning
DateTimes in the UTC time zone. Eg,
DateTime::Format::Strptime-new(pattern = '%Y%m%d%H%M%S')
-parse_datetime('2004110200')
-time_zone-name
== 'UTC'
This is at odds with DateTime, which defaults to floating. This caused
a mysterious inconsistency in my code.
I think it would be right to change this to floating. I also found the
use of the time zone given to the parser object confusing. I think the
following is a clearer documentation of the current code:
--- lib/DateTime/Format/Strptime.pm.orig2004-11-02 14:56:37.0 -0800
+++ lib/DateTime/Format/Strptime.pm 2004-11-02 14:56:40.0 -0800
@@ -859,12 +859,13 @@
=item * new( pattern=$strptime_pattern )
-Creates the format object. You must specify a pattern, you can also
-specify a Ctime_zone and a Clocale. If you specify a time zone
-then any resulting CDateTime object will be in that time zone. If you
-do not specify a Ctime_zone parameter, but there is a time zone in the
-string you pass to Cparse_datetime, then the resulting CDateTime will
-use that time zone.
+Creates the format object. You must specify a pattern, and may also
+specify a Ctime_zone and a Clocale. If you specify a time zone, it
+will be used as the default time zone if none is found by parsing, and
+the resulting CDateTime object will be converted to that time zone. If
+you do not specify a time zone, 'UTC' will be used as the default time
+zone, and the resulting CDateTime object will remain in the time zone
+found by parsing.
You can optionally use an on_error parameter. This parameter has three
valid options:
Change 'UTC' to 'floating' if you take my suggestion.
Andrew
