Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 minimum whenever it sees any
mention of Unicode.
Didn't know Perl::MinimumVersion existed :/
I believe it was that version that fixed the last major Unicode bug.
Something to do with Cjoin ?
The code never says 5.8.4:
$VERSION = '0.11';
# Export the PMV convenience constant
@EXPORT_OK = 'PMV';
# The primary list of version checks
%CHECKS = (
# Various small things
_bugfix_magic_errno = version-new('5.008.003'),
# Included in 5.6. Broken until 5.8
_pragma_utf8 = version-new('5.008'),
_perl_5006_pragmas= version-new('5.006'),
_any_our_variables= version-new('5.006'),
_any_binary_literals = version-new('5.006'),
_magic_version= version-new('5.006'),
_any_attributes = version-new('5.006'),
_perl_5005_pragmas= version-new('5.005'),
_perl_5005_modules= version-new('5.005'),
_any_tied_arrays = version-new('5.005'),
_any_quotelike_regexp = version-new('5.005'),
_any_INIT_blocks = version-new('5.005'),
);
Would be good to find this out. ALso, the changelog mentions ignore
perlvar, could you please fix it?
Best wishes,
Tels
--
Signed on Fri Apr 7 10:35:40 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
Let's say there are a thousand. But there are 284 million people in
this country. You can't have public policy that is aimed at 100,000
people when the other multi-multi-millions are also involved. You can't
do it that way. - Jack Valenty in http://tinyurl.com/2y65n
pgp0i48Wc8YF9.pgp
Description: PGP signature
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 it was that version that fixed the last major Unicode bug. Something to do with Cjoin ? Adam K
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 between good and bad uses, then fine. The problem comes that under UNIVERSAL::isa/can there is NO way to UNIVERSAL::isa/can in the documented way. From the documentation in bleadperl: =head1 EXPORTS None by default. You may request the import of all three functions (Cisa, Ccan, and CVERSION), however it is usually harmful to do so. Please don't do this in new code. -- c
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 to do just on the interpreter. Making core modules dual-life is a way to handle these to someone else who has spare time and who doesn't need to have deep XS or Perl guts knowledge. At least I think that's the reason, otherwise why was I accepted as the maintainer of two such modules (XSLoader and Sys::Syslog)? Well, I think it's that reason too. :-) Yes, to me, size is maintainance liability, not disk space or bandwidth. Putting things in core is a pain. Keeping them there is a pain. I remember the fun of getting Storable sufficiently portable that it could go into the core. Trying to work around strange issues thrown up by certain AIX compilers in certain configurations... Nicholas Clark
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 scarce ressource, and they already lack the time to do all the work they'd like to do just on the interpreter. Making core modules dual-life is a way to handle these to someone else who has spare time and who doesn't need to have deep XS or Perl guts knowledge. At least I think that's the reason, otherwise why was I accepted as the maintainer of two such modules (XSLoader and Sys::Syslog)? Well, I think it's that reason too. :-) Yes, to me, size is maintainance liability, not disk space or bandwidth. Putting things in core is a pain. Keeping them there is a pain. I remember the fun of getting Storable sufficiently portable that it could go into the core. Trying to work around strange issues thrown up by certain AIX compilers in certain configurations... Which reminds me ... Will the new volunteer to maintain README.aix please stand up? It's almost no time involved, but fun in working with AIX is a pre, which rules the current maintainer (me) out. -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11, 11.23, SuSE 10.0, AIX 4.3 5.2, and Cygwin. http://qa.perl.org http://mirrors.develooper.com/hpux/ http://www.test-smoke.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
* 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 various architectures in various configurations. Absolutely; this, I cede. B. Let's just name YAML. Up until 0.38 it was not to difficult to install a module that is very useful, but now in 0.58, it uses a different test suite, that needs Spiffy, that needs .. Ugh, yeah, but you're picking a very specific and specifically troubled distribution. You also didn't mention (maybe you've been spared learning) that YAML used to export :all but now doesn't. 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 fewer people want to use that trivial module because it takes longer to install and is less well-tested by virtue of its dependencies. My opinion only. I don't think your opinion, as stated, is insane. I think it's better to vote with your installer, though, and avoid using those modules that have more dependencies than you think is right. I think that Kwalitee is an over-rated concept, but not useless -- but weirder things keep getting proposed to make it even less useful. I think too many non-core deps would be a nail in its coffin as a global metric. -- rjbs
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 fewer people want to use that trivial module because it takes longer to install and is less well-tested by virtue of its dependencies. Interesting example. What module do you mean? I wasnt aware that there were very many modules that have dependencies on DDS. OTOH, if it has to do with proper serilization (of closures, or cyclic data structures) then Data::Dumper just wont cut it. Cheers, Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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, as before UNIVERSAL::isa and UNIVERSAL::can, I had to deal with way too many bug reports of other people's code breaking mine. In other words, it didn't work. For example, Template::Toolkit may *never* work with Test::MockObject because the author refuses to ask the author of CGI.pm to fix a bug in the latter module, despite apparently knowing about it for several years and apparently preferring to break my code instead. I'm not going to release knowingly broken code, just so my broken code can run brokenly on really old versions of Perl. What good is that? -- c
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
* 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 AnyDBM and Data::Dumper. It will just meant that fewer people want to use that trivial module because it takes longer to install and is less well-tested by virtue of its dependencies. Interesting example. What module do you mean? I wasnt aware that there were very many modules that have dependencies on DDS. OTOH, if it has to do with proper serilization (of closures, or cyclic data structures) then Data::Dumper just wont cut it. I was making a random example of something that used something it probably didn't need, and that used something that might be emulable by core modules. -- rjbs
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 Exporter::Lite is lite'r than Exporter, the use of Exporter is zero, while Exporter::Lite means loading another module, and adds another dependency. And because dependencies are recursive, you inherit it's baggage. If one dep doesn't work on VMS, now your program doesn't. And the more dependencies, especially if you are using more than one module that does the same thing just because of stylistic differences, then it means more problems. It's not till you hit something like Ricardo's exporter, which does some very novel and interesting extra things, that you reach the threshold. It's mostly the same, but if you need the extra parts, then it might be worth the extra dependency. Which is why Graph::Easy will include about 50 lines reinventing Heap::Binary - it removes the last dependency, uses less memory, is faster, and it avoids with me dealing with the only other option, Heap::Simple, because Heap::Simple comes in two flavours, Perl and XS and _you_ have to choose which to make the dependency, meaning the user doesn't get a choise other than needs suddenly a compiler, but is faster or needs still no compiler, but is not much faster than Heap::Binary. Anyway, I think that we all agree in principle, but everyone has different thresholds. best wishes, Tels -- Signed on Wed Apr 5 18:31:08 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. My wife is just a slow brain, running up the bill.. -- Often misheard song lyrics #149 pgpWBojwpqe9N.pgp Description: PGP signature
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 etc. This to me is the biggest problem. After 6 years, is it finally okay for me to use such exotic features as lexical warnings and lexical filehandles, just to satisfy someone who refuses to upgrade an eight year old installation of Perl? [snip] I'm trying to figure out why I've been sending patches to p5p for about five years now if people complain when I take advantage of the bugs they fix. At some point, it would be nice if people were to use software released this millennium. Ever written software for government? Yes. And I don't know which parts of the mystical government you speak off, but people everywhere are pretty pissed of when they have to work with 10 year old software. Hell, there are problems getting hardware that still runs that old stuff. It's routine to be required to offer a 10 year support period. Yes, but that does not mean that you need to upgrade the installation with the-latest-foo-bar-from-cpan-which-just-breaks-on-5.004. You just keep the system as it is and patch when breakage really occurs. :) This comes up more often that you might think. And so as my gold standard for back-compatability, I use 10 years. A decade is a nice round number. Ugh - but at least we don't have 16 fingers :) If it's something that isn't very core'y, I use a secondary support period of 5 years. 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. I wont :) best wishes, Tels -- Signed on Wed Apr 5 18:21:33 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. My glasses, my glasses. I cannot see without my glasses. - My glasses, my glasses. I cannot be seen without my glasses. pgpmeg0FZETKZ.pgp Description: PGP signature
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 of work just fine, as before UNIVERSAL::isa and UNIVERSAL::can, I had to deal with way too many bug reports of other people's code breaking mine. In other words, it didn't work. 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. UNIVERSAL::isa and UNIVERSAL::can remain a good idea implemented without sufficient hubris. As I've mentioned a few times, a much better option would have been something like warnings::isacan, to warn about bad calls, but which when the few of us that NEED to use as a function, knowing exactly what we mean by using it that way, don't have it magically and forcibly and mistakenly converted to a method. And to make matters worse, now there's a warning suppression option, so they now just magically change the way the code works, potentially breaking it without warning. For example, Template::Toolkit may *never* work with Test::MockObject because the author refuses to ask the author of CGI.pm to fix a bug in the latter module, despite apparently knowing about it for several years and apparently preferring to break my code instead. Turnabout is not fair play when it comes to bugs. I'm not going to release knowingly broken code, just so my broken code can run brokenly on really old versions of Perl. What good is that? I wasn't aware Test::MockObject was fundamentall broken. As far as I was aware it does the right thing. And if someone uses UNIVERSAL::isa the wrong way, that's their problem to fix. And as for the version issue, you should do what you like there, because you introduced it as a new module. Just make sure the version dependency is explicit. Adam K
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 out why I've been sending patches to p5p for about five years now if people complain when I take advantage of the bugs they fix. At some point, it would be nice if people were to use software released this millennium. Ever written software for government? Yes. And I don't know which parts of the mystical government you speak off, but people everywhere are pretty pissed of when they have to work with 10 year old software. We *only* have local government as customers, and they get *my* perl, installed in *our* tree. Of course my perl includes defined-or :) :o) Hell, there are problems getting hardware that still runs that old stuff. :) One customer ran production on a system so old that they didn't dare to reboot it, because they were affraid it was not going to boot again. OK, that was 6 years ago, but still, government is a strange customer. You will laugh, but the most common hardware failure occurs due to power-down/power-up cycles. Systems run happy for months, even years, shut them down, let them cool, boot them up, and the HD, power supply or mainboard is dead. That's why you use a lot and big UPS. Government indeed is strange. Some parts of it can't buy ink for the printer, let alone a new HD, others blow a million on a new data center. Usually, both parts sit in the same building :-P It's routine to be required to offer a 10 year support period. Yes, but that does not mean that you need to upgrade the installation with the-latest-foo-bar-from-cpan-which-just-breaks-on-5.004. You just keep the system as it is and patch when breakage really occurs. :) I don't care if their default perl breaks down. That would be their fault. As long as they don't break mine. Perl has the advantage of not being tied to this product *must* be installed in /usr (and yes, we *do* have a third party that still sets that requirement for their product), symlinks to the rescue. Yeah, but if you install your own Perl, then the modules you use can work with it, hence there is no requirement for Foo-Bar to actually run under 5.004. That was my main point :D It's like saying that $LatestGame must run under Win95, just because there are a few people who insist that they use it. I hate upgrade cycles as much as everyone else, but even more annoying are people stuck in the last decade :D This comes up more often that you might think. And so as my gold standard for back-compatability, I use 10 years. A decade is a nice round number. Ugh - but at least we don't have 16 fingers :) 5.8.3 is the minimum to accept for me, and it should have defined-or 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? best wishes, Tels -- Signed on Wed Apr 5 23:17:38 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. helft den armen vögeln -- gegen kleinschreibung pgpOZC3IARHEP.pgp Description: PGP signature
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 on Spiffy, so Spiffy needs to go in the core (which isn't what actually happened, but could have) Actually I thought the decision was that YAML wasnt going in and that the MB team would roll their own writer? Already done by Stephen Adkins, from Changes for 0.27_10: - We now include our own YAML.pm work-alike that we can use when the real YAML isn't installed. We might soon even start using it when YAML is installed, because the YAML API and dependency chain have been changing in unfavorable ways lately. [Stephen Adkins] This is the version that is currently in blead perl, so this dependency problem is resolved. Randy.
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 the CPAN. I dont agree with this. Or rather, I dont agree that the core is over-crowded. I do agree that as many modules should be dual-lifed as possible however, but that is just so you can upgrade without upgrading perl. Yes, and if some of these modules can be made to work on older Perl as well with one- or two-lines patches, isn't it even better? :-) Personally i think the core is too big argument is a red-herring given that bandwidth is as cheap as it is these days. Adding a couple of modules to core would increase the rsynch time by what a second or two? It would suck up a couple of extra K, something like 1% of what most of use for our web-browser cache. So the size argument IMO doesnt hold water. 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 to do just on the interpreter. Making core modules dual-life is a way to handle these to someone else who has spare time and who doesn't need to have deep XS or Perl guts knowledge. At least I think that's the reason, otherwise why was I accepted as the maintainer of two such modules (XSLoader and Sys::Syslog)? Also, there is a tension in the community relating to this issue that i dont think we will see any resolution of soon. 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 example a module as important as Test::More was included in the core in 5.7, which really means 5.8. Maybe the problem is that, like Abigail pointed it in P5P, there were fewer Perl releases in the past years, and more precisely we're at the same branches (5.8 / 5.9) since a long time, therefore reducing the cycle of potential inclusion of new modules. IMO this objecitve is in direct contradiction of the purported P5P objective of not adding stuff to the core and just makes omissions from the core even more critical. 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 that when people write code based only on core modules they can do a good job without reinventing wheels or code duplication. In a sense, my opinion does not really matter here: the facts are that many P5Porters in general, and the Pumpkings in particular, dislike adding new modules to the core, on the basis that installing modules from the CPAN is easy. You're more active on P5P than I am, so I don't have to recall you all the discussions that preceded the inclusion of CPANPLUS and Module::Build, and how making them work everywhere doesn't look an easy task. But note that I don't necessarily disagree with you: I would welcome a Perl distribution that offer more modules, but when I need to write a portable program, that must run on older Perl, the new features in the core can't be used anyway. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 example a module as important as Test::More was included in the core in 5.7, which really means 5.8. This isn't an issue. Any distribution is going to have a Perl version dependency. So for any given distribution $d with Perl version dependency $d-minver, it needs to keep $d-deps as a subset of $perl[$d-minver]-modules. This is what 99% of authors mean by that phrase. And generally the bugs only occur when they misread their minimum version, or don't put an explicit minimum (and so never bother to check). Adam K
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 the CPAN. I dont agree with this. Or rather, I dont agree that the core is over-crowded. I do agree that as many modules should be dual-lifed as possible however, but that is just so you can upgrade without upgrading perl. There are some crappy modules in the core, though. I mean, look at CSearch::Dict. I'm never likely to use that in a million years. (partly because the documentation doesn't help me understand what it buys me). Or CText::Soundex. I know what it does, but its purpose is so specialised (and in this international age, woefully parochial) that it hardly deserves core status. It's just that it's been in there forever. In another universe it would be on CPAN only. Possibly with some sort of plug-in architecture to let you switch in Metaphone and other algorithms. Then it might be a bit more useful. 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. Personally i think the core is too big argument is a red-herring given that bandwidth is as cheap as it is these days. Adding a couple I don't think bandwidth is the argument. of modules to core would increase the rsynch time by what a second or two? It would suck up a couple of extra K, something like 1% of what most of use for our web-browser cache. So the size argument IMO doesnt hold water. There is the multiplier effect of having that new K stored on all the mirrors to keep in mind. Also, there is a tension in the community relating to this issue that i dont think we will see any resolution of soon. 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. As long as the core modules are there on the basis that they serve as building blocks to build other modules, I don't see any problem with that. The trouble is that all the cool tools are evolving so rapidly that putting them into core would really cramp their style. IMO this objecitve is in direct contradiction of the purported P5P objective of not adding stuff to the core and just makes omissions from the core even more critical. I'm curious, what's critically lacking? 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 that when people write code based only on core modules they can do a good job without reinventing wheels or code duplication. What wheels are being reinvented, or what code is being duplicated? I think the core problem-space isn't too bad. I'm not sure that there are many intermediate level modules left out there that can be applied to generic module development. I'm not sure that I want to drink the Class::* kool-aid. Long term i think the community needs to sort out this problem because I dont think there is consensus on it, and I think that a lot of people only look at the issue from their own individual point of view. If somebody is concerned about the overall quality of perl and CPAN I think a more holisitic point of view is required. 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 modules. Then after a while, see what floats to the top. David -- It's overkill of course, but you can never have too much overkill.
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 modules. Then after a while, see what floats to the top. There's a couple of people working on this in dribs and drabs, me included. With the new DBIx::Loader module coming out soon, and having SQLite support, I'm planning on merging Data::Package::SQLite with DBIx::Class so you can point a class at a SQLite URI and it will just sort of download and unfold itself into a full CDBI-like interface to the data. And with that, we get much much easier access to the datasets generated by CPANTs, CPAN Testers, and a few other things. Which makes dependency graphs and such much much more trivial, and more likely to be available from something you just grab from CPAN. (and once I get my CPAN SQLite index, you get CDBI-like access to the index too, like JSAN has) Adam K
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 feature-lacking code like 5.6. or even gasp 5.004. Just think Unicode support, hash randomization, memory leaks. FWIW I've heard at least one valid argument for sticking with 5.6, and that actually is unicode support. :-) Apparently, in 5.6 regular expressions don't have full unicode support. But in 5.8 the regexp unicode stuff is expensive. And to make matters worse, if anything in any package that you import uses unicode, the new, slower unicode regular expression algorithm is applied to *everything* and there's no easy way to turn that off. This is just a nasty rumour I'm sure, but I've heard it multiple times from multiple people. I like to stay on the cutting edge and if my regexps are too slow, I'll find some other way to do it. :-) Which is fine if you live in ASCII land. Herr Müller paying € 150 to Mr. ☺ 唐鳳☻ might not share your view. :) OTOH, since the introduction of 5.6, hardware has gotten faster and cheaper, so the slower, but actually working Unicode processing in 5.8 might something you actually want :D Best wishes, Tels -- Signed on Tue Apr 4 19:33:08 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. Ivonna Humpalot pgp7hTifO3azx.pgp Description: PGP signature
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 into core. Let the early adopters try out non-CPAN low-level modules. Then after a while, see what floats to the top. I was, but it is atm very hard to get simple things queried from the CPANTS (or CPAN or whatever) database. There is a package list, but it only includes author/file info, no dependencies, license etc. There is also CPANTS database, which includes the stuff, but is outdated (e.g. from 2005-12-05) I thought about writing my own stuff, but I am completely overloaded with other work atm. It would be cool to generated whatever graphs/stats from CPAN easily, though. And if you have easily dependency information, you could even easily build an auto-bundler, that throws you a .tar.gz containing the module and every nec. dependency in one go. best wishes, tels -- Signed on Tue Apr 4 18:54:00 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. A Thaum is the basic unit of magical strength. It has been universally established as the amount of magic needed to create one small white pigeon or three normal-sized billiard balls. -- Terry Pratchett pgp1HneGlmNHF.pgp Description: PGP signature
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 feature-lacking code like 5.6. or even gasp 5.004. Just think Unicode support, hash randomization, memory leaks. You forget that there's more than one way to use Perl :-) :) When Perl is used for sysadmin tasks, most of the features you listed (and I could add threads support, new IO implementation, signals handling, subroutines attributes) are of no to little use because such Perl scripts are run for executing tasks that do not require advanced Perl features like those just listed. Remember that on Unix systems, Perl is like Bash, Sed and Awk, only more powerful (even if it's by one or two orders). Do you replace your /bin/sh on your Solaris with the latest Bash just because it has very new and cool features? Usually you can't. Mainly because it could break things, and has little to no added value. On workstations, poeple (e.g me, collegues, family etc) tend to install a new system every 2..3 years because the old(er) linux versions are usually lacking in feature (like, say, no unicode support, no support for modern hardware, buggy software, etc etc). OTOH, I have server systems running for like 3 years (or until the hardware burns down) because it works. (Usually, after a few years you upgrade the system anyway, because the definition of works changed sufficiently, or the environment causes the machine to no longer work with others). In the former case I am not interested in running older perls, in the latter case I am not updating any module or software on the server unless its definitely broken, because updating lets say File::Temp would risk breaking the system, and users of the machine in question don't like downtimes. Now, there is definitely a difference between very basic modules that should run on 5.004, like File::Temp or whatever, and fancy stuff you don't want to run on such old systems, like say Graph::Easy, though. But for instance, I am totally at a loss why Version.pm needs to support 5.004 - I mean, if you are running such an ancient machine, why put a new Version.pm on it and risk breaking stuff? Likewise, why using BigInt on 5.004? The bugs in overload.pm alone would probably make your head spin. I think the worst case is that the testsuite runs ok, so you think it works, but it then breaks in many and subtle ways, exactly when you need it most. More below: Using these older Perls means you basically show the hard-working Perl5-Porters that you don't care for their work in improving Perl. But the Perl interpreter (which is what the P5Porters are working on) and the Perl modules are mostly disconnected (*). Where would be the interest to use an interpreted language if it were tied to a specific version of the interpreter? Most Perl code out there don't require recent features. To continue with my previous analogy, there are also many people that work hard on the Linux kernel, the GNU system, and all the different parts that compose a GNU/Linux distribution, but when a server is in production, you can't upgrade it at your wish. (*) 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 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? My current $work is to write a Perl program that must execute on about 1200 Linux servers, with Perl versions ranging from 5.004 to 5.8. I can't upgrade Perl on these because they have different kernel / glibc / gcc versions. But that's not a problem because I don't need to upgrade Perl or the modules on said systems, just to put the modules I need in a directory and use lib /that/directory. Of course I need to use modules that work with 5.004, or patch them so they work with 5.004, but you could be surprised to see how little some of the patches are. Can be as simple as removing require 5.6 (as for File::Temp). Most of the patches I've sent were less than 10 lines of differences. You $work is what I call a special case. It is certainly not the generic case (at least for my userbase), and I don't think that authors should have to care for such special needs (unless they want :-D. The biggest problem you face IMHO is that the module might work in testing, but not in praxis. Dont think CPAN testers even do 5.6 anymore, and I do not havy anything older than 5.8.3 at my disposal. This means
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 me to use such exotic features as lexical warnings and lexical filehandles, just to satisfy someone who refuses to upgrade an eight year old installation of Perl? Are there such people who absolutely want to use the latest code I wrote without actually upgrading their systems? I'm trying to figure out why I've been sending patches to p5p for about five years now if people complain when I take advantage of the bugs they fix. At some point, it would be nice if people were to use software released this millennium. -- c
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
* 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 reasons to write their own. The problems arise when authors of big modules start prefering non-core versions of good core modules. IMHO something like that should give you a (very) negative score on CPANTS. Could you elaborate on this? As stated, it seems pretty ludicrous to me. It reads like this: You should not use module B that is like module A, if A is in the core distribution. This is true regardless of the fact that B may be better optimized for your current needs, planned needs, programming style. This can be further distilled to: There's more than one way to do it, but most of them will get you dirty looks. -- rjbs
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 it finally okay for me to use such exotic features as lexical warnings and lexical filehandles, just to satisfy someone who refuses to upgrade an eight year old installation of Perl? The answer is it depends. I'll have a more definative answer once we get the dependency graph stuff sorted out. But as a stopgap answer, I offer the following. Yes you can, as long as nobody else uses your module. If you write something for 5.8.4, and then over time dozens of other modules that use yours are all 5.005, then it might be worth looking at doing some back-porting, because you've become the weakest link. That said, to some degree they made that situation themself. On the other hand, if YOU were adding a module as a new dependency of something you already have that needs 5.005, and 100 other 5.005 things already use, then you just broke 5.005 support on them all. So I'd say on CPAN 5.005 is it's something you expect others to use, 5.6 for general things if you want, 5.8.4 is you need unicode (or whatever other special cases apply) and if people start using you and you are getting in the way, consider dropping. And once we get CPAN and CPANTs graph modules set up, I have an algorithm in mind that should be able to give us a list of the Backcompatibility Weakest Links, the modules that are prevent other modules below them from working on the versions they say they can. Are there such people who absolutely want to use the latest code I wrote without actually upgrading their systems? I'm trying to figure out why I've been sending patches to p5p for about five years now if people complain when I take advantage of the bugs they fix. At some point, it would be nice if people were to use software released this millennium. Ever written software for government? It's routine to be required to offer a 10 year support period. This comes up more often that you might think. And so as my gold standard for back-compatability, I use 10 years. A decade is a nice round number. If it's something that isn't very core'y, I use a secondary support period of 5 years. 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. Adam K
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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. Should is nice and all, but until you start paying my invoices for the special $40 an hour for free software support (and not a one-time fee, 'cuz maintenance costs, but it's a much better deal than my usual consulting rate), it's just an opinion out there in the luminous aether somewhere and I'll go on quite happily giving people useful software because I enjoy it until I stop enjoying it. You're totally welcome to file bugs based on your dependency graph about what I should and shouldn't do. I'll cheerfully file them under Not fun. Don't care. You get both pieces if it breaks. I get paid directly for approximately exactly zero of my CPAN coding. Thus if it's not fun, I don't do it. Supporting ancient software from the last millennium and coding with both hands tied behind my back to support Perl 5.005 and to work around all of its infelicities and bugs that I've helped to fix isn't fun... unless there's cash involved or someone else doing the work in such a way that I don't have to deal with the un-fun. I write software to make my life easier. If I can't use that software to make my life easier because people who are using that work I've done for free complain, well then what's my motivation? Could I write a test suite without Test::More? Yep. I've done it before. Could I write my own mock objects by hand without Test::MockObject or Test::MockObject extends? Absolutely. Do I know how to deal without lexical warnings or lexical filehandles or to use signals safely? Yep. Doesn't mean I want to go back to the bad old days. There have been what, a dozen stable releases of Perl since the last 5.005 release? If someone can't update to a newer release less than 8% of the time, that's all sorts of auto-face-stabby badness and not so much fun for me, and frankly TV and video games seem like more fun hobbies with less frustration, 'cuz I'm pretty sure I'm absolutely NOT getting any decent feedback from such a situation. Is there a business in supporting classic software in certain situations? Perhaps. That baby's not cute enough for anyone but its mother to love it though, in my opinion. Now if I've mistakenly claimed that a distribution requires Perl 5.6 as a minimum (which most of mine do, I believe) and it works further back, that's fine -- I'm happy to loosen that requirement. I have no desire to rule out the utility of my code in situations where it works without increasing my blood pressure. (Now if someone were to make warnings.pm a dual-lived module and put in a pre-5.6 compatibility mode, great! I don't mind marking a dependency on that so that my code works in more places. It's just when backwards compatibility become a millstone around my neck that I want to smash things and generally not spend time around my computer.) I don't think I'm so odd a developer in all this. -- c
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 work with 5.004 (and maybe earlier) but their author haven't yet released updated versions. With these patches (and if the test suites of some of these are fixed), several modules can probably work on 5.004 or earlier with little to no changes. 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 randomization, memory leaks. Using these older Perls means you basically show the hard-working Perl5-Porters that you don't care for their work in improving Perl. 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? Best wishes, Tels -- Signed on Mon Apr 3 18:28:11 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. I'm not a vegetarian, but I eat animals who are -- Groucho Marx pgp2O2qldS6MZ.pgp Description: PGP signature
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 possibly the smartest thing I've ever heard Donald Rumsfeld say (although he put it somewhat confusingly) There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know. While you might not see why, let me tell you from the number of bug emails I've received about these sorts of issues, I _know_ there are scenarios we don't know about where this stuff is important. I just don't know what they are :) Adam K
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 randomization, memory leaks. You forget that there's more than one way to use Perl :-) When Perl is used for sysadmin tasks, most of the features you listed (and I could add threads support, new IO implementation, signals handling, subroutines attributes) are of no to little use because such Perl scripts are run for executing tasks that do not require advanced Perl features like those just listed. Remember that on Unix systems, Perl is like Bash, Sed and Awk, only more powerful (even if it's by one or two orders). Do you replace your /bin/sh on your Solaris with the latest Bash just because it has very new and cool features? Usually you can't. Mainly because it could break things, and has little to no added value. Using these older Perls means you basically show the hard-working Perl5-Porters that you don't care for their work in improving Perl. But the Perl interpreter (which is what the P5Porters are working on) and the Perl modules are mostly disconnected (*). Where would be the interest to use an interpreted language if it were tied to a specific version of the interpreter? Most Perl code out there don't require recent features. To continue with my previous analogy, there are also many people that work hard on the Linux kernel, the GNU system, and all the different parts that compose a GNU/Linux distribution, but when a server is in production, you can't upgrade it at your wish. (*) 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 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? My current $work is to write a Perl program that must execute on about 1200 Linux servers, with Perl versions ranging from 5.004 to 5.8. I can't upgrade Perl on these because they have different kernel / glibc / gcc versions. But that's not a problem because I don't need to upgrade Perl or the modules on said systems, just to put the modules I need in a directory and use lib /that/directory. Of course I need to use modules that work with 5.004, or patch them so they work with 5.004, but you could be surprised to see how little some of the patches are. Can be as simple as removing require 5.6 (as for File::Temp). Most of the patches I've sent were less than 10 lines of differences. Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 support, hash randomization, memory leaks. FWIW I've heard at least one valid argument for sticking with 5.6, and that actually is unicode support. :-) Apparently, in 5.6 regular expressions don't have full unicode support. But in 5.8 the regexp unicode stuff is expensive. And to make matters worse, if anything in any package that you import uses unicode, the new, slower unicode regular expression algorithm is applied to *everything* and there's no easy way to turn that off. This is just a nasty rumour I'm sure, but I've heard it multiple times from multiple people. I like to stay on the cutting edge and if my regexps are too slow, I'll find some other way to do it. :-) Cheers, Tyler
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 code like 5.6. or even gasp 5.004. Just think Unicode support, hash randomization, memory leaks. FWIW I've heard at least one valid argument for sticking with 5.6, and that actually is unicode support. :-) Apparently, in 5.6 regular expressions don't have full unicode support. But in 5.8 the regexp unicode stuff is expensive. And to make matters worse, if anything in any package that you import uses unicode, the new, slower unicode regular expression algorithm is applied to *everything* and there's no easy way to turn that off. This is just a nasty rumour I'm sure, but I've heard it multiple times from multiple people. I like to stay on the cutting edge and if my regexps are too slow, I'll find some other way to do it. :-) I dont believe that this is correct. The regex engine uses UTF8 logic if the pattern is UTF8 or if the string is UTF8. If both are ascii then it uses ascii logic only. Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 accompanies a script has a syntax error in it? Lets hope you wouldnt be surprised when they file said bug report in /dev/nul Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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)
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 Enzer [EMAIL PROTECTED] http://www.matisse.net/ - http://www.eigenstate.net/
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 script that accompanies a script has a syntax error in it? No, you'd file it against the distribution that contained the Makefile.PL or Build.PL. Just because they implement the installer using a particular library, doesn't mean you blame the library for their mistakes. Adam K
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 job as being to build. It should, and does leave the job of installing to ExtUtils::Install. And that makes sense to me. 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 pre-build failure, not an install failure. I'd consider that to be just a case of semantics. I could well argue it doesn't build either, it $smaller_divisions_again. From a top level tasks perspective, Module::Build has two primary roles. 1. Package the module into a distribution. 2. Install the distribution onto a system Those 4(5) steps are all part of the install task. Most end users don't see the build stage as being somehow distinct, all they want to do is install a module. Adam K
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 keep it in mind... This installer will crash with a non-useful error message if someone tries to install of 5.006, and has an implicit undeclared (still unresolvable I believe) dependency on File::HomeDir. How is this different from a Makefile.PL or any other perl script with a Cuse statement. If the Cused module can't be found, it says it can't be found. It doesn't crash. There is no difference at all when it comes to Makefile.PL. The problem is specific to installers. In an installer, you don't yet know if any piece of code is SUPPOSED to run, as well as not know if it will run. 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 isn't that it doesn't have warnings. The problem is that it doesn't have Perl 5.006. 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 distribution itself needs dependencies. If the installer doesn't look after itself, then we are back to the situation where you are installing RT, and half way though 3000 lines of output something goes BLART NO WARNINGS.PM, INSTALL FAILED and then prints another 1000 lines of output, and no reasonable end users has any idea whatsoever what caused the problem, or how to fix it. If an installer can't INSTALL under battle conditions, it is failing it's primary missing. Adam K Sure, the dependency should be listed in META.yml. And, there is a way to that so that CPAN.pm and other tools can see the dependency before running the Build.PL: You simply list it in Crequres argument to the constructor. But this was just a simplified example to illustrate a different point... (I'll shut up about the whole implicit undeclared unresolvable dependency on Module::Build for a while, given it's now in the core and I've had a good long chat about the issue with Tony.) Again, how is this different from MakeMaker's Makefile.PL which, strange enough, requires MakeMaker to be present? So if you use warnings in your Build.PL you should always do it as use 5.006; use strict; use warnings; I agree, this is true of any script, not just Build.PL. As for how to ensure File::HomeDir is installed before you actually know what you dependencies are, well I dunno, but this problem is going to keep coming back and haunting us till MB supports bundling of some kind. Bundling is *a* solution to *some* problems *some* of the time. From what I understand there's a pretty good module out there that helps with that ;). But I'm not yet convinced that it should be the default method for every distribution. Authors should have a choice. For people who want to bundle Module::Build it's simple to do by hand, and it's been done by authors who decided that was best for their distribution. Regards, Randy.
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
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 distribution itself needs dependencies. This should be Any surrounding client doing a recursive installation can't fix it, UNLIKE the way it can when the installer completes and tells the client what needs to be installed. If an installer can't INSTALL under battle conditions, it is failing it's primary missing. missing - mission. Adam K
