Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-07 Thread Tels
Moin, On Friday 07 April 2006 02:55, Adam Kennedy wrote: I use 5.8.0 as minimum, but for unicode I think it should be 5.8.1 - but I am unsure. COuld you give a reason for why specifically 5.8.3? Actually, in consultation with Audrey and other $experts, Perl::MinimumVersion applies a 5.8.4

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-06 Thread Adam Kennedy
chromatic wrote: On Wednesday 05 April 2006 14:09, Adam Kennedy wrote: And now in return, we have new modules that changes the way EVERYBODY else's code works, and changes the meaning of that code instead, so Test::MockObject gets less spurious bug reports. You mischaracterize the situation.

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-06 Thread Adam Kennedy
I use 5.8.0 as minimum, but for unicode I think it should be 5.8.1 - but I am unsure. COuld you give a reason for why specifically 5.8.3? Actually, in consultation with Audrey and other $experts, Perl::MinimumVersion applies a 5.8.4 minimum whenever it sees any mention of Unicode. I believe

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-06 Thread chromatic
On Thursday 06 April 2006 17:53, Adam Kennedy wrote: UNIVERSAL::isa/can when called as a function does a very specific thing, and one that is often misunderstood. ... and never correct, in the face of proxy objects, blessed objects, overloading, and ties. And if you were able to distinguish

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-05 Thread H.Merijn Brand
On Tue, 4 Apr 2006 19:27:57 -0400, Ricardo SIGNES [EMAIL PROTECTED] wrote: * H.Merijn Brand [EMAIL PROTECTED] [2006-04-04T10:40:39] And then still people make more of the same. Take Getopt::Long. A perfect and very functional module. Full of features, matured, and actively maintained.

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-05 Thread demerphq
On 4/4/06, David Landgren [EMAIL PROTECTED] wrote: demerphq wrote: There are also some mistakes, like Switch, but once a module goes in, it can never be removed. That's the main reason why people are so leery these days of adding new stuff to the core, in case they get it wrong. Thats an

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-05 Thread demerphq
On 4/4/06, Adam Kennedy [EMAIL PROTECTED] wrote: I want to see File::HomeDir ultimately in there, because there's a number of things that use $ENV{HOME} and implement their own special case logic. If it presents a platform independent way to find a home dir then I agree with you. You want to

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-05 Thread Adam Kennedy
chromatic wrote: On Tuesday 04 April 2006 21:57, Adam Kennedy wrote: Seeing as the worst support cases are about 10 years in a variety of countries and situations, I think that is what we should be aiming for for highly used CPAN modules. Which last time I checked is now 5.005.something So I

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-05 Thread Nicholas Clark
On Tue, Apr 04, 2006 at 11:27:07AM +0200, Sébastien Aperghis-Tramoni wrote: I don't think that the problem of core is too big is a matter of disk size, but more a matter of number of modules. P5Porters time is a scarce ressource, and they already lack the time to do all the work they'd like

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-05 Thread H.Merijn Brand
On Wed, 5 Apr 2006 14:20:15 +0100, Nicholas Clark [EMAIL PROTECTED] wrote: On Tue, Apr 04, 2006 at 11:27:07AM +0200, Sébastien Aperghis-Tramoni wrote: I don't think that the problem of core is too big is a matter of disk size, but more a matter of number of modules. P5Porters time is a

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-05 Thread Ricardo SIGNES
* H.Merijn Brand [EMAIL PROTECTED] [2006-04-05T02:39:20] I'll just mention two things, both very different A. CORE modules are tested on all supported architectures, while CPAN modules do not give that guarantee. The smoke system still causes all possible combinations to be tested on

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-05 Thread demerphq
On 4/5/06, Ricardo SIGNES [EMAIL PROTECTED] wrote: That said, I don't dispute the point that it can be wildly obnoxious when Something::Trivial requires DBD::MySQL and Data::Dump::Streamer when it could use neither -- or at least rely on AnyDBM and Data::Dumper. It will just meant that

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-05 Thread chromatic
On Wednesday 05 April 2006 02:02, Adam Kennedy wrote: But it's also why UNIVERSAL::isa/can and people adding higher-version dependencies below their existing lower-dependency modules is bad. The code used to work just fine, and now it doesn't. This is a strange definition of work just fine,

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-05 Thread Ricardo SIGNES
* demerphq [EMAIL PROTECTED] [2006-04-05T10:23:45] On 4/5/06, Ricardo SIGNES [EMAIL PROTECTED] wrote: That said, I don't dispute the point that it can be wildly obnoxious when Something::Trivial requires DBD::MySQL and Data::Dump::Streamer when it could use neither -- or at least rely on

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-05 Thread Tels
Moin, On Wednesday 05 April 2006 06:43, Adam Kennedy wrote: Ricardo SIGNES wrote: * H.Merijn Brand [EMAIL PROTECTED] [2006-04-04T10:40:39] [sniplots] But there's very little point in using Exporter::Lite because 100 other modules use Exporter in any given program. So even though

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-05 Thread Tels
Moin, On Wednesday 05 April 2006 06:57, Adam Kennedy wrote: chromatic wrote: On Tuesday 04 April 2006 10:32, Tels wrote: There is also the point that supporting ancient Perls means you can't use all the new, wonderfull features that were added to later versions of Perl, like our, warnings

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-05 Thread H.Merijn Brand
On Wed, 5 Apr 2006 18:30:33 +0200, Tels [EMAIL PROTECTED] wrote: Moin, On Wednesday 05 April 2006 06:57, Adam Kennedy wrote: chromatic wrote: On Tuesday 04 April 2006 10:32, Tels wrote: There is also the point that supporting ancient Perls means you can't use all the new, wonderfull

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-05 Thread Adam Kennedy
chromatic wrote: On Wednesday 05 April 2006 02:02, Adam Kennedy wrote: But it's also why UNIVERSAL::isa/can and people adding higher-version dependencies below their existing lower-dependency modules is bad. The code used to work just fine, and now it doesn't. This is a strange definition

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-05 Thread chromatic
On Wednesday 05 April 2006 14:09, Adam Kennedy wrote: And now in return, we have new modules that changes the way EVERYBODY else's code works, and changes the meaning of that code instead, so Test::MockObject gets less spurious bug reports. You mischaracterize the situation. There is no

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-05 Thread Tels
Moin, On Wednesday 05 April 2006 20:46, H.Merijn Brand wrote: On Wed, 5 Apr 2006 18:30:33 +0200, Tels [EMAIL PROTECTED] wrote: Moin, On Wednesday 05 April 2006 06:57, Adam Kennedy wrote: chromatic wrote: On Tuesday 04 April 2006 10:32, Tels wrote: [snip] I'm trying to figure

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-05 Thread Randy W. Sims
demerphq wrote: On 4/4/06, Adam Kennedy [EMAIL PROTECTED] wrote: Module::Build wants to go in, but because they use YAML for the data file, we add Ingy's YAML.pm, who then decides he wants to use Test::Base for everything he does, so that slips in undernearth, and of course Test::Base is based

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-04 Thread demerphq
On 4/4/06, Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote: (*) Yes, I know that the core Perl distribution includes many modules, but ask any P5Porter and he'll answer you that the core is over-crowed and that all core modules that can be made dual-life should be released on the CPAN. I

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-04 Thread Adam Kennedy
Anyway, i just wanted to add this because I dont think that you can take it for granted that all perl5porters believe the core module set should be as restricted as possible. I dont. I believe that the core should contain out of the box enough support for the various platforms that perl runs on

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-04 Thread Sébastien Aperghis-Tramoni
demerphq wrote: On 4/4/06, Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote: (*) Yes, I know that the core Perl distribution includes many modules, but ask any P5Porter and he'll answer you that the core is over-crowed and that all core modules that can be made dual-life should be

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-04 Thread Adam Kennedy
Many module authors set a design objective of making their modules dependent only on core modules. This is a comment that I see on a regular basis. When I hear or read that, I always wonder if the author realised that core modules is something dependant on the Perl distribution version. For

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-04 Thread David Landgren
demerphq wrote: On 4/4/06, Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote: (*) Yes, I know that the core Perl distribution includes many modules, but ask any P5Porter and he'll answer you that the core is over-crowed and that all core modules that can be made dual-life should be released on

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-04 Thread H.Merijn Brand
On Tue, 04 Apr 2006 16:20:09 +0200, David Landgren [EMAIL PROTECTED] wrote: demerphq wrote: On 4/4/06, Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote: (*) Yes, I know that the core Perl distribution includes many modules, but ask any P5Porter and he'll answer you that the core is

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-04 Thread Adam Kennedy
Who was it who was working on the global CPAN dependency graph, to figure out what module was dependent on what? Whatever became of that? I think hard numbers that stand on their own merits are about the only way to get new stuff into core. Let the early adopters try out non-CPAN low-level

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-04 Thread Tels
Moin, On Tuesday 04 April 2006 18:30, Adam Kennedy wrote: Who was it who was working on the global CPAN dependency graph, to figure out what module was dependent on what? Whatever became of that? I think hard numbers that stand on their own merits are about the only way to get new stuff

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-04 Thread Tels
Moin, On Tuesday 04 April 2006 01:35, Sébastien Aperghis-Tramoni wrote: Tels wrote: Moin, Hello Tels, OTOH, who still runs pre-5.8.x code deserves what they get. There are horrible bugs in older Perls, and I don't know why people still insist using insecure, buggy and

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-04 Thread chromatic
On Tuesday 04 April 2006 10:32, Tels wrote: There is also the point that supporting ancient Perls means you can't use all the new, wonderfull features that were added to later versions of Perl, like our, warnings etc. This to me is the biggest problem. After 6 years, is it finally okay for

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-04 Thread Tels
Moin, On Tuesday 04 April 2006 01:50, Tyler MacDonald wrote: Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote: OTOH, who still runs pre-5.8.x code deserves what they get. There are horrible bugs in older Perls, and I don't know why people still insist using insecure, buggy and

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-04 Thread Ricardo SIGNES
* H.Merijn Brand [EMAIL PROTECTED] [2006-04-04T10:40:39] And then still people make more of the same. Take Getopt::Long. A perfect and very functional module. Full of features, matured, and actively maintained. Now go look at CPAN, and see how many people either do not like it or find other

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-04 Thread Adam Kennedy
Ricardo SIGNES wrote: * H.Merijn Brand [EMAIL PROTECTED] [2006-04-04T10:40:39] And then still people make more of the same. Take Getopt::Long. A perfect and very functional module. Full of features, matured, and actively maintained. Now go look at CPAN, and see how many people either do not

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-04 Thread Adam Kennedy
chromatic wrote: On Tuesday 04 April 2006 10:32, Tels wrote: There is also the point that supporting ancient Perls means you can't use all the new, wonderfull features that were added to later versions of Perl, like our, warnings etc. This to me is the biggest problem. After 6 years, is

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-04 Thread chromatic
On Tuesday 04 April 2006 21:57, Adam Kennedy wrote: Seeing as the worst support cases are about 10 years in a variety of countries and situations, I think that is what we should be aiming for for highly used CPAN modules. Which last time I checked is now 5.005.something So I aim there.

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-03 Thread Tels
Moin, On Sunday 02 April 2006 16:37, Sébastien Aperghis-Tramoni wrote: Adam Kennedy wrote: [snip] This is a little harder with Module::Build as it has a few dependencies that ask 5.005 or 5.6, although in some cases incorrectly. I send patches so modules like File::Temp or ExtUtils::Constant

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-03 Thread Adam Kennedy
I know, now people will come out of the wood and say that they have that old system, and no, they can't upgrade Perl etc, never touch a running system etc yadda yadda. But what the heck do you then try to upgrade modules on said system when you didn't want to touch the system? To quote

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-03 Thread Sébastien Aperghis-Tramoni
Tels wrote: Moin, Hello Tels, OTOH, who still runs pre-5.8.x code deserves what they get. There are horrible bugs in older Perls, and I don't know why people still insist using insecure, buggy and feature-lacking code like 5.6. or even gasp 5.004. Just think Unicode support, hash

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-03 Thread Tyler MacDonald
Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote: OTOH, who still runs pre-5.8.x code deserves what they get. There are horrible bugs in older Perls, and I don't know why people still insist using insecure, buggy and feature-lacking code like 5.6. or even gasp 5.004. Just think Unicode

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-03 Thread demerphq
On 4/4/06, Tyler MacDonald [EMAIL PROTECTED] wrote: Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote: OTOH, who still runs pre-5.8.x code deserves what they get. There are horrible bugs in older Perls, and I don't know why people still insist using insecure, buggy and feature-lacking

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-02 Thread Adam Kennedy
demerphq wrote: On 4/2/06, Adam Kennedy [EMAIL PROTECTED] wrote: demerphq wrote: On 4/1/06, Adam Kennedy [EMAIL PROTECTED] wrote: Similarly if somebody has an error in their Build.PL or Makefile.PL are you going to say that the installer doesnt work? Yes, absolutely. So you would file a

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-02 Thread Sébastien Aperghis-Tramoni
Adam Kennedy wrote: While the code for the distribution might be able to die like this, the INSTALLER should fail in a way that is detectable and automatable. If the Cused warnings.pm module can't be found, it crashes (specifically, dies) and say it can't find warnings. But the problem

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-01 Thread demerphq
On 4/1/06, Adam Kennedy [EMAIL PROTECTED] wrote: Similarly if somebody has an error in their Build.PL or Makefile.PL are you going to say that the installer doesnt work? Yes, absolutely. So you would file a bug with ExtUtils::MakeMaker or Module::Build when the pre-build script that

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-01 Thread demerphq
On 4/1/06, demerphq [EMAIL PROTECTED] wrote: On 4/1/06, Adam Kennedy [EMAIL PROTECTED] wrote: Similarly if somebody has an error in their Build.PL or Makefile.PL are you going to say that the installer doesnt work? Yes, absolutely. So you would file a bug with ExtUtils::MakeMaker

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-01 Thread Tels
Moin, On Saturday 01 April 2006 14:13, demerphq wrote: On 4/1/06, demerphq [EMAIL PROTECTED] wrote: On 4/1/06, Adam Kennedy [EMAIL PROTECTED] wrote: Similarly if somebody has an error in their Build.PL or Makefile.PL are you going to say that the installer doesnt work?

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-01 Thread chromatic
On Saturday 01 April 2006 03:41, demerphq wrote: So you would file a bug with ExtUtils::MakeMaker or Module::Build when the pre-build script that accompanies a script has a syntax error in it? Don't forget with every distribution that marked that distribution as a dependency. -- c

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-01 Thread Matisse Enzer
On Mar 31, 2006, at 11:02 AM, Adam Kennedy wrote: Most end users don't see the build stage as being somehow distinct, all they want to do is install a module. I agree 100% with that, and urge others to keep that in mind. --- Matisse

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-01 Thread Adam Kennedy
demerphq wrote: On 4/1/06, Adam Kennedy [EMAIL PROTECTED] wrote: Similarly if somebody has an error in their Build.PL or Makefile.PL are you going to say that the installer doesnt work? Yes, absolutely. So you would file a bug with ExtUtils::MakeMaker or Module::Build when the pre-build

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-01 Thread Adam Kennedy
chromatic wrote: On Saturday 01 April 2006 03:41, demerphq wrote: So you would file a bug with ExtUtils::MakeMaker or Module::Build when the pre-build script that accompanies a script has a syntax error in it? Don't forget with every distribution that marked that distribution as a

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-01 Thread demerphq
On 4/2/06, Adam Kennedy [EMAIL PROTECTED] wrote: demerphq wrote: On 4/1/06, Adam Kennedy [EMAIL PROTECTED] wrote: Similarly if somebody has an error in their Build.PL or Makefile.PL are you going to say that the installer doesnt work? Yes, absolutely. So you would file a bug with

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-04-01 Thread demerphq
On 4/2/06, demerphq [EMAIL PROTECTED] wrote: On 4/2/06, Adam Kennedy [EMAIL PROTECTED] wrote: demerphq wrote: On 4/1/06, Adam Kennedy [EMAIL PROTECTED] wrote: Similarly if somebody has an error in their Build.PL or Makefile.PL are you going to say that the installer doesnt work?

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-03-31 Thread demerphq
On 3/31/06, Adam Kennedy [EMAIL PROTECTED] wrote: If an installer can't INSTALL under battle conditions, it is failing it's primary missing. Personally I think its worth being a touch more specific with your language. I dont see Module::Build's job to be to install. I see its job as being to

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-03-31 Thread Adam Kennedy
demerphq wrote: On 3/31/06, Adam Kennedy [EMAIL PROTECTED] wrote: If an installer can't INSTALL under battle conditions, it is failing it's primary missing. Personally I think its worth being a touch more specific with your language. I dont see Module::Build's job to be to install. I see its

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-03-31 Thread demerphq
On 3/31/06, Adam Kennedy [EMAIL PROTECTED] wrote: demerphq wrote: So it seems to be that you have four (five?) phases: Pre-Build Build Test Install (Post Install Test?) Something like dieing on a use warnings statement in the makefile or whatever to me constitutes a

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-03-31 Thread Adam Kennedy
Similarly if somebody has an error in their Build.PL or Makefile.PL are you going to say that the installer doesnt work? Yes, absolutely. Adam K

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-03-30 Thread Adam Kennedy
Randy W. Sims wrote: Adam Kennedy wrote: There are a number of ways to do this. The most simple is: use strict; use warnings; use File::HomeDir; my $conf_dir = File::Spec-catdir( File::HomeDir-my_home, '.Foo' ); Not that I wish to be a pedant about this, but only so people

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

2006-03-30 Thread Adam Kennedy
ugh, sorry, WAY too early in the morning. If the installer needs a module in order to run, it has nothing to fall back on to supply that module for it. Any surrounding client doing a recursive installation can't fix it, unless what it can do when the installer runs and says that the