Re: On naming new module for the eBay API

[Dan Book]

On Thu, Aug 25, 2022 at 2:11 PM David Shere  wrote:

> I am considering contributing a new module for using the eBay API.  I have
> read this https://pause.perl.org/pause/query?ACTION=pause_namingmodules
> and have noted the existence of several other eBay API modules including
> Net::eBay and eBay::API.  I also see the discussion last month on this list
> for usage of the WebService namespace.  I’d like to use WebService::eBay
> and welcome any comments, suggestions, or smart remarks.
>

Seems reasonable to me

-Dan

Re: Seeking naming guidance

[Dan Book]

On Sat, Mar 12, 2022 at 1:55 PM Jim Avera  wrote:

> Hello World,
>
> I'm seeking guidance on naming a module to avoid inappropriately
> stepping on existing namespace.
>
> The module is a wrapper for (actually subclass of) Data::Dumper with a
> fairly large API.  But its most distinguishing feature is interpolating
> strings where massaged Data::Dumper output is substituted for variable
> references.
>
> Locally this has been in use for years as module "Vis", but now that I'm
> going to contribute it to CPAN I thought it would be best to rename the
> module to something like
>
>Data::Dumper::Interpolate# Most suggestive, but a lot to type
>Data::Dumper::Interp# less typing, still sort-of suggestive
>Data::Interpolate   # even less typing but more vague
>
> My first question is whether placing *anything* below Data::Dumper is
> appropriate.  Obviously my module is not supported or sanctioned by the
> authors of Data::Dumper.
>
> Thanks for any help!
>
> -Jim Avera
>
> P.S. For specifics, please run
>
>  perldoc http://abhweb.org/jima/perl/lib/Data/Dumper/Interp.pm
>
> (module name is tentative of course)
>
>
>
>
There isn't a Data::Dumper ecosystem, and there are already similar modules
under the Data::Dumper:: namespace (e.g. Data::Dumper::HTML,
Data::Dumper::Lazy, Data::Dumper::Concise) so I think it is perfectly
appropriate.

-Dan

Re: Math::BigInt and bigint with non-integers

[Dan Book]

On Thu, Aug 19, 2021 at 4:18 AM Peter John Acklam 
wrote:

> Hi!
>
> I would like some input on how the Math::BigInt module and bigint pragma
> should handle non-integers. The current behaviour is rather inconsistent.
>
> The new() constructor converts a non-integer to a Math::BigInt NaN:
>
> $ perl -MMath::BigInt -wle 'print Math::BigInt -> new("3.16")'
> NaN
>
> A math operation that returns a non-integer, returns a Math::BigInt with
> the
> truncated value:
>
> $ perl -MMath::BigInt -wle 'print Math::BigInt -> new("10") -> bsqrt()'
> 3
>
> Math::BigInt with overloading of constants, leave a non-integer as an
> unmodified Perl scalar:
>
> $ perl -MMath::BigInt=:constant -wle 'print 3.16'
> 3.16
>
> However, when the "bigint" pragma is used for overloading constants, a
> non-integer becomes a Math::BigInt with the truncated value:
>
> $ perl -Mbigint -wle 'print 3.16'
> 3
>
> I'm not saying that all four cases should return the same value, but
> returning three different values seems too much. Any suggestions?
>

Truncation to integer seems the most useful and expected behavior to me.
Not sure if the "overloading of constants" case should be affected, would
people depend on it staying unmodified?

-Dan

Re: How to handle minimum versions of dependencies which are recommended but not required?

[Dan Book]

On Sun, Aug 8, 2021 at 3:35 PM Diab Jerius  wrote:

> Howdy!
>
> I've a module (
> https://metacpan.org/release/DJERIUS/Data-Record-Serialize-0.27-TRIAL)
> which may use JSON and YAML writers.
>
> For JSON, I use JSON::MaybeXS.  Cpanel::JSON::XS >= 3.0236 is required.
>
> My code can use either YAML::XS or YAML::PP.  YAML::XS  >= 0.67 is
> required.
>
> Since JSON & YAML output are optional, I've encoded the XS dependencies as
> runtime recommendations, rather than requirements. JSON::MaybeXS is
> specified as a runtime dependency (as is YAML::PP, but that's a mistake; it
> should also be a runtime recommendation).
>
> Here are the relevant bits of  META.json (
> https://metacpan.org/release/DJERIUS/Data-Record-Serialize-0.27-TRIAL/source/META.json#L98
> )
>
>   "runtime" : {
>  "recommends" : {
> "Cpanel::JSON::XS" : "3.0236",
> "JSON::PP" : "0",
> "YAML::XS" : "0.67"
>  },
>  "requires" : {
> "JSON::MaybeXS" : "0",
> "YAML::PP" : "0",
>  }
>   },
>
> Here's the problem, illustrated by this CPAN testers failure:
>
> http://www.cpantesters.org/cpan/report/2f961e48-6bf6-1014-90df-a468c69b7236
>
> The smoker has versions of Cpanel::JSON::XS and YAML::XS which are older
> than my required versions.  Since the ::XS versions are prioritized over
> the ::PP versions, the code uses those and thus fails the tests.   I
> presume that because the ::XS versions are  recommendations rather than
> requirements, they weren't updated to the versions that the code requires.
>
> Is there some way of triggering an update to the required versions via the
> metadata, or should I put a runtime version check into the tests and skip
> if the appropriate versions aren't installed?
>
> For production runs, I'll have to add a runtime check in the code which
> falls back to YAML::PP if the version of YAML::XS is too old, but I don't
> see how I can do that with JSON::MaybeXS, as there are no hooks to indicate
> acceptable versions of the backend.  I think my only option is to take the
> same approach as for YAML, namely manually specifying which backend
> libraries are acceptable.  I don't like this, as now I can't automatically
> take advantage of JSON::MaybeXS's list of backends.
>
> Any advice on how to gracefully handle this situation?
>

There's only two real options, and you might want to do both:

Dynamically add a runtime requires on the required version if you detect
that the optional module is installed but too old. With dzil you can do
this with https://metacpan.org/pod/Dist::Zilla::Plugin::DynamicPrereqs.

At runtime, ensure that the module satisfies your minimum version if it is
present, and if not treat it as if it was not installed.

-Dan

(resent to list)

Re: New module: Type::Tie::Full

[Dan Book]

On Fri, Apr 30, 2021 at 4:23 AM Asher Gordon  wrote:

