Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PATCH] corelist: Provide access to info on utilities via Module::CoreList::Utils #15652

Open
p5pRT opened this issue Oct 12, 2016 · 6 comments

Comments

@p5pRT
Copy link

p5pRT commented Oct 12, 2016

Migrated from rt.perl.org#129858 (status was 'open')

Searchable as RT129858$

@p5pRT
Copy link
Author

p5pRT commented Oct 12, 2016

From tsibley@cpan.org

See attached patch. Thanks!

@p5pRT
Copy link
Author

p5pRT commented Oct 12, 2016

From tsibley@cpan.org

0001-corelist-Provide-access-to-info-on-utilities-via-Mod.patch
From 95a597b26c7a93488a66172fa78e96a129c79fb8 Mon Sep 17 00:00:00 2001
From: Thomas Sibley <tsibley@cpan.org>
Date: Wed, 12 Oct 2016 10:23:29 -0700
Subject: [PATCH] corelist: Provide access to info on utilities via
 Module::CoreList::Utils

---
 dist/Module-CoreList/corelist | 79 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 78 insertions(+), 1 deletion(-)

diff --git a/dist/Module-CoreList/corelist b/dist/Module-CoreList/corelist
index 9f3d335..3d2706a 100644
--- a/dist/Module-CoreList/corelist
+++ b/dist/Module-CoreList/corelist
@@ -14,6 +14,8 @@ See L<Module::CoreList> for one.
    corelist [-a|-d] <ModuleName> | /<ModuleRegex>/ [<ModuleVersion>] ...
    corelist [-v <PerlVersion>] [ <ModuleName> | /<ModuleRegex>/ ] ...
    corelist [-r <PerlVersion>] ...
+   corelist --utils [-d] <UtilityName> [<UtilityName>] ...
+   corelist --utils -v <PerlVersion>
    corelist --feature <FeatureName> [<FeatureName>] ...
    corelist --diff PerlVersion PerlVersion
    corelist --upstream <ModuleName>
@@ -113,6 +115,15 @@ lists all of the perl releases and when they were released
 
 If you pass a perl version you get the release date for that version only.
 
+=item --utils
+
+lists the first version of perl each named utility program was released with
+
+May be used with -d to modify the first release criteria.
+
+If used with -v <version> then all utilities released with that version of perl
+are listed, and any utility programs named on the command line are ignored.
+
 =item --feature, -f
 
 lists the first version bundle of each named feature given
@@ -142,7 +153,7 @@ my %Opts;
 
 GetOptions(
     \%Opts,
-    qw[ help|?! man! r|release:s v|version:s a! d diff|D feature|f u|upstream ]
+    qw[ help|?! man! r|release:s v|version:s a! d diff|D utils feature|f u|upstream ]
 );
 
 pod2usage(1) if $Opts{help};
@@ -181,6 +192,12 @@ if(exists $Opts{v} ){
     }
 
     my $num_v = numify_version( $Opts{v} );
+
+    if ($Opts{utils}) {
+        utilities_in_version($num_v);
+        exit 0;
+    }
+
     my $version_hash = Module::CoreList->find_version($num_v);
 
     if( !$version_hash ) {
@@ -227,6 +244,25 @@ if ($Opts{diff}) {
     exit(0);
 }
 
+if ($Opts{utils}) {
+    die "\n--utils only available with perl v5.19.1 or greater\n"
+        if $] < 5.019001;
+
+    die "\nprovide at least one utility name to --utils\n"
+        unless @ARGV;
+
+    warn "\n-a has no effect when --utils is used\n"                 if $Opts{a};
+    warn "\n--diff has no effect when --utils is used\n"             if $Opts{diff};
+    warn "\n--upstream, or -u, has no effect when --utils is used\n" if $Opts{u};
+
+    my $when = maxstr(values %Module::CoreList::released);
+    print "\n","Data for $when\n";
+
+    utility_version($_) for @ARGV;
+
+    exit(0);
+}
+
 if ($Opts{feature}) {
     die "\n--feature is only available with perl v5.16.0 or greater\n"
       if $] < 5.016;
@@ -364,6 +400,47 @@ sub module_version {
     }
 }
 
+sub utility_version {
+    my ($utility) = @_;
+
+    require Module::CoreList::Utils;
+
+    my $released = $Opts{d}
+        ? Module::CoreList::Utils->first_release_by_date($utility)
+        : Module::CoreList::Utils->first_release($utility);
+
+    my $removed = $Opts{d}
+        ? Module::CoreList::Utils->removed_from_by_date($utility)
+        : Module::CoreList::Utils->removed_from($utility);
+
+    if ($released) {
+        print "$utility was first released with perl ", format_perl_version($released);
+        print " and later removed in ", format_perl_version($removed)
+            if $removed;
+        print "\n";
+    } else {
+        print "$utility was not in CORE (or so I think)\n";
+    }
+}
+
+sub utilities_in_version {
+    my ($version) = @_;
+
+    require Module::CoreList::Utils;
+
+    my @utilities = Module::CoreList::Utils->utilities($version);
+
+    if (not @utilities) {
+        print "\nModule::CoreList::Utils has no info on perl $version\n\n";
+        exit 1;
+    }
+
+    print "\nThe following utilities were in perl ",
+        format_perl_version($version), " CORE\n";
+    print "$_\n" for sort { lc($a) cmp lc($b) } @utilities;
+    print "\n";
+}
+
 
 sub max_mod_len {
     my $versions = shift;
-- 
2.8.3

@p5pRT
Copy link
Author

p5pRT commented Oct 13, 2016

From @jkeenan

On Wed Oct 12 10​:36​:25 2016, tsibley wrote​:

See attached patch. Thanks!

Do we have tests for the 'corelist' utility apart from Module​::CoreList? If so, should we add tests (as these changes are all in the utility)?

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Oct 13, 2016

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Oct 13, 2016

From tsibley@cpan.org

On 10/12/2016 07​:09 PM, James E Keenan via RT wrote​:

On Wed Oct 12 10​:36​:25 2016, tsibley wrote​:

See attached patch. Thanks!

Do we have tests for the 'corelist' utility apart from
Module​::CoreList? If so, should we add tests (as these changes are
all in the utility)?

As far as I could tell, there aren't any tests of the corelist utility
itself. Thus, I didn't add any in this patch.

corelist would probably benefit from some level of testing. The logic
of its different modes and interactions of the various flags is quite
messy and thus presumably easy to break accidentally.

I'm not necessarily volunteering to do the work of adding comprehensive
tests for all of corelist, but I would write tests for this new feature
if they're deemed necessary.

Thomas

@p5pRT
Copy link
Author

p5pRT commented Jun 1, 2017

From @jkeenan

On Thu, 13 Oct 2016 23​:54​:09 GMT, tsibley wrote​:

On 10/12/2016 07​:09 PM, James E Keenan via RT wrote​:

On Wed Oct 12 10​:36​:25 2016, tsibley wrote​:

See attached patch. Thanks!

Do we have tests for the 'corelist' utility apart from
Module​::CoreList? If so, should we add tests (as these changes are
all in the utility)?

As far as I could tell, there aren't any tests of the corelist utility
itself. Thus, I didn't add any in this patch.

corelist would probably benefit from some level of testing. The logic
of its different modes and interactions of the various flags is quite
messy and thus presumably easy to break accidentally.

I'm not necessarily volunteering to do the work of adding comprehensive
tests for all of corelist, but I would write tests for this new feature
if they're deemed necessary.

Thomas

Could we get this patch reviewed by people knowledgeable about Module​::CoreList?

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants