Re: New proposed CPANTS metric: prereq_matches_use
On Nov 22, 2007, at 3:47 PM, David Cantrell wrote: Does the metric include modules used in the test suite? I write my test suites to deal gracefully with missing Test modules. Most people don't, unfortunately. Then CPAN testers will catch it. I don't see how adding author test modules, like Perl::Critic etc, to build_requires will help anything. And what about Linux::Smaps and other OS specific modules? I imagine a lot of things would break if we are not allowed to require modules based on context. -- Ask Solem [EMAIL PROTECTED] . +47 41545862]
Re: New proposed CPANTS metric: prereq_matches_use
Thomas Klausner wrote: The metric will be called prereq_matches_use and shall check if all the modules used in a dist are also listed as a prereq. (prereq is either gatherd directly from Meta.YMLs 'requires', by parsing Build.PL or Makefile.PL) As you might know this is quite tricky, because some modules live in strange dists (e.g. HTTP::Request - libwww-perl) and some modules are in Core (I'll check this with Module::CoreList). The first implementation 'simply' selects all distinct dists from all modules (of which CPANTS know which dist they are in..) used in a dist, and compares this with the distinct dists from all listed prereqs. I have just looked at the latest CPANTS results. I see that all my modules fail this metric... but I am unsure as to why. Consider: http://cpants.perl.org/dist/prereq/Integer-Partition I agree, it's probably best to list Carp, but do I really declare pragmas like 'strict' and 'vars'? How many ISPs remove *them*? Does the metric include modules used in the test suite? I write my test suites to deal gracefully with missing Test modules. David
Re: New proposed CPANTS metric: prereq_matches_use
Is the code for implementing this metric available now? I'm interested in using it to create a utility that generates the appropriate entries in a form suitable for use in Build.PL and Makefile.PL format. --- Matisse Enzer [EMAIL PROTECTED] http://www.matisse.net/ - http://www.eigenstate.net/
Re: New proposed CPANTS metric: prereq_matches_use
On Mon, Nov 19, 2007 at 03:03:51PM -0800, chromatic wrote: On Monday 19 November 2007 14:30:51 Jonathan Rockway wrote: I think the real solution, though, is to agree that the perl interpreter without all of the core modules installed isn't Perl. (I'm not a big fan of core modules, but the concept is especially worthless if you can't depend on their existence.) To your own modules? If so, why on earth is anyone upset about this? Any chance you could convince a few thousand ISPs of that? I'm game. And this is why. Nicholas Clark
Re: New proposed CPANTS metric: prereq_matches_use
On Sat, Nov 17, 2007 at 09:47:57PM -0800, Matisse Enzer wrote: On Nov 15, 2007, at 8:04 PM, A. Pagaltzis wrote: So in order to make everything work robustly, distros should explicitly list every single module they explicitly use ? no shortcuts, no implications. basically, I agree completely, with the possible exception of modules that are in the Perl core Which version of the perl core? Taking a fairly common dependency as an example, Storable was introduced in 5.8.0, so people using 5.6 won't have it unless you declare it as a pre-requisite. You need to list anything that isn't core in the minimum version of perl that you support. And ideally say what that minimum version is. -- David Cantrell | top google result for internet beard fetish club Today's previously unreported paraphilia is tomorrow's Internet sensation
Re: New proposed CPANTS metric: prereq_matches_use
On Mon, Nov 19, 2007 at 04:30:51PM -0600, Jonathan Rockway wrote: I've been yelled at in bug reports and on IRC for adding core modules as prereqs So close the bugs with no bug found and /ignore the twits on irc. -- David Cantrell | Godless Liberal Elitist The Law of Daves: in any gathering of technical people, the number of Daves will be greater than the number of women.
Re: New proposed CPANTS metric: prereq_matches_use
On Sun, 2007-11-18 at 18:51 -0800, Matisse Enzer wrote: On Nov 18, 2007, at 7:25 AM, Andreas J. Koenig wrote: Even if it's in the perl core, the developer may have compiled with -Dnoextensions=Encode In such a case Encode is not present. I have skipped Encode many times because it takes up so much time, others may do likewise. So, I think the bottom line here is: List them ALL in Makefile.PL/ Build.PL I've been yelled at in bug reports and on IRC for adding core modules as prereqs (think upgrading dual-life core modules on older Perl versions; I guess that's not always desirable.) I think the best solution would be something like: # Makefile.PL use 5.8.8; requires 'Encode'; # note that I'm not specifying a version; use 5.8.8 does that for me I think the real solution, though, is to agree that the perl interpreter without all of the core modules installed isn't Perl. (I'm not a big fan of core modules, but the concept is especially worthless if you can't depend on their existence.) Regards, Jonathan Rockway
Re: New proposed CPANTS metric: prereq_matches_use
On Monday 19 November 2007 14:30:51 Jonathan Rockway wrote: I think the real solution, though, is to agree that the perl interpreter without all of the core modules installed isn't Perl. (I'm not a big fan of core modules, but the concept is especially worthless if you can't depend on their existence.) Any chance you could convince a few thousand ISPs of that? I'm game. -- c
Re: New proposed CPANTS metric: prereq_matches_use
On Sat, 17 Nov 2007 21:47:57 -0800, Matisse Enzer [EMAIL PROTECTED]
said:
On Nov 15, 2007, at 8:04 PM, A. Pagaltzis wrote:
So in order to make everything work robustly, distros should
explicitly list every single module they explicitly use no
shortcuts, no implications.
basically, I agree completely, with the possible exception of modules
that are in the Perl core - the standard libraries. On the otehr
hand, if a specific version of a standard library is required then it
most certainly should be listed, for example:
# In Something.pm
use File::HomeDir 0.66;
and
# In Makefile.PL
PREREQ_PM= { 'File::HomeDir' = '0.66' },
Even if it's in the perl core, the developer may have compiled with
-Dnoextensions=Encode
In such a case Encode is not present. I have skipped Encode many times
because it takes up so much time, others may do likewise.
--
andreas
Re: New proposed CPANTS metric: prereq_matches_use
On Nov 18, 2007, at 7:25 AM, Andreas J. Koenig wrote: Even if it's in the perl core, the developer may have compiled with -Dnoextensions=Encode In such a case Encode is not present. I have skipped Encode many times because it takes up so much time, others may do likewise. So, I think the bottom line here is: List them ALL in Makefile.PL/ Build.PL Hmm, sounds like I should create a PPI-based utility that walks a code tree and finds all 'use' and 'require' statements and makes a list for potential use in Makefile.PL / Build.PL --- Matisse Enzer [EMAIL PROTECTED] http://www.matisse.net/ - http://www.eigenstate.net/
Re: New proposed CPANTS metric: prereq_matches_use
On Nov 15, 2007, at 8:04 PM, A. Pagaltzis wrote:
So in order to make everything work robustly, distros should
explicitly list every single module they explicitly use – no
shortcuts, no implications.
basically, I agree completely, with the possible exception of modules
that are in the Perl core - the standard libraries. On the otehr
hand, if a specific version of a standard library is required then it
most certainly should be listed, for example:
# In Something.pm
use File::HomeDir 0.66;
and
# In Makefile.PL
PREREQ_PM= { 'File::HomeDir' = '0.66' },
---
Matisse Enzer [EMAIL PROTECTED]
http://www.matisse.net/ - http://www.eigenstate.net/
Re: New proposed CPANTS metric: prereq_matches_use
In article [EMAIL PROTECTED], A. Pagaltzis [EMAIL PROTECTED] wrote: * brian d foy [EMAIL PROTECTED] [2007-11-13 21:10]: In article [EMAIL PROTECTED], David Cantrell [EMAIL PROTECTED] wrote: On Mon, Nov 12, 2007 at 10:53:42PM +0100, A. Pagaltzis wrote: and: Foo::Bar is in distribution AUTHOR/Foo-Bar which also contains Foo::Bar::Baz, so I only need to declare one of them to get both. This is also an error, as Foo::Bar::Baz might be moved into a seperate distribution at some point in the future Well, that's why you check the current distribution to see what it provides. I do this in Test::Prereq. Consider Test::Harness::Straps getting released as a separate distro recently. Any modules that only use ::Straps but list Test::Harness as a prereq will now fail to install. If Straps is the only thing that you use, then that's the only thing you should list. If Straps has dependencies, it lists those. Test::Prereq would see what the Straps distro provides and only remove those from the prereq list. If Straps doesn't provide anything else, it doesn't remove anything else. I'm not sure why you think it's some other way.
Re: New proposed CPANTS metric: prereq_matches_use
* brian d foy [EMAIL PROTECTED] [2007-11-15 22:40]: If Straps is the only thing that you use, then that's the only thing you should list. If Straps has dependencies, it lists those. Test::Prereq would see what the Straps distro provides and only remove those from the prereq list. If Straps doesn't provide anything else, it doesn't remove anything else. I'm not sure why you think it's some other way. I don’t know what exactly Test::Prereq does. I checked the docs but they don’t say precisely how it behaves. Anyway, irrespective of what ::Prereq does, here’s what I mean: # found in Something.pm use Test::Harness; # found in Other.pm in the same distro use Test::Harness::Straps; This distro should list Test::Harness *and* Test::Harness::Straps as dependencies, even though (at the time of writing) they are both in the same distro. Another example: use Params::Validate; use Scalar::Util; This distro should, again, list both Params::Validate *and* Scalar::Util as prereqs – even though Params::Validate also depends on Scalar::Util. At some point in the future, P::V might cease to depend on S::U, but *this* distro will still depend on it. So in order to make everything work robustly, distros should explicitly list every single module they explicitly use – no shortcuts, no implications. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: New proposed CPANTS metric: prereq_matches_use
On 13 Nov 2007, at 04:29, Geoffrey Young wrote: The metric will be called prereq_matches_use and shall check if all the modules used in a dist are also listed as a prereq. I find this odd. if I check a prereq for mod_perl (.pm) I know I have the 50 some modules that come with a mod_perl distribution. check for LWP and I know I have HTTP::Request. I'm sure the list goes on. While I can accept it's a place where reasonable folk can differ I prefer it where each module is mentioned rather than each distribution. It helps when I'm having to deal with interesting installations where people have managed to get different bits of an installation in different places. However, I suspect that enough folk are of the opposite opinion that a CPANTS metric wouldn't be very useful :-) Adrian
Re: New proposed CPANTS metric: prereq_matches_use
On Tue, 13 Nov 2007 02:08:41 +0100, Sébastien Aperghis-Tramoni [EMAIL PROTECTED] said: There was already a module that does this, I can't remember it's name, Maybe B::Prereq and its companion Test::Dependencies. -- andreas
Re: New proposed CPANTS metric: prereq_matches_use
On Mon, Nov 12, 2007 at 10:53:42PM +0100, A. Pagaltzis wrote: * Thomas Klausner [EMAIL PROTECTED] [2007-11-12 21:10]: The metric will be called prereq_matches_use and shall check if all the modules used in a dist are also listed as a prereq. (prereq is either gatherd directly from Meta.YMLs 'requires', by parsing Build.PL or Makefile.PL) This results in: Of 12039 dists, 5419 have missing deps If a sizable fraction of these are in fact valid hits and not just false negatives due to the trickiness of the problem, then I would say the metric is direly needed! I bet most of them are things like: I need Foo::Bar and Baz::Barf. Foo::Bar requires Baz::Barf so I don't need to declare it. This is an error, because the next version of Foo::Bar might drop that pre-requisite by, eg, implementing the functionality itself or changing to use something else. and: Foo::Bar is in distribution AUTHOR/Foo-Bar which also contains Foo::Bar::Baz, so I only need to declare one of them to get both. This is also an error, as Foo::Bar::Baz might be moved into a seperate distribution at some point in the future, or its functionality might be folded into Foo::Bar. I approve of this kwalitee metric and would like to subscribe to its newsletter^W^W^W^Wbe told which of my modules are broken. -- David Cantrell | top google result for internet beard fetish club One person can change the world, but most of the time they shouldn't -- Marge Simpson
Re: New proposed CPANTS metric: prereq_matches_use
In article [EMAIL PROTECTED], David Cantrell [EMAIL PROTECTED] wrote: On Mon, Nov 12, 2007 at 10:53:42PM +0100, A. Pagaltzis wrote: and: Foo::Bar is in distribution AUTHOR/Foo-Bar which also contains Foo::Bar::Baz, so I only need to declare one of them to get both. This is also an error, as Foo::Bar::Baz might be moved into a seperate distribution at some point in the future Well, that's why you check the current distribution to see what it provides. I do this in Test::Prereq.
Re: New proposed CPANTS metric: prereq_matches_use
* brian d foy [EMAIL PROTECTED] [2007-11-13 21:10]: In article [EMAIL PROTECTED], David Cantrell [EMAIL PROTECTED] wrote: On Mon, Nov 12, 2007 at 10:53:42PM +0100, A. Pagaltzis wrote: and: Foo::Bar is in distribution AUTHOR/Foo-Bar which also contains Foo::Bar::Baz, so I only need to declare one of them to get both. This is also an error, as Foo::Bar::Baz might be moved into a seperate distribution at some point in the future Well, that's why you check the current distribution to see what it provides. I do this in Test::Prereq. Consider Test::Harness::Straps getting released as a separate distro recently. Any modules that only use ::Straps but list Test::Harness as a prereq will now fail to install. If ::Straps were listed as a dependency, installation would continue to Just Work. So if you use any module from the CPAN, you should list it explicitly, not imply it via the main module of its containing distro. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
New proposed CPANTS metric: prereq_matches_use
Hi!
I'm currently thinking about a new CPANTS metric (and I even have a
half-finished implementation..), and I'd like to get some feedback on
it, before spending more time on it (or even releasing it..)
The metric will be called prereq_matches_use and shall check if all the
modules used in a dist are also listed as a prereq. (prereq is either
gatherd directly from Meta.YMLs 'requires', by parsing Build.PL or
Makefile.PL)
As you might know this is quite tricky, because some modules live in
strange dists (e.g. HTTP::Request - libwww-perl) and some modules are in
Core (I'll check this with Module::CoreList).
The first implementation 'simply' selects all distinct dists from all
modules (of which CPANTS know which dist they are in..) used in a dist,
and compares this with the distinct dists from all listed prereqs.
This results in: Of 12039 dists, 5419 have missing deps
Adiitionally, there is a lot of potential finetuning possible:
- do not award the kwalitee point if there are too many listed prereqs
(i.e. the dist requires another dist, without actually using it.)
This might be controversial, because authors could lists dists as a
prereq which are a prereq of a prereq (etc) - for various valid (?)
reasons...
- also check build_requires (I'm not sure if other buildtools than
Module::Build support this), with this twist:
If dists are only used in tests, but are listed in 'requires', do not
award a kwalitee point.
What do you think?
--
#!/usr/bin/perl http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: New proposed CPANTS metric: prereq_matches_use
# from Thomas Klausner # on Monday 12 November 2007 12:05: check if all the modules used in a dist are also listed as a prereq ... by parsing Build.PL or Makefile.PL How do you propose to address system-dependent requirements? (e.g. $^O eq 'MSWin32' issues.) If you do not execute the Makefile.PL/Build.PL, you do not know whether you are working from the correct list of requisites. As you might know this is quite tricky, because some modules live in strange dists (e.g. HTTP::Request - libwww-perl) and some modules are in Core (I'll check this with Module::CoreList). And some modules spring into existence at compile time with Package::Tent :-D Are you planning to implement this with parsing or compiling the code? I would love to see something like run the test suite under Devel::TraceLoad and compare to the prereq list. But that is probably a better author tool than a kwalitee metric, especially if the kwalitee metric is wrong. How about asking the author if they ran such a thing (e.g. checking META.yml for a yes, I did indeed run checkrequires before rolling this dist flag?) In other words: how the metrics has_pod_test and has_pod_coverage_test should have been done in the first place. --Eric -- Cult: A small, unpopular religion. Religion: A large, popular cult. -- Unknown --- http://scratchcomputing.com ---
Re: New proposed CPANTS metric: prereq_matches_use
Hi Thomas, * Thomas Klausner [EMAIL PROTECTED] [2007-11-12 21:10]: The metric will be called prereq_matches_use and shall check if all the modules used in a dist are also listed as a prereq. (prereq is either gatherd directly from Meta.YMLs 'requires', by parsing Build.PL or Makefile.PL) sounds great to me. This results in: Of 12039 dists, 5419 have missing deps If a sizable fraction of these are in fact valid hits and not just false negatives due to the trickiness of the problem, then I would say the metric is direly needed! Adiitionally, there is a lot of potential finetuning possible: - do not award the kwalitee point if there are too many listed prereqs (i.e. the dist requires another dist, without actually using it.) This might be controversial, because authors could lists dists as a prereq which are a prereq of a prereq (etc) - for various valid (?) reasons... -1. At most this should be an optional metric, but even then it’s likely as not to be harmful. - also check build_requires (I'm not sure if other buildtools than Module::Build support this), with this twist: If dists are only used in tests, but are listed in 'requires', do not award a kwalitee point. +1 Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: New proposed CPANTS metric: prereq_matches_use
Thomas Klausner wrote: I'm currently thinking about a new CPANTS metric (and I even have a half-finished implementation..), and I'd like to get some feedback on it, before spending more time on it (or even releasing it..) The metric will be called prereq_matches_use and shall check if all the modules used in a dist are also listed as a prereq. (prereq is either gatherd directly from Meta.YMLs 'requires', by parsing Build.PL or Makefile.PL) As you might know this is quite tricky, because some modules live in strange dists (e.g. HTTP::Request - libwww-perl) There was already a module that does this, I can't remember it's name, and it insisted that each module after a use was listed in PREREQ_PM, which was quite bothersome because it wanted both LWP and HTTP::Request to be listed for example. and some modules are in Core (I'll check this with Module::CoreList). Each time I here checking with Module::CoreList, I wonder which version will be tested against. [...] What do you think? +1 for the rest -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: New proposed CPANTS metric: prereq_matches_use
The metric will be called prereq_matches_use and shall check if all the modules used in a dist are also listed as a prereq. I find this odd. if I check a prereq for mod_perl (.pm) I know I have the 50 some modules that come with a mod_perl distribution. check for LWP and I know I have HTTP::Request. I'm sure the list goes on. --Geoff (who admittedly doesn't really buy into kwalitee metrics anyway :)