> Hello,
>
> I'm writing a new module that exports a similar interface to Type::Tie,
> but performs a type check on the entire variable each time it is
> changed. Obviously, this is much more expensive, but it can be useful
> for types like Types::Standard::Dict in cases where speed is not very
> important.
>
> In case you're not familiar with Type::Tie, here's a brief summary:
> Type::Tie exports a single function, ttie(), which ties variables to
> types. For example, after
>
> use Type::Tie;
> use Types::Standard qw(Num);
>
> ttie my $num, Num;
>
> setting $num to anything but a number will die. And
>
> ttie my @num_list, Num;
>
> only allows numbers in @num_list. So
>
> push @num_list, "foo";
>
> will die.
>
> Type::Tie::Full (the working name for my module) is similar, except that
> the entire variable (as a reference) is passed to the type checker. The
> sole exception to this is tying scalars--in this case, the referenced
> scalar will be passed to the type checker rather than the reference
> itself.
>
> For example, this works correctly:
>
> use Type::Tie::Full;
> use Types::Standard qw(Dict Optional Str Num);
>
> ttie my %dict, Dict[string => Str, number => Optional[Num]],
> string => 'foo';
>
> $dict{string}   = 'bar';# ok
> $dict{number}   = 42;   # ok
> $dict{nonexistent}  = 'foo';# dies
> $dict{number}   = 'foo';# dies
>
> delete $dict{string};   # dies ('string' is not optional)
> delete $dict{number};   # ok ('number' is optional)
>
> Currently, only one layer of tying is performed, which means things like
> the following don't work how I would like them to:
>
> use Type::Tie::Full;
> use Types::Standard qw(HashRef Num);
>
> ttie my $hashref, HashRef[Num], {};
>
> $hashref = { foo => 'bar' }; # dies ('bar' is not a number)
> $hashref->{foo} = 'bar'; # doesn't die, but probably should
>
> I intend to implement this using deep tying, but it doesn't work for
> now.
>
> My question is, does the name make sense for this module? I figure since
> it performs a full check on the variable every time it is changed (as
> opposed to a check on just the added elements), then it makes sense to
> call it that. Would you agree?
>

Any namespace under Type::Tie you like seems appropriate to me. One
suggestion I have is Type::Tie::Aggregate, since it performs a type check
on the aggregate variables rather than the elements.

-Dan

Re: CPAN meta resources and MetaCPAN

[Dan Book]

On Sat, Apr 10, 2021 at 8:28 PM Asher Gordon  wrote:

> Hello,
>
> I've noticed that the MetaCPAN page for many modules on CPAN has links
> to homepages and/or git/hg/etc. repositories. I assume these links are
> generated from the 'resources' field in the meta specification
> (META.json or META.yml), right?
>

Correct. The issue tracker defaults to the auto-generated tracker on
https://rt.cpan.org/ if none is specified; the others have no default.


> If I want the homepage, bugtracker, etc. to be the ones provided by
> MetaCPAN and CPAN, it would be redundant to specify them in the meta
> spec, no? And also, should I provide 'resources.license'? Dist::Zilla
> doesn't seem to do that by default despite knowing the license of the
> project and URL to the license.
>

MetaCPAN and CPAN do not provide any of these things, only the RT issue
tracker would be assumed if you don't specify any. The homepage field is
primarily useful if there is a website relevant to the distribution
separate from its documentation/repository/issue tracker.

Feel free to specify the license field in resources, but it is just for
URLs to license text which is not necessary if you provide the text of your
licenses in the distribution, as most dzil dists do automatically. The top
level license array is where the license(s) of the distribution is
specified.

-Dan

Re: Prereq scanners for Dist::Zilla and Pod::Weaver plugin bundles

[Dan Book]

On Thu, Apr 8, 2021 at 2:59 PM Asher Gordon  wrote:

> Hello,
>
> As I've already mentioned, I've Dist::Zilla and Pod::Weaver plugin
> bundles for use in my projects
> (Dist::Zilla::PluginBundle::Author::ASDAGO and
> Pod::Weaver::PluginBundle::Author::ASDAGO). However, I noticed that
> prerequisites on other plugins and plugin bundles are not detected by
> AutoPrereqs. As far as I could tell, there didn't exist any scanners for
> Perl::PrereqScanner that could scan Dist::Zilla and Pod::Weaver plugin
> bundles, so I wrote my own.
>
> So far, they work pretty well (the Dist::Zilla one currently only works
> on Dist::Zilla::Role::PluginBundle::Easy plugin bundles). My working
> names for them are Perl::PrereqScanner::Scanner::PluginBundle::DistZilla
> and Perl::PrereqScanner::Scanner::PluginBundle::PodWeaver. Are these
> names satisfactory? I was also thinking something like
> Perl::PrereqScanner::Scanner::DistZillaPluginBundle in case they would
> get confused as plugin bundles for Perl::PrereqScanner itself. What do
> you think? Also, I think that they're different enough to release as
> separate packages.
>
> Another thing is, the Pod::Weaver plugin bundle scanner works by looking
> for any anonymous array references of three elements where the last one
> is an anonymous hash reference. Since plugins could be stored in
> variables before they are returned from mvp_bundle_config() (indeed,
> these seems to usually be the case), this is really the only reasonably
> reliable method of detecting prerequisites short of actually running the
> file.
>
> Unfortunately, this also means there are sometimes false positives. For
> example, in RJBS's Dist::Zilla plugin bundle, my Pod::Weaver plugin
> bundle scanner detects two false positives:
> Pod::Weaver::Section::CPAN-Outdated and
> Pod::Weaver::Section::RJBS-Outdated. This is because they are specified
> to add_plugins() as an anonymous array reference of three elements with
> the last one being an anonymous hash reference, which, you will recall,
> is exactly what my Pod::Weaver plugin bundle scanner looks for.
>
> Of course, the Pod::Weaver plugin bundle scanner should not be run on a
> Dist::Zilla plugin bundle, but since RJBS's Dist::Zilla and Pod::Weaver
> plugin bundles are packaged together (which is what I was planning to do
> with my plugin bundles, though I may rethink that), I don't think it's
> possible (correct me if I'm wrong) to use different scanners for each
> file with the AutoPrereqs plugin. One solution would be to write another
> plugin similar to AutoPrereqs, but that allows per-file scanners to be
> specified. Another (perhaps better) solution would be to package the
> Dist::Zilla and Pod::Weaver plugin bundles separately, and use a
> different scanner for each package. Let me know if you have any opinions
> on how that should be done.
>
> Sorry for the long message (especially the first sentence of the fifth
> (previous) paragraph), and thanks for any help.


These are some interesting ideas but perhaps a bit too narrow in scope for
this particular list (other than perhaps the naming of modules). There
isn't a functional dzil mailing list anymore but you might consider joining
#distzilla on irc.perl.org to have such in depth discussions:
https://kiwiirc.com/client/irc.perl.org/distzilla

-Dan

Re: New module: Text::Wrap::OO

[Dan Book]

On Tue, Apr 6, 2021 at 2:19 PM Asher Gordon  wrote:

> Hi everyone,
>
> I have just written my first Perl module (that I'm going to release). It
> is an object oriented interface to Text::Wrap. My question is, what do
> you think of the name? Is it a good name, descriptive enough? And do you
> have any other advice for releasing my first module?
>
> I don't currently have it released anywhere (I'll eventually have the
> git repository on sv.nongnu.org), and I'm not sure if an attached
> tarball would be appreciated (I can attach it if requested), but here's
> the SYNOPSIS so you can get an idea of what it does and how it works:
>
> SYNOPSIS
>Object oriented interface
>use Text::Wrap::OO;
>
>my $wrapper = Text::Wrap::OO->new(init_tab => "\t");
>$wrapper->columns(70);
>my $wrapped = $wrapper->wrap($text);
>
>Static method interface
>use Text::Wrap::OO;
>
>my $wrapped = Text::Wrap::OO->wrap(
>{
>init_tab=> "\t",
>columns => 70,
>}, $text,
>);
>
>Exported interface
>use Text::Wrap::OO 'wrap',
>wrap => { columns => 70, -as => 'wrap70' };
>
>my $wrapped = wrap {
>init_tab=> "\t",
>columns => 60,
>}, $text;
>
>my $wrapped_70 = wrap70 {
>huge => 'overflow',
>}, $text;
>
> Thanks in advance,
> Asher
>
> P.S. https://pause.perl.org/pause/query?ACTION=pause_namingmodules seems
> to indicate that this is a good list for this type of question. Sorry if
> I was mistaken.
>
> --
> I have no doubt that it is a part of the destiny of the human race,
> in its gradual improvement, to leave off eating animals.
> -- Thoreau
>
> I prefer to send and receive mail encrypted. Please send me your
> public key, and if you do not have my public key, please let me
> know. Thanks.
>
> GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68
>

It's a fine list for that purpose. You may also seek feedback on
https://perldoc.perl.org/perlcommunity#IRC or https://www.reddit.com/r/perl/
.

The name and design seem fine to me. Just beware providing so many options
for doing the same thing that you'll have to support them all (common
mistake of the "DWIM era" of CPAN), sometimes it is better to keep things
simple and only add alternative options once they are useful.

Also make sure you are aware that CPAN distributions must be packaged a
specific way. The first few sections of
https://metacpan.org/pod/Dist::Zilla::Starter go over this and some modern
options for authoring (you don't have to use Dist::Zilla unless it fits
your approach). http://tynovsky.github.io/cpan-tutorials/ also lays out a
quick guide to authoring with Minilla.

-Dan

Re: Algorithm-SkipList

[Dan Book]

On Thu, Feb 25, 2021 at 1:44 AM John M. Gamble  wrote:

> I was surprised to see Algorithm-SkipList marked as owned by ADOPTME in
> PAUSE, which is not the case in MetaCPAN, where it is owned by Robert
> Rothenburg (although it is marked for adoption, see
> ).
>

  The author displayed on a PAUSE release page is the author that uploaded
that release. It has no bearing on the permissions for the modules in the
distribution, other than that they had some permission at the time of
upload (if it doesn't say UNAUTHORIZED).

-Dan

Re: rt.cpan.org sunsetting / updating module git and issues

[Dan Book]

On Tue, Dec 8, 2020 at 6:42 PM Adam Spann  wrote:

> Hi All,
>
> With the prospect of RT being sunset. I am looking into updating my two
> humble modules so that they contain issues links on metacpan. Currently
> they default to rt.cpan.org
>
> I have the example config details from:
>
> https://www.perl.com/article/how-to-upload-a-script-to-cpan/
> and
>
> https://perlmaven.com/how-to-add-link-to-version-control-system-of-a-cpan-distributions
>
> But I am not sure if I actually need to bump my module versions to get
> this update accepted into cpan.
>
> Could anyone point my in the right direction?
>

Yes, you need to make a new release with new versions to propagate your new
metadata to CPAN and have it then extracted and displayed by MetaCPAN.

-Dan

Re: Module name hierarchy...

[Dan Book]

On Wed, Sep 30, 2020 at 1:56 AM BC  wrote:

> The only thing I don't like is that it feels like I am squatting on
> something fairly generic near the top of the name space.  If I were to
> push my one and only module down a level as:
>
> Class::Fault::Foobar
>
> would it be a faux pas if there is no Class/Fault.pm or anything else
> at that second level?
>

There is no requirement or reason that each step of the module hierarchy
needs to exist as a separate module. (Just imagine if that was needed for
https://metacpan.org/pod/Acme::Working::Out::Dependencies::From::META::files::Will::Be::Wrong::At::Some::Point::Like::This::Module::For::Instance
)

-Dan

Re: Module name hierarchy...

[Dan Book]

On Fri, Sep 25, 2020 at 2:20 PM BC  wrote:

> Let's say I wanted to submit a module named:
>
>  Class::Error::Foobar
>
> Would this be considered bad form if my "Foobar" module is not related
> to the existing Class::Error module in any way?  In other words,
> Foobar does not depend on, extend, nor reference the Class::Error
> module other than perhaps a courtesy "See Also" mention.
>

It is not necessarily bad form, but if there is an existing "Class::Error"
ecosystem you might consider asking the author first in case they wanted to
use that sub-namespace. That does not really seem to be the case here.

-Dan

Re: Changes to WWW-Mechanize-Query proposal - small fix 1

[Dan Book]

On Sun, Jul 5, 2020 at 6:25 PM Nikolay Chegodaev 
wrote:

> Hi San,
> Hi Module Authors,
>
> My name is Nikolay. I am a Perl enthusiast and worked as Perl Developer
> for 5 years. I am writing to you because of the Olaf Alders advice - the
> Gitpan repository keeper - https://github.com/gitpan. He told me that you
> may help to publish changes for the module to reflect the recent changes in
> Mojo::DOM, WWW::Mechanize::Query is dependent on Mojo::DOM or so it seems.
> The module is a really good approach and I do not think it would be good to
> leave it like this. Writing to both superasn email and module authors in
> the hope that some email would answer.
>
>  have tried to use https://github.com/gitpan/WWW-Mechanize-Query to
> implement a really small project on Perl v5.26.1 and encountered a number
> of errors which prevent me from using the module. In fact errors probably
> reflect recent changes in https://metacpan.org/pod/Mojo::DOM module which
> is a dependence for WWW-Mechanize-Query.
>
> I have made some testing changes to the module Query.pm on my localhost,
> which solved the issue for me. *Do you mind if I share them public and
> commit them to the repository, with your code review of course?*
>
> The changes are seem to be small and mostly related to sub input of the
> Query.pm module ( link to Gitpan project
> 
>  )
> for Perl v5.26.1 and Mojo::DOM  the
> changes list for now only seem to include the following:
> 1) change all attrs calls to attr call - for example $ele->attrs( 'type' )
> to $ele->attr( 'type' )
> 2) change ->type call to ->tag call at the place where we check if the
> type of the element submitted is correct, but the information we check
> contains in ->tag attribute, not in the ->type attribute. -> type attribute
> only contains a "tag" in it since select or text boxes are considered like
> so in the new edition of Mojo::DOM it seems. For example: *} elsif (
> $ele->type =~ /select/i ) { should be changed to } elsif ( $ele->tag =~
> /select/i ) {*
> 3) change $dom->to_xml to just just dom at the response of the sub input
> for example: $self->update_html( $dom->to_xml ); to $self->update_html(
> $dom); to_xml seem not to be used in Mojo::DOM as far as I tested and it
> seems like just $dom already contains the xml content
>
> Please kindly find attached Query.pm with the changes - I have taken an
> audacity to change the version, please accept apologies if I should not.
>
> The attached module reflects the changes mentioned in the fields 1)-3). I
> have tested them on my localhost - seems working. Also while the module
> being used in combo with the WWW::Mechanize there are issues with the
> posting the forms - older format of form fields in there so debugging it at
> the moment, while working on my script/snippet - so probably a second fix
> to follow.
>

Hi Nikolay,

The issue tracker for this module is at
https://rt.cpan.org/Public/Dist/Display.html?Name=WWW-Mechanize-Query. I
did not find a github repository for the module. Only the maintainers would
be able to decide what changes should be made to the module.

-Dan

Re: The Math-Matrix distribution

[Dan Book]

On Tue, Apr 28, 2020 at 11:56 AM Peter John Acklam 
wrote:

> To the PAUSE admins,
>
> I would like to take over the responsibility of the Math-Matrix
> distribution / the Math::Matrix module.
>
> I contacted the three authors listed in the Math::Matrix POD, Ulrich
> Pfeifer, Brian J. Watson, and Matthew Brett. All three e-mails bounced back
> to me because of invalid e-mail addresses.
>
> Then I contacted BIRKETT and ULPFR via their @cpan.org addresses. These
> two are listed on the page
> https://rt.cpan.org/Dist/Display.html?Name=Math-Matrix. BIRKETT (William
> B. Birkett) replied that he has never had any involvement in the module and
> doesn't even know why he is listed on that page. ULPFR (Ulrich Pfeifer),
> who released the most recent version of Math-Matrix in 2013, has not
> replied.
>
> I would be grateful if one of the PAUSE admins could add me as first-come
> or at least as co-maintainer.
>
> Kind regards,
> Peter John Acklam / PJACKLAM on CPAN
>

Hi,

This is the list for CPAN authors to discuss amongst themselves - to reach
the PAUSE admins, mail modu...@perl.org (and CC interested parties).

-Dan

Re: How to do co-maintenance on CPAN distro which uses Dist::Zilla (Travis and other questions)

[Dan Book]

On Thu, Jan 23, 2020 at 3:04 PM James E Keenan  wrote:

> 3.  Assume that I am the co-maintainer of the distribution but have
> rights to push to the original author's repository, which will remain
> the canonical repository.  How do I then get the CPAN release to show up
> under my CPAN ID (JKEENAN)?
>

Not sure I understand the question here. The CPAN release and its upload
has nothing to do with the source repository, and will be entirely up to
the PAUSE credentials you use when doing `dzil release`. The metadata
referring to the GitHub repository is, in this case, controlled by the use
of the [MetaResources] plugin, so if that repository is still being used
then no change is needed there.

-Dan

Re: How to do co-maintenance on CPAN distro which uses Dist::Zilla (Travis and other questions)

[Dan Book]

On Thu, Jan 23, 2020 at 3:04 PM James E Keenan  wrote:

> I have been granted COMAINT status by Paul Fenwick on CPAN distribution
> IPC-System-Simple.  This distribution is built and maintained using
> Dist::Zilla and quite a few Dist::Zilla plugins.  I do not, in general,
> use Dist::Zilla in any of my own CPAN distributions.  It's much too
> "auto-magicky" for my needs and taste, so I only use it when, say, I
> have to diagnose a test failure in a "CPAN-River-3000" module.
>
> But in this case I have to use dzil, so I'd like to get some answers to
> specific questions en route to formulating what (for me, at least) will
> be best practices for maintaining this distribution going forward.
>
> 1.  How do I add a Travis-CI configuration to a distribution maintained
> with Dist::Zilla?
>
> The IPC-System-Simple repository did not have a .travis.yml
> configuration file when I cloned the repo, so I added one (attached)
> copied from one of my other CPAN distros where it DWIMs.  I made no
> changes in dist.ini.  The only other change I made was to modify a test
> to deal with the github issue that led me to request comaintenance on
> this distro in the first place.  I activated the configuration under my
> Travis account and pushed to github.  However, the Travis build failed,
> here:
>
> #
> https://travis-ci.org/jkeenan/ipc-system-simple/jobs/641031415
> #
>
> This build failed with this log output:
>
> #
> [DZ] attempt to add META.json multiple times; added by: text from
> coderef added by MetaJSON (Dist::Zilla::Plugin::MetaJSON line 91);
> filename set by GatherDir (Dist::Zilla::Plugin::GatherDir line 225);
> encoded_content added by @Basic/GatherDir
> (Dist::Zilla::Plugin::GatherDir line 226)
>
> [DZ] attempt to add t/author-pod-coverage.t multiple times; added by:
> content added by PodCoverageTests (Dist::Zilla::Plugin::InlineFiles line
> 33); filename set by ExtraTests (Dist::Zilla::Plugin::ExtraTests line
> 54); content set by ExtraTests (Dist::Zilla::Plugin::ExtraTests line
> 67); filename set by GatherDir (Dist::Zilla::Plugin::GatherDir line
> 225); encoded_content added by @Basic/GatherDir
> (Dist::Zilla::Plugin::GatherDir line 226)
>
> [DZ] attempt to add t/author-pod-syntax.t multiple times; added by:
> content added by PodSyntaxTests (Dist::Zilla::Plugin::InlineFiles line
> 33); filename set by ExtraTests (Dist::Zilla::Plugin::ExtraTests line
> 54); content set by ExtraTests (Dist::Zilla::Plugin::ExtraTests line
> 67); filename set by GatherDir (Dist::Zilla::Plugin::GatherDir line
> 225); encoded_content added by @Basic/GatherDir
> (Dist::Zilla::Plugin::GatherDir line 226)
>
> [DZ] attempt to add t/author-critic.t multiple times; added by: content
> added by Test::Perl::Critic (Dist::Zilla::Plugin::Test::Perl::Critic
> line 42); filename set by ExtraTests (Dist::Zilla::Plugin::ExtraTests
> line 54); content set by ExtraTests (Dist::Zilla::Plugin::ExtraTests
> line 67); filename set by GatherDir (Dist::Zilla::Plugin::GatherDir line
> 225); encoded_content added by @Basic/GatherDir
> (Dist::Zilla::Plugin::GatherDir line 226)
>
> [DZ] attempt to add META.yml multiple times; added by: filename set by
> GatherDir (Dist::Zilla::Plugin::GatherDir line 225); encoded_content
> added by @Basic/GatherDir (Dist::Zilla::Plugin::GatherDir line 226);
> text from coderef added by @Basic/MetaYAML
> (Dist::Zilla::Plugin::MetaYAML line 70)
>
> [DZ] attempt to add LICENSE multiple times; added by: filename set by
> GatherDir (Dist::Zilla::Plugin::GatherDir line 225); encoded_content
> added by @Basic/GatherDir (Dist::Zilla::Plugin::GatherDir line 226);
> content added by @Basic/License (Dist::Zilla::Plugin::License line 37)
>
> [DZ] attempt to add README multiple times; added by: filename set by
> GatherDir (Dist::Zilla::Plugin::GatherDir line 225); encoded_content
> added by @Basic/GatherDir (Dist::Zilla::Plugin::GatherDir line 226);
> content added by @Basic/Readme (Dist::Zilla::Plugin::Readme line 44);
> content set by Readme (Dist::Zilla::Plugin::Readme line 61)
>
> [DZ] attempt to add Makefile.PL multiple times; added by: filename set
> by GatherDir (Dist::Zilla::Plugin::GatherDir line 225); encoded_content
> added by @Basic/GatherDir (Dist::Zilla::Plugin::GatherDir line 226);
> content set by MakeMaker (Dist::Zilla::Plugin::MakeMaker line 329);
> content added by @Basic/MakeMaker (Dist::Zilla::Plugin::MakeMaker line 144)
>
> [DZ] attempt to add MANIFEST multiple times; added by: filename set by
> GatherDir (Dist::Zilla::Plugin::GatherDir line 225); encoded_content
> added by @Basic/GatherDir (Dist::Zilla::Plugin::GatherDir line 226);
> bytes from coderef added by @Basic/Manifest
> (Dist::Zilla::Plugin::Manifest line 55)
>
> aborting; duplicate files would be produced at
>
> /home/travis/perl5/perlbrew/perls/5.30.0/lib/site_perl/5.30.0/Dist/Zilla/App/Command/
> build.pm
> line 97.
>
> The command "build-dist" failed and exited with 255 during .
> #
>
> So, what do I need to do to get 

Re: TimeDate and indexing permissions

[Dan Book]

Thank you for the action, all those who volunteered, and atoomic for the
prompt fixed release!

-Dan

On Thu, Jan 16, 2020 at 6:05 PM Neil Bowers  wrote:

> A number of people volunteered to take on TimeDate and address the
> breakage. Thank you to all who did.
>
> Given this distribution is fairly far up the CPAN River (more than 8700
> other CPAN distributions ultimately dependent on it), the PAUSE admins had
> a discussion on who was the best candidate, in terms of CPAN experience,
> the support they have, etc.
>
> As a result we selected Nicolas R (ATOOMIC). I have transferred first-come
> indexing permission on all packages in the distribution to ATOOMIC. Graham
> retains co-maint.
>
> This also points out that we could do with some kind of monitoring system,
> to spots sudden changes in CPAN test results (without a new release). In
> this case lots of people noticed that things started failing, but earlier
> warning in the right place would be useful.
>
> Thanks also to Graham for being happy to pass this on, and his work in
> getting it to this point.
>
> Neil
>
>

Re: [RFC] File::TVShow::Parse

[Dan Book]

It would be either the job of the install script or static install process
to determine that the Perl is too old, yes. In the former case, it's
commonly hard-blocked by a "use 5.XXX" statement in the Makefile.PL or
Build.PL, in the legacy format, as META.json is only used for configure
phase prereqs in this case. In the latter case it would be via the perl
runtime prereq in META.json - and only by an installer new enough to
understand all of this anyway.

This is all just for what version of Perl you support, though; for your
module version, as long as you have a declared Perl minimum version in one
of these ways, either version format is fine.

-Dan

On Tue, Apr 16, 2019 at 5:09 PM John M. Gamble  wrote:

> I'm already on record on not supporting anything older than 5.10.1*. But
> the reason I mentioned the META.* files is because I would think (well,
> hope) that that in itself should be enough to prevent older Perls from
> even looking at the package**.
>
> Therefore, if the package isn't ever downloaded by these older Perls, the
> 'use' statement can use the all-integer format without problem. In theory.
>
>  -john
>
> ---
> * In two or three years I'll be changing that to 5.16.1.
>
> ** People who deliberately override that restriction aren't part of this
> conversation.
>
> On Tue, April 16, 2019 2:59 pm, Dan Book wrote:
> > It depends entirely what Perls you want to support. If you only want to
> > support Perl 5.10 or newer, module versions in the dotted-decimal form
> are
> > fine as long as you always declare them as strings and don't use
> > underscores. If you want to support older than that, you have to jump
> > through some hoops or risk users getting the wrong behavior.
> >
> > For the 'use X' statement itself for declaring a minimum perl version of
> a
> > file, the '5.XXXYYY' format is still (always?) recommended, because it
> > will
> > make sure that running it on older Perls will result in a sensible error
> > message.
> >
> > -Dan
> >
> > On Tue, Apr 16, 2019 at 3:54 PM John M. Gamble 
> wrote:
> >
> >> On Mon, April 15, 2019 12:46 pm, David Cantrell wrote:
> >> > On Mon, Apr 15, 2019 at 12:04:24PM -0400, Dan Book wrote:
> >> >
> >> >> As a side note, remember that the X.Y.Z form of versions (with more
> >> than
> >> >> one decimal point) is a sequence of integers ...
> >> >
> >> > Sadly it's worse than that.
> >> >
> >> > There exists popular software management software out there written by
> >> > idiots who think that 3.0014 > 3.1, so that rule applies even when
> >> > you're using numbers in the form X.Y with a single decimal point.
> >> Those
> >> > people did a lot of hard work to break numeric comparisons, one of the
> >> > few things that computers are any good at.
> >>
> >> Are we at the point where there is no reason to not use X.Y.Z? I recall
> >> (I
> >> think) the historical reasons for using the 5.00y00z format, but given
> >> that minimum Perl versions are now specified in META.* files, surely
> >> there's no real reason to keep doing that anymore?
> >>
> >> I say this while looking at all my modules, which still use the fraction
> >> format.
> >>
> >>  -john
> >>
> >
>

Re: [RFC] File::TVShow::Parse

[Dan Book]

It depends entirely what Perls you want to support. If you only want to
support Perl 5.10 or newer, module versions in the dotted-decimal form are
fine as long as you always declare them as strings and don't use
underscores. If you want to support older than that, you have to jump
through some hoops or risk users getting the wrong behavior.

For the 'use X' statement itself for declaring a minimum perl version of a
file, the '5.XXXYYY' format is still (always?) recommended, because it will
make sure that running it on older Perls will result in a sensible error
message.

-Dan

On Tue, Apr 16, 2019 at 3:54 PM John M. Gamble  wrote:

> On Mon, April 15, 2019 12:46 pm, David Cantrell wrote:
> > On Mon, Apr 15, 2019 at 12:04:24PM -0400, Dan Book wrote:
> >
> >> As a side note, remember that the X.Y.Z form of versions (with more than
> >> one decimal point) is a sequence of integers ...
> >
> > Sadly it's worse than that.
> >
> > There exists popular software management software out there written by
> > idiots who think that 3.0014 > 3.1, so that rule applies even when
> > you're using numbers in the form X.Y with a single decimal point. Those
> > people did a lot of hard work to break numeric comparisons, one of the
> > few things that computers are any good at.
>
> Are we at the point where there is no reason to not use X.Y.Z? I recall (I
> think) the historical reasons for using the 5.00y00z format, but given
> that minimum Perl versions are now specified in META.* files, surely
> there's no real reason to keep doing that anymore?
>
> I say this while looking at all my modules, which still use the fraction
> format.
>
>  -john
>

Re: [RFC] File::TVShow::Parse

[Dan Book]

Best practice is to $VERSION all modules in your distribution, because then
other distributions can depend on a certain version of any module they are
using rather than only the main module. You can bump versions in modules
separately based on when each is updated, but generally it ends up being
simpler in the long run if you keep all versions the same, thus matching
the distribution version, and bump all of them each release. Authoring
tools like Dist::Zilla/Milla/Minilla can manage these versions for you (see
the Starter bundle's managed_versions option for Dist::Zilla), and
otherwise I wrote a tool that may be helpful:
https://metacpan.org/pod/perl-bump-version

As a side note, remember that the X.Y.Z form of versions (with more than
one decimal point) is a sequence of integers, thus leading zeroes in any
section are insignificant. Make sure not to accidentally use the X.Y form,
which in Perl is treated as a decimal number that isn't directly
compatible. Further reading:
http://blogs.perl.org/users/grinnz/2018/04/a-guide-to-versions-in-perl.html

-Dan

On Mon, Apr 15, 2019 at 9:35 AM Adam Spann  wrote:

> I have completed the majority of the code for this module. Renamed it
> File::TVShow::Info as well.
>
> There are still a few things to do. But its main function of
> extracting key identifying information is complete.
>
> I am including the current README from the pod documentation.
>
> One question however:
>
> 1) I have separted some data and arrays containing regex patterns into
> seperate files
> E.G File:TVShow::EpisodeName.pm
> Do I need to VERSION this pm file. The expectation would be that
> this file would be updated and this would then
>require a minor version update to the File::TVShow::Info Note that
> VERSION is 0.01.0.0 so if EpsiodeName is updated
>Info would become 0.01.0.1 and a minor update to Info would make
> the version 0.01.1.0 with a major code change resulting in 0.02.0.0
>
>
> I look forward to hearing some feedback.
>
> Kind Regards,
> Adam Spann
>
> NAME
>
> File::TVShow::Info - Perl meta data extractor from file name for TV
> Show file.
>
> VERSION
>
> Version 0.01.0.0
>
> SYNOPSIS
>
> This module is intended to identify and extract nformation in the file
> name of a TV show. These details can then be accessed by calling the
> relevant methods. It does NOT attempt to read the contents of the file.
>
> Note: This module will be modelled off
> https://metacpan.org/pod/Video::Filename created by Behan Webster, but
> will focus on TV Shows only and with additional features.
>
> If the file name is parsed and can not be identified as a TV show then
> "is_tv_show" will return 0.
>
> use File::TVShow::Info;
> my $show = File::TVShow::Info->new('file');
>
> Methods
>
>  new
>
> Create a Info object to extract meta information from the file name.
>
> my $show = File::TVShow::Info->new('file');
>
>   Object attributes.
>
> Attributes may be accessed through $show->{attribute_name} however
> methods do exist for all required operations.
>
>   * show_name: Name of the show.
>
>   * original_show_name: This will contain the show name found in the
>   file name without any modifications. This will only be defined if
>   _isolate_name_year has found a year string within the file name such
>   as name.2019, name.(2019), name 2018, name (2018)
>
>   * season: Show season
>
>   * episode: Show episode
>
>   * episode_name
>
>   * country
>
>   * endep: (Naming under consideration) last Episode number found when
>   file name contains SXXEXXEXX
>
>   * year, month, date: Show date e.g 2019.03.03 This can be accessed
>   using the method "ymd" Note: year will be defined in two cases. One:
>   show name contains year. show_name. or Two: File name contains
>   .MM.DD that are identified by date. These are mutually exclusive
>   and no conflict is expected.
>
>   * source
>
>   * resolution: Show resolution 480p/720p and so on. This will be '' if
>   not found.
>
>   * release_group
>
>   * is_subtitle
>
>   * subtitle_lang
>
>   * ext: File extension
>
>  show_name
>
> Return the show name found in the file name.
>
>  strip_show_name
>
> Return show_name after removing string delimiters
>
>  original_show_name
>
> Return the original show name.
>
> This method will return the orginal show name if original_show_name is
> defined. This will be defined if show_name contains a year string
> () or 
>
> If not defined it will return {show_name}
>
>  season
>
> Return the season found in the file name. Return '' if {season} is not
> defined.
>
>  season_to_int
>
> Return season as an integer
>
>  episode
>
> Return the episode found in the file name. Return '' if {episode} is
> not defined.
>
>  episode_to_int
>
> Return episode as an integer
>
>  

Re: [naming] To pragma or not to pragma?

[Dan Book]

On Sat, Mar 2, 2019 at 1:01 AM Konstantin S. Uvarin 
wrote:

> Hello,
>
>   I'd like to release a module that lazy-loads other modules to reduce
> startup time.
>
>   My initial idea was `lazy` but that was taken, so I switched to
> `on::demand`. There's also `autouse` with similar functionality.
>
>   However, on second thought I'm not even sure if a lowercase name fits in
> here. It's certainly not as effectful as `namespace::clean` or `strict`.
>
>   So the question is, what are the guidelines for deeming a module to be
> worth called a pragma?
>
>
Strictly speaking, a pragma is usually supposed to affect the lexical scope
it's imported to, rather than the package. "lib" has precedent of doing
neither and instead affecting global state, which is more similar to your
idea. I would say use whichever looks better to you.

-Dan

Re: Perl 5.26 and the . in INC issue where modules won't install

[Dan Book]

See https://github.com/miyagawa/cpanminus/pull/579 for my attempt at
documenting this behavior. Carton 1.0.34 is the latest version.

-Dan

On Thu, Nov 1, 2018 at 8:51 PM Karen Etheridge  wrote:

> The 'dist' option is documented in Module::CPANfile, but the 'url' option
> can only be found in the t/options.t test in the distribution -- so it must
> be implemented at least partially, somehow.  Maybe miyagawa can comment?
>
> On Thu, Nov 1, 2018 at 4:39 PM, Alex Muntada  wrote:
>
>> Hi Karen,
>>
>> > You can also install locally patched modules with carton by
>> > specifying a 'file:///' path in cpanfile:
>> >
>> > requires 'Foo::Bar', '0.123', url =>
>> > 'file:///local/path/Foo-Bar-0.123.tar.gz';
>>
>> I tried this with latest Carton (v1.0.28) and it didn't work.
>> Since I couldn't find any reference to an url attribute in
>> Module::CPANfile, I'm wondering whether I'm missing something
>> because this looks like a very nice feature.
>>
>> Can you provide some details or pointers on how it works?
>>
>> Thanks!
>> Alex
>>
>>
>

Re: Perl 5.26 and the . in INC issue where modules won't install

[Dan Book]

You can always fork the module but then it requires the other modules to
use that fork instead. Another alternative is Alt:: (
http://metacpan.org/pod/Alt) but that's opt-in for the user and messy, and
may not work out with Carton. Getting the author to pass you maintainership
or adopting the module if the maintainers haven't responded after a few
weeks (after trying listed emails, bug reports) is the simplest way to get
the dist fixed.

-Dan

On Thu, Nov 1, 2018 at 11:37 AM Martin J. Evans 
wrote:

> Hi Module Authors,
>
> Increasingly I am having problems with modules in Perl 5.26 and later
> which won't install because of the . not in @INC issue. Quite often it is
> not even the module I want to use but a requirement
>
> e.g., Cache::Memory requires File::NFSLock and File::NFSLock won't install
> on 5.26 because of @INC change.
>
> In the case of File::NFSLock, a patch was submitted back in Feb 2017 (
> https://rt.cpan.org/Public/Bug/Display.html?id=120088) but it has still
> not been applied. Other than ask to take over maintainership of
> File::NFSLock (and a number of other modules with the same problem) what
> can I do to get this fixed? Is there a way for a non maintainer to apply
> the patch and release a new version?
>
> The extra reason this is a pain is we are using Carton and so I believe to
> supply a hand crafted fixed module I'd have to have a web server somewhere,
> where I could place the patched module.
>
> Thanks
>
> Martin
>

Re: executable only Perl distributions & CPAN

[Dan Book]

(duplicate reply because first one didn't go to the list)

On Fri, Sep 7, 2018 at 4:01 PM Diab Jerius  wrote:

> Howdy,
>
> My apologies if this topic has been covered elsewhere; I've been
> unable to concoct a search which would efficiently find it.
>
> I've authored a distribution which contains a single executable and no
> supporting modules. After injecting the tarball into my local darkpan
> via orepan2-inject, cpanm is unable to find it.
>
> I believe the problem is that as there are no packages, the "provides"
> field in META.yml is empty, and as 02packages.detail.txt lists only
> packages, it won't show up there.
>
> I see two options:
>
> 1.  Create an empty package which gets indexed; or
> 2.  Add an entry to the "provides" field mapping the distribution's
> "package" name (App::pltvectors) to the script file.
>
> Unfortunately, if a tool uses the "provides" field to verify that the
> listed package is in the script file it will fail, so this approach
> may lead to breakage.
>
> Is there a third option which doesn't require creating the empty file?
>
>
> Thanks,
>
> Diab
>
> P.S. I'm interested not just for my package, but also one of my
> old-time favorites on CPAN, makepatch, which isn't indexed on metacpan
> because of this (see
> https://github.com/metacpan/metacpan-web/issues/601) and thus isn't
> installable by CPAN clients, or indeed discoverable by metacpan, which
> is a shame.
>

CPAN distributions must contain a valid package, matching the filename,
which you have permissions for, with a higher version declared than
existing uploads of that module, in order to be indexed. Scripts are not
indexed by PAUSE, they aren't modules. So it should contain a file lib/App/
pltvectors.pm that contains package App::pltvectors and our $VERSION =
'...'. This ensures 1. that module name will be indexed, 2. it will be
installable by cpanm via that module name, 3. it will be able to satisfy
CPAN dependencies on that module name, 4. the module name is possible to
'use' (though this may not matter for such a distribution). If it's not for
CPAN but just for local installation then putting the info you suggest in
the 'provides' metadata should be enough, but it depends on how orepan
emulates the PAUSE indexer.

-Dan

Re: [RANT] Should we try to keep compatibility with old perl5s?

[Dan Book]

On Sat, Aug 11, 2018 at 4:39 PM Shlomi Fish  wrote:

> Hi all!
>
> This post is a little flamebait, so please try to keep the discussion
> civil.
>
> Anyway, after reading the discussion in this public github issue, and
> following
> some of the links (especially
>
> https://szabgab.com/what-does--if-it-aint-broke-dont-fix-it--really-mean.html
> ),
> do you think I was being unreasonable, or should I as a CPAN
> author/maintainer/adopter accommodate for people running old perl5s, in my
> case
> 5.10.x and below:
>
> https://github.com/shlomif/perl-XML-SemanticDiff/issues/3
>
> This reminds me of what chromatic wrote here -
> https://www.nntp.perl.org/group/perl.perl5.porters/2008/09/msg140206.html
> :
>
> «
> This is why we can't have nice things.
> »
>
> Any comments or opinions? I think I'll relax by watching a nice and fun
> video.
>
>
Here is my take on the issue.

1. There is a general expectation that old but supported (by toolchain)
Perls will continue to work, but perhaps not be able to use new features.
This is just the legacy of Perl.

2. As a CPAN author you have no obligation to support anything you don't
want to. Users have the ability to fork your module or use a different one
if they need to.

3. It's generally polite to your users to declare and support a minimum
Perl version that is consistent with what Perl features you are using, and
that is simple for you to test on to ensure continued support (e.g. via
Travis CI or cpantesters, if not your own system).

With all of that combined, my personal policy for CPAN modules that I
expect others to use is to support back to 5.8 unless it is in an ecosystem
that already requires a newer version (like a Mojolicious module requires
5.10, a Dist::Zilla module requires 5.14). But that is just because that is
the minimum version which is supported by toolchain and convenient for me
to test through Travis CI. Your support policy can be whatever you want it
to be, but be aware how people will decide to go about using or not using
your module as a result.

-Dan

Re: Is it ok taking the Refute::* namespace?

[Dan Book]

On Wed, Sep 6, 2017 at 7:24 AM, Konstantin S. Uvarin 
wrote:
>
>   Now to the subject. Would it be fine to take up a whole top-level
> namespace, or should I stick to a humbler naming scheme like
> Assert::Refute? If I do take a namespace, what should I do aside from being
> concerned and posting here?
>

It's unlikely to be a problem to take that namespace (and there's no
additional action you need to take, unless someone already owns it) but
Assert::Refute sounds more descriptive of your goal to me.
-Dan

Re: Module naming -- processing 3D JPEG files...

[Dan Book]

>
> Some would consider the following to be even more general and
> thus better:
>
>Image::3D::Pairs::MPO
>Image::3D::Pairs::JPS
>Image::3D::Pairs::JPG
>
>Image::3D::Lenticular
>Image::3D::VR
>Image::3D::Holo
>Image::3D::DepthMap
>
> But wouldn't this break the rule for an uppercase letter as the
> first character?


A number as the first character of a subnamespace is fine, as long as it is
not the first character of the whole package name.

-Dan

Re: Network Device API - Package Names

[Dan Book]

I recommend using Device:: as your top-level namespace, as it's already
widely used for hardware interface libraries. You can make it more granular
under that if you wish.

On Wed, Nov 16, 2016 at 7:45 PM, Greg Foletta  wrote:

> Hello,
>
> I'm currently writing modules to interact with the APIs of network
> devices. These include the NXAPI of Cisco Nexus switches, and the API of
> Palo Alto firewalls.
>
> I'm looking for suggestions as to where to place these within the package
> space?
>
> My first consideration has been for the top level to be the device type:
> Firewall::PaloAlto
> Switch::NXAPI
>
> What are other people's thoughts?
>
> Greg Foletta
> g...@foletta.org
>
>

Re: Please provide me with COMAINT on https://metacpan.org/pod/Dist::Zilla::Plugin::VersionFromModule

[Dan Book]

On Fri, Nov 11, 2016 at 5:03 AM, Shlomi Fish  wrote:
>
>
> Thanks for the tip, Karen! [RewriteVersion] seems nice and I started the
> switch
> to it. Now the "install_deps" stage of my CI-testing script succeeds but
> not
> I'm getting a failure in the test stage:
>
> https://travis-ci.org/thewml/latemp/builds/175020627
>
> Oh well - progress!
>
> Regards,
>
> Shlomi Fish


Your earlier 'cpanm' commands are being run with sudo, but when it ends up
running this command to install the dzil authordeps, cpanm is not run with
sudo and you can see the warning that it gives.

https://github.com/thewml/latemp/blob/master/CI-testing/continuous-integration-testing.pl#L38

-Dan

Re: Declaring optional dependencies

[Dan Book]

On Wed, Nov 9, 2016 at 9:49 AM, Timothe Litt  wrote:
>
> cpan and cpanm seem to handle 'recommended' differently.  IIRC, neither
> defaults to installing 'recommended' modules.
>

Sadly, this is correct and in fact (as far as I know) CPAN.pm still handles
recommended prereqs completely wrongly if you do enable them (fails the
installation if they don't install). cpanm handles them more correctly but
still not ideally. The fact they are not installed by default, in turn,
makes them not any more useful than 'suggests' in practicality, so it ends
up being a semantic difference. 'recommends' should be modules which are
always a good idea to install but not required, and 'suggests' should be
modules which the user may consider installing if they choose.

This leads to the case as you noted with JSON::MaybeXS, where the only
practical solution in the current state of things is to instead rely on
dynamic dependencies, and add a hard dependency on the modules that are
appropriate at installation time. Dynamic dependencies however are a very
widely supported and backwards compatible system. Only configure-time
dependencies are read from the static META.json, the rest are read from the
generated MYMETA.json, generally even if dynamic_config is set to 0, though
in that case it is imperative that the generated prereqs match the static
ones.

Re: PDLx::Mask - search.cpan.org uses README.pod instead of lib/PDLx/Mask.pm

[Dan Book]

All .pod files are likely to be indexed by both search engines regardless
of their location. Metacpan indexes it according to the NAME section but it
doesn't seem to take precedence over the pod in the module of the same name
in your case. Either way you should not include .pod files that are not
namespaced with your modules.
-Dan

On Fri, Oct 28, 2016 at 12:17 PM, Diab Jerius <djer...@cfa.harvard.edu>
wrote:

> On Wed, Oct 26, 2016 at 6:52 PM, Dan Book <gri...@gmail.com> wrote:
> > On Wed, Oct 26, 2016 at 6:14 PM, Diab Jerius <djer...@cfa.harvard.edu>
> > wrote:
> >>
> >> Howdy,
> >>
> >> The PDLx-Mask distribution has a README.pod file at the top level, as
> >> well as actual module documentation in lib/PDLx/Mask.pm.
> >>
> >> On the module's main page:
> >>
> >>   http://search.cpan.org/~djerius/PDLx-Mask-0.01/
> >>
> >> The PDLx::Mask link goes to README.pod, not to lib/PDLx/Mask.pm
> >>
> >> That's not quite what I expected, while this
> >>
> >>   https://metacpan.org/pod/PDLx::Mask
> >>
> >> is.
> >>
> >> Should I not be uploading the README.pod file? I use that to
> >> generate README and README.md.
> >>
> >> Thanks,
> >>
> >> Diab
> >
> >
> > You should not upload any .pod files in the top level of the
> distribution,
> > as they will get indexed and installed for historical reasons. (Metacpan
> > sees the name in that document as PDLx::Mask, so it does not override the
> > indexed PDLx::Mask documentation in their index. Search.cpan.org
> clearly has
> > different logic we are not privy to.) README.md and README are fine.
> >
> > -Dan
>
> search.cpan.org is dogged!  moving README.pod to docs/README.pod did
> not camouflage its prey.
>
> I'll rename README.pod and see if that helps...
>

Re: PDLx::Mask - search.cpan.org uses README.pod instead of lib/PDLx/Mask.pm

[Dan Book]

On Wed, Oct 26, 2016 at 6:14 PM, Diab Jerius 
wrote:

> Howdy,
>
> The PDLx-Mask distribution has a README.pod file at the top level, as
> well as actual module documentation in lib/PDLx/Mask.pm.
>
> On the module's main page:
>
>   http://search.cpan.org/~djerius/PDLx-Mask-0.01/
>
> The PDLx::Mask link goes to README.pod, not to lib/PDLx/Mask.pm
>
> That's not quite what I expected, while this
>
>   https://metacpan.org/pod/PDLx::Mask
>
> is.
>
> Should I not be uploading the README.pod file? I use that to
> generate README and README.md.
>
> Thanks,
>
> Diab
>

You should not upload any .pod files in the top level of the distribution,
as they will get indexed and installed for historical reasons. (Metacpan
sees the name in that document as PDLx::Mask, so it does not override the
indexed PDLx::Mask documentation in their index. Search.cpan.org clearly
has different logic we are not privy to.) README.md and README are fine.

-Dan

Re: Sanity checking for namespace and other abuses

[Dan Book]

On Wed, Oct 26, 2016 at 12:01 PM, David Mertens 
wrote:

> @everybody,
>
> Does anybody oppose me adding to code to top-level, lower-cased packages
> "int", "num", and "str"? What about top-level packages "Int", "UInt",
> "Str", or "Num"? Do other type systems use these top-level packages?
>

My opinion is to avoid it if possible. For similar work, see Type::Tiny,
which uses exported subs for that sort of type name.
https://metacpan.org/pod/Type::Tiny

-Dan

Re: Where to report bugs in website 'search.cpan.org' ?

[Dan Book]

On Wed, Sep 7, 2016 at 11:56 PM, Linda A. Walsh  wrote:

>
> Moving this question to module-authors as per David G.'s feedback.
>
> I was looking for available mail-filtering, aka Milter, mods, and
> came across Mail-Milter.
>
> I noticed it has 1 review rating it a single *.  and it wanted to
> know if the review was helpful -- and it wasn't --
> as it doesn't say *what* version the review was about.
>
> The reviews seem to be generally "worthless", if they don't
> tell me which version is being reviewed.  A comment about a module
> from V0.0.1 isn't very useful for a module at version 2.3.7 (as a
> randomly chosen example).
>
> This brings up a few requests/ideas for improvement:
>
> 1) Could the version number a review refers to be included?
>
> For comments already posted, either, mark them as too old to
> to have included the reviewed version, OR, *IF* the date
> of the review is known (it probably should be included in the
> review anyway), then match it to the highest version before
> the review was added.
>
> 2) There should be a way of "closing out" reviews that would have
> really been better placed as bugs or RFE's, that have been addressed
> (i.e. bug-fixed, or feature-added, etc...).
>
> As it stands now, reviews don't say anything about current versions
> and for "bug-fix" reviews, there's no way to indicate the bug was
> fixed and the review doesn't apply to a more current version.  There
> is also no way to respond to a review to mention that anything has changed
> or been fixed.  Any response ends up as another, _unconnected_ comment --
> not very useful.
>
> Thoughts?  Ideas/feedback?
> Thanks...
>
>
>
>
(Resending as it didn't go to the list)

These issues are mostly regarding the cpanratings site itself, which is not
part of search.cpan.org. You can find its issue tracker here:
https://github.com/perlorg/perlweb/issues

And you might also find this discussion interesting, regarding similar
links from metacpan.org: https://github.com/metacpan/metacpan-web/
issues/1653