Re: Enabling all MY methods of the same name in multiple modules

[Leon Timmermans]

On Fri, Jul 16, 2021 at 8:57 AM David Christensen 
wrote:

> module-authors:
>
> I have extended EUMM in a Perl distribution by implementing a module
> that overrides various methods in the "MY" package namespace and by
> using that MY override module in Makefile.PL, per "Overriding MakeMaker
> Methods" in:
>
>  https://metacpan.org/pod/ExtUtils::MakeMaker
>
>
> I would like to split the single distribution into multiple
> distributions.  Multiple distributions will have a MY override module.
> A given MY method may be implemented in multiple modules.  A given
> Makefile.PL may 'use' one or more modules.  Method name collisions are
> expected.  I will architect the distributions to avoid circular
> dependencies.
>
>
> AIUI simply use'ing modules with the same package namespace and the same
> subroutine (method) names will result in later definitions redefining
> earlier definitions, generating compiler warnings and making the earlier
> definitions inaccessible.
>
>
> Is there a mechanism to daisy-chain multiple package::subroutine
> definitions such that a MY method call by EUMM will return the
> concatenated results of all definitions?
>
>
> David
>

In general, I don't think it's a good idea for any module to add methods to
MY:: directly (or at least not by default), exactly for that reason. MY
should only live in Makefile.PL. For methods without side-effects on $self,
combining them is could be done like this:

 my @extensions = (...);
 load($_) for @extensions;
 my @methods = map { $_. "::postamble" } @extensions;
 sub MY::postamble {
   my ($self, %args) = @_;
   return join "\n\n", map { $self->$_(%args) } @methods;
 }

Another alternative is to insert yourself in the inheritance tree between
MY:: and whatever happens to be its base-class ($MY::ISA[0]), so you can
chain them. This may work better with side-effects.

Leon

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

[Leon Timmermans]

On Sat, Jan 25, 2020 at 3:39 AM James E Keenan  wrote:
> I managed to get an Appveyor configuration, but the build stopped when
> it couldn't locate a prereq needed only on Windows.  I decided to defer
> all work on Windows (which I don't have access to) until a later date.
>
> > 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)?
> >
>
> I decided to KISS.  I called 'dzil test' and 'dzil build' then manually
> uploaded the resulting tarball to CPAN in the same way I've done since 2002.

Some actions only happen upon release, typically updating the Changes
file to include the current version, tagging the version in git, and
setting the trial status if needed. I do indeed see you're manually
fixing these things up in the repository. You really should be using
«dzil release» instead.


Leon

Re: Perl Modules in GitHub

[Leon Timmermans]

On Tue, Mar 29, 2016 at 5:21 AM, Jerry D. Hedden  wrote:

> I maintain server Perl modules on CPAN:
> http://search.cpan.org/~jdhedden/  Some of the modules are part of the
> core Perl distribution; some are my own.  I want to add them to GitHub.  Is
> there preferred organization, account, methodology for doing this?  I would
> think there is a better way than just putting them under my own GitHub
> account, particularly as this would complicate matters if the time should
> come when someone else would need to take over their maintenance.
>

AFAIK the perl group is not meant as a community development platform (most
obviously perl/perl is only a mirror), but more as communication to the
outside world The Perl Toolchain gang is quite functional at what it's
trying to do, but I don't think think that enlarging that umbrella is a
good idea organizationally. I do think it may be a good idea to have an
organization for non-toolchain dual-life modules (in fact, I just took the
liberty of creating exactly such an organization).

Leon

Re: Is META.yml Necessary Anymore?

[Leon Timmermans]

On Mon, Oct 26, 2015 at 5:26 PM, David Cantrell 
wrote:

> On Sun, Oct 25, 2015 at 10:16:02AM -0400, Shawn H Corey wrote:
>
> > If it's not a requirement, then people are going to get sloppy with it,
> > meaning sometimes it will break other people's code.
>
> Supporting everything for ever is a recipe for Pain. I'd be happy for it
> to be officially deprecated, for authors to be notified, for tools to
> later start warning that it exists, and for support to be removed in a
> few years.


For reasons Aristotle mentioned, we can't fully deprecate it until 5.14 is
the minimum supported perl (even if we can omit it in many cases today).
The toolchain gang just increased it's own absolute minimum from 5.6 to 5.8
in 2013 (and there are still a few advocates for the former). What you're
suggesting is probably going to happen around the time RHEL 6 is EOLed.

You have no idea how happy I'd be to share a $beverage with you when that
happens somewhere around 2024.

Leon

Re: Is META.yml Necessary Anymore?

[Leon Timmermans]

On Sun, Oct 25, 2015 at 12:26 PM, Dominique Dumont <domi.dum...@free.fr>
wrote:

> Le samedi 10 octobre 2015, 15:45:38 15:45:38 Leon Timmermans a écrit :
> > Also I think some packagers may be using it.
>
> Debian uses the information from META to create and refresh Perl package in
> Debian format.
>
> More specifically, the tool used to create and refresh package
> (dh-make-perl
> [1]) needs META.yml to work.
>
> So, please, do not remove META.
>
> All the best
>

As far as I can tell, dh-make-perl is already using CPAN::Meta, and
preferring META.json over META.yml as it should
(DhMakePerl::Command::Packaging::process_meta), I don't think there' a
problem there.

Leon

Re: Is META.yml Necessary Anymore?

[Leon Timmermans]

On Fri, Oct 9, 2015 at 8:50 AM, Aristotle Pagaltzis 
wrote:

> Hi John,
>
> * John M Gamble  [2015-10-06 20:25]:
> > What with META.json being generated (and presumably used) in our CPAN
> > uploads, is it necessary to include META.yml anymore? A brief search
> > didn't really tell me anything.
> >
> > If it makes a difference, the minimum version of Perl that I require
> > for my modules is currently 5.10.1.
>
> if I’m looking at this right, Perl 5.13.10 is the earliest Perl version
> where the toolchain supports META.json out of the box.
>
> Specifically, 5.13.9 was the first perl to ship JSON::PP in core, but
> its CPAN.pm and Parse::CPAN::Meta lack META.json support. They were
> added in Parse::CPAN::Meta 1.41_01 and CPAN.pm 1.94_65, both of which
> were included in 5.13.10 (or rather, Parse::CPAN::Meta was upgraded to
> 1.44).
>
> In practice that means Perl 5.14.0 is the first Perl that can install
> dists with a JSON-only META out of the box.
>
META was never something relevant for installation purposes except
configure_requires (and dynamic_config, theoretically), it's MYMETA that
matters more. When using EUMM often you can easily live without META.yml,
but figuring out when you need it and when not is a hassle, and actually
declaring a minimum EUMM version (even if it's an ancient one) is generally
considered good practice. Also I think some packagers may be using it.
Leon

Re: autodie was not installed on http://www.cpantesters.org/cpan/report/6109ee1e-63a7-11e5-80f8-24112cde3c15

[Leon Timmermans]

On Sat, Sep 26, 2015 at 12:48 PM, Shlomi Fish <shlo...@shlomifish.org>
wrote:

> Hi, Leon!
>
> On Sat, 26 Sep 2015 12:28:20 +0200
> Leon Timmermans <faw...@gmail.com> wrote:
>
> > On Sat, Sep 26, 2015 at 10:33 AM, Shlomi Fish <shlo...@shlomifish.org>
> > wrote:
> >
> > > On
> > >
> http://www.cpantesters.org/cpan/report/6109ee1e-63a7-11e5-80f8-24112cde3c15
> > > - there's a missing "autodie" despite the fact that it properly
> appears in
> > > the
> > > test_requires in Build.PL and in build_requires in the META.yml. Please
> > > investigate why it is happening.
> > >
> >
> > Proper test_requires support in MB requires MB 0.4200
> >
>
> Well https://metacpan.org/source/SHLOMIF/App-Timestamper-0.0.5/Build.PL
> seems to contain the right code to fallback to build_requires (see line
> #63),
> however with a check for version 0.4004 instead. Should it be 0.4200 ? Is
> it a
> bug in Dist::Zilla? The latest version of dzil was used.
>

I had missed that. In theory it should be fine, though I remember there
were a few edge-cases (I forgot the details) that would make me recommend
0.4200 instead. I think I figured out what the problem is though:

I suspect the version of CPAN.pm is too old to understand META.yml, and the
_build/prereqs contains only test_requires (not build_requires), so it all
falls on its face. Possibly this is something MB should take into account.


> > > I also noticed that the test was done with perl-5.6.2 - is there still
> a
> > > case
> > > for testing with such an ancient version of perl?
> > >
> >
> > Yes there is.
>
> Until when are we going to do so? And why?
>

As long as people feel the need to; because they feel the need to. I'm not
sure what the disadvantage is to you, if you really mind the messages you
can simple disable CPAN Testers reports for 5.6 or declare in advance it
wouldn't work.

Leon

Re: Curating old dists on CPAN

[Leon Timmermans]

On Fri, May 1, 2015 at 12:10 AM, Neil Bowers neil.bow...@cogendo.com
wrote:

 I think we should either remove very old dists from CPAN, or update them
 to follow modern conventions (so they have a META.yml or META.json, for
 example). I had email with the author of CGI::Response (last released in
 1995) for example, and he agreed that it should be removed from CPAN.

 I had a look at all the dists that were last released in 1995 and wrote up
 my thoughts on them:

 http://neilb.org/2015/04/30/curating-old-releases.html

 Where people think dists shouldn’t be removed, I’m happy to try adopt them
 to release minimal updates, where I’m able to.

 I’m interested to hear what others think.


Unless it's actively standing in the way (e.g. dysfunctional yet first hit
on a realistic search query), I do not see any benefit to doing this.

Leon

Re: =head1 SEEN ALSO BY

[Leon Timmermans]

On Tue, Mar 31, 2015 at 6:29 PM, Paul LeoNerd Evans 
leon...@leonerd.org.uk wrote:

 Random musings from #perl on Freenode:

 If I write a base module that's intended for expansion/extension (such
 as Tickit), and then write lots and lots of extensions (see: the entire
 Tickit::Widget:: namespace), it would be nice as an end-user feature
 browsing module documentation, to be able to see a list of all those
 widgets when looking at the base. Sometimes module developers use a

   =head1 SEE ALSO

 However, for developers that's a terrible solution. It means the author
 of the base has to list all the extensions, which will naturally grow
 over time. As the base becomes more stable, it increasingly means the
 base does documentation-only releases that just add to that list.
 Also it's hard for third-parties to add it there.

 I wonder if therefore, metacpan needs some sort of back-reference
 ability? That if an extension module could somehow list

   =head1 SEEN ALSO BY

   LTickit

 then such a module declaring that would *automatically* get listed
 somehow in some automatically-generated and (near)-realtime updated
 part of the Tickit documentation when viewed via metacpan.

 Does this sound like something that might gain traction?


AFAIK there are ways to sneak in a piece of HTML into the POD, so I guess
you could XSS yourself ;-)

Leon

Re: Test failing on Windows but not elsewhere

[Leon Timmermans]

On Mon, Mar 9, 2015 at 11:44 PM, James E Keenan jk...@verizon.net wrote:

 This weekend I gave my CPAN library CPAN-Mini-Visit-Simple an overhaul, a
 large part of which was guaranteeing that CPAN Testers handled the absence
 of a minicpan gracefully.  As a result, for the first time I'm getting lots
 of green on my results matrix (http://matrix.cpantesters.
 org/?dist=CPAN-Mini-Visit-Simple).

 Except on Windows.  See, e.g., http://www.cpantesters.org/
 cpan/report/88cc1179-8782-1014-9710-f1002b825c07, where this failure is
 reported:

 #
 C:\strawberry\perl\bin\perl.exe -MExtUtils::Command::MM
 -MTest::Harness -e undef *Test::Harness::Switches; test_harness(0,
 'blib\lib', 'blib\arch') t/*.t

 #   Failed test 'Got expected error message for malformed minicpan
 repository'
 #   at t/001_new.t line 78.
 #   'Absence of C:\Users\SOLIMA~1\AppData\
 Local\Temp\FLXGKPwo7N\authors\id implies no valid minicpan at t/001_new.t
 line 74.
 # '
 # doesn't match '(?^:Absence of C:\Users\SOLIMA~1\AppData\
 Local\Temp\FLXGKPwo7N\authors\id implies no valid minicpan)'
 # Looks like you failed 1 test of 16.
 t/001_new.t ...
 Dubious, test returned 1 (wstat 256, 0x100)
 #

 Here's the relevant source code:

 #
 my $id_dir = File::Spec-catdir($data{minicpan}, qw/authors id/);
 croak Absence of $id_dir implies no valid minicpan
 unless -d $id_dir;
 $data{id_dir} = $id_dir;
 #

 And here's the relevant testing code:

 #
 {
 my ($tdir, $id_dir, $self);
 $tdir = tempdir();
 $id_dir = File::Spec-catdir($tdir, qw/authors id/);
 eval {
 $self = CPAN::Mini::Visit::Simple-new({
 minicpan = $tdir,
 });
 };
 like($@, qr/Absence of $id_dir implies no valid minicpan/,
 Got expected error message for malformed minicpan repository );
 }
 #

 Note that in both cases I compose directories by File::Spec-catdir(). My
 understanding is that this should handle the Windows path separators
 issue.  So having Done The Right Thing in that respect, I can't figure out
 why I'm getting this failure.

 Suggestions?


I would guess a quotemeta (for example in the form of \Q$id_dir\E) will fix
your problem.

Leon

Re: How avert warning re MYMETA.* ?

[Leon Timmermans]

On Sat, Feb 14, 2015 at 1:17 AM, James E Keenan jk...@verizon.net wrote:

 When I am working on an update to a CPAN distribution, I say make clean,
 then create the Makefile in the customary way -- but I get a warning about
 files missing from my kit.

 #
 $ perl Makefile.PL
 Checking if your kit is complete...
 Warning: the following files are missing in your kit:
 MYMETA.json
 MYMETA.yml
 Please inform the author.
 Generating a Unix-style Makefile
 Writing Makefile for List::Compare
 Writing MYMETA.yml and MYMETA.json
 #

 MYMETA.yml and MYMETA.json are then written.

 I list MYMETA.yml and MYMETA.json in the distribution's MANIFEST, so they
 are included in the tarball which gets uploaded to CPAN.  I don't
 customarily put either MYMETA.* under version control (in this case, git).

 What is the significance of the warning?  Should I take any steps to avert
 it?


MYMETA *must not* be listed in the MANIFEST (and neither is it sensible to
put it under version control).

This sounds like the dist is not having MYMETA in its MANIFEST.SKIP file,
adding it there should solve this problem.

Leon

Re: name for a Module to build XS with Visual C on a core Mingw GCCPerl

[Leon Timmermans]

On Fri, Jan 9, 2015 at 1:11 PM, bulk88 bul...@hotmail.com wrote:

 Module::Build tests for and forbids overriding Config (related report
 http://perlmonks.org/?node_id=987651 ),


Module::Build probably has better support for overriding Config than
MakeMaker, it's just opinionated on how you should do that.


 so that means VCConfig will have install itself as site/lib/Config.pm and
 use an ENV var to control VC vs GCC.


That seems like a more sensible approach to start with to me.

Leon

Re: Best way to communicate changing the output of a module

[Leon Timmermans]

On Mon, Dec 23, 2013 at 12:48 PM, Shmuel Fomberg shmuelfomb...@gmail.comwrote:

 Hi Stephen.

 On Fri, Dec 20, 2013 at 2:32 AM, Stephen Patterson wrote:


 I'm the maintainer of Finance::Bank::CooperativeUKPersonal, a module for
 downloading UK bank statements. Part of the output from this module is a
 statement date in dd/mm/ (UK) format. As I've started using the module,
 I'm considering changing this to ISO-SQL standard - -mm-dd. What's the
 best way of communicating this change  managing things during changeover?


 Is changing the interface really worth it?
 If you already have users, they won't appreciate the cleanness of the new
 interface. they just want their code to work.
 So while I understand that you want to fix past mistakes, unless they are
 major and doing real harm, just leave them be.

 don't worry, next module you will be wiser and make other mistakes. :-)


Some 35 years ago, the authors of make didn't want to change the tabs based
syntax of makefile because they already had a few dozen users, we're still
suffering for it. It shouldn't be done lightly, or often, but sometimes it
is for the better.

In this particular case, I'm wondering if a date_format argument taking a
strftime/strptime string wouldn't make more sense. Why not have the user
choose what it wants. Also, it may be a good idea if it stays consistent
with the memorableDate argument.

Leon

Re: Unclear as to problem: Tried to register 'Types', but says can't due to unrelated module.

[Leon Timmermans]

On Wed, Nov 13, 2013 at 4:43 PM, Linda W perl-didd...@tlinx.org wrote:

 On 2013-11-13 07:30, David Cantrell wrote:

   Ah-- NetIcal1.11 doesn't have it.. but if I try


 Types by itself, it downloads Netical 1.15

 The indexing system is broken, IMO...

 I see Types:
 cp lib/Net/ICal/Parser.pm blib/lib/Net/ICal/Parser.pm
 cp lib/Net/ICal/Makefile blib/lib/Net/ICal/Makefile
 cp lib/Net/ICal/Component.pm blib/lib/Net/ICal/Component.pm
 cp lib/Net/ICal.pm blib/lib/Net/ICal.pm
 cp Net__ICal.pm blib/lib/Net/Net__ICal.pm
 cp lib/Net/ICal/Store.pm blib/lib/Net/ICal/Store.pm
 cp lib/Net/ICal/Cluster.pm blib/lib/Net/ICal/Cluster.pm
 cp lib/Net/ICal/Types.pm blib/lib/Net/ICal/Types.pm
 cp lib/Net/ICal/Parameter.pm blib/lib/Net/ICal/Parameter.pm
 cp lib/Net/ICal/Property.pm blib/lib/Net/ICal/Property.pm
 cp lib/Net/ICal/Value.pm blib/lib/Net/ICal/Value.pm
 cp lib/Net/ICal/Calendar.pm blib/lib/Net/ICal/Calendar.pm
 netical_wrap.c: In function ‘SWIG_GetPtr’:
 
 Under Net::ICal/Types.

 But not at the top level.

 Presumably he owns Store, Cluster Parameter Property Value and Calendar?

 I dont' recall seeing them indexed...

 It was the same with Inline -- It wasn't a top level module, but a
 Math::Simple
 down a dir level...

 So what's up with that?   Why isn't it indexed as Net::ICal::Types?

 Something seems odd here... The 'owner' of Inline had no idea it indexed
 Math::Simple -- as it wasn't a top level module... So What's the scoop?

 For a module that has Perl's basic data types, and that's all where would
 you
 put it?


Net-ICall 0.11 has a package Types in lib/Net/ICal/Types.pm. This was
probably a mistake.

Leon

Re: Problem brewing w/tar?

[Leon Timmermans]

On Mon, Nov 11, 2013 at 11:58 PM, Linda A. Walsh perl-didd...@tlinx.orgwrote:

 Too bad Archive::Tar isn't up-to-date with a 10+year old standard.


http://xkcd.com/927/

Leon

Re: How to specify a pre-req?

[Leon Timmermans]

On Thu, Nov 7, 2013 at 9:49 PM, Linda W perl-didd...@tlinx.org wrote:

 I am trying to specify a pre-req that needs to be present for
 my module to work.

 I have it under the PREREQ_PM section next in my Makefile.PL
 as well as under the BUILD_REQUIRES section.

 I'm not sure I specified the version correctly -- I note that
 Test::Simple, has a floating point version, while mine has
 a string '0.3.2'.


You should specify such versions as 'v0.3.2'. Without the v the
vstring/version object logic doesn't kick in.


 Yet the reports for the new version have nothing like that
 at the top...

 So I'm stumped...  Why don't the pre-req's in the Makefile.PL
 pull down the needed modules and how can the test continue
 to run when it should have died up front?


Also, ExtUtils::MakeMaker only supports this properly since 6.70, so you'd
need a configure dependency on that too :-(

Leon

Re: Name for an A/B testing module?

[Leon Timmermans]

On Sun, Sep 29, 2013 at 10:44 AM, Ovid publiustemp-moduleautho...@yahoo.com
 wrote:

 I've written an A/B testing module for Perl, but I suspect the name
 Test::AB will annoy people since people expect modules in the Test::
 namespace to be about traditional testing tools (exporting test functions
 or providing a test framework in which said functions are used). This
 module simply allows you specify the number of visitors and the number of
 *converted* visitors per experiment and for each experiment, returns a
 z-score and percentage to help you understand if you should reject the null
 hypothesis.
 Needless to say, this doesn't fit into the Boolean yes/no proposition of
 standard testing in Perl, so namespace suggestions are welcome.


Sounds like good work. Now I just wish I'd trust people to interpret
statistics in a useful manner :-/

Leon

Re: Conditional installation of XS (or graceful fallback)

[Leon Timmermans]

On Thu, Sep 19, 2013 at 8:20 AM, David Oswald daosw...@gmail.com wrote:

 On Wed, Sep 18, 2013 at 3:49 PM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 da...@cpan.org wrote:
  how to cause an install of
  List::BinarySearch to attempt to download and install
  List::BinarySearch::XS (a separate distribution)
  Include the prerequisite conditionally at configure time. The condition
  is whether xsubpp/cccmd can compile a dummy XS file.

 That's too late, isn't it?  If the user types, cpan install
 List::BinarySearch, Makefile.PL doesn't get executed until after the
 target module is pulled in.  Prereqs are specified in the
 distribution's META.* files.  By the time Makefile.PL is run, the
 installer is done pulling in prereqs.  The goal is for a cpan
 installer to pull in the XS distribution and attempt to install it.
 Failure not block the PP module from completing its install.


The META.* is only used for configure_requires (and dynamic_config to some
extent). After Makefile.PL/Build.PL the cpan client will read the
dependencies from the mymeta file, or lacking that from the Makefile
itself/build parameters file.

Leon

Re: cpan as generic installer? + Re: module for finding all git repos under a path

[Leon Timmermans]

On Thu, Sep 19, 2013 at 11:06 AM, Matthew Astley m...@sanger.ac.uk wrote:

 Now I have another script to add to my grubby collection, which I cast
 as a modulino.  It should probably go in CPAN.  Maybe I should fatpack
 it into git-yacontrib?  It languishes on a private branch.


I don't see why you would want to package a CPAN distribution as a
modulino. They can make sense as a better organized script if everything
has to be in one file, but in a CPAN distribution you're not limited in
that way.

Leon

Re: Alien::XXX needs something more

[Leon Timmermans]

On Thu, Aug 8, 2013 at 9:16 PM, Aristotle Pagaltzis pagalt...@gmx.de wrote:
 Yeah, that’ll work great until the moment someone supports three OSes.
 Or supports all OSes except a specific one. (Alien::NotVMS::FooBar?)

Or only recent versions of an OS…

Leon

Re: Alien::XXX needs something more

[Leon Timmermans]

On Sun, Aug 4, 2013 at 5:38 PM, Paul LeoNerd leon...@leonerd.org.uk wrote:
 Having a look more in detail at why, though, is revealing:

 For example:

   http://www.cpantesters.org/cpan/report/754b7df1-6c93-1014-b350-ae488c0ce015

 gives:


   # running Build.PL
   'make' is not recognized as an internal or external command,
   operable program or batch file.
   'libtool' is not recognized as an internal or external command,
   operable program or batch file.
   'glibtool' is not recognized as an internal or external command,
   operable program or batch file.
   OS unsupported - unable to find GNU libtool

 Similar things in unibilium.

 The specifics in this case are that libtermkey itself won't do anything
 useful on Windows, for lack of actual TTY devices, but there's no
 reason unibilium won't work. Its build system simply requires GNU
 libtool, and then it would build. Most Windows systems lack GNU
 libtool, so it can't be built there.

 If so, that is exactly the critical information needed
 so windows users don't go down a dead end trying
 to use those modules or perl modules requiring
 them.  I haven't come up with a good way to do
 that for the general case.  If one knows a priori
 any such restrictions, at least the docs should
 indicate that and the Makefile.PL or Build.PL
 could return NA in testing.

 But that is exactly what the OS unsupported string is for. Take a
 look again - running it produces that exact output:

   OS unsupported - unable to find GNU libtool

 It's far more useful to report this string, than simply telling people
 in advance that it won't work on Windows - because it /will/ work on
 any Windows box that has GNU libtool available; and also the same
 failure tells people on otherwise-supported platforms that simply lack
 a GNU libtool currently that they need to install it.

Sounds like an Alien::libtool may be useful ;-)

Leon

Re: META.yml/json and requiring itself for testing (CPAN.pm, Dist::Zilla)

[Leon Timmermans]

On Sun, Jun 9, 2013 at 7:26 AM, Serguei Trouchelle s...@cpan.org wrote:
 I was tried to install my own module (Dist::Zilla-based, more than a year
 old) on brand new 5.18.0 with all recent modules. CPAN shell (CPAN.pm 2.0)
 refused to build it, complaining about circular dependency. The problem is,
 it's self-dependency. When I tried to find out what's wrong, I found that
 META.json contains the module name in prereqs/test/requires. I understand
 that it was added by Dist::Zilla because tests use this module (obviously).
 But I had no problems with installing it some time ago (more than a year).

I would say it shouldn't self-reference.

 I've been away from the recent Perl trends for a while, so I'm not sure who
 is at fault here: CPAN.pm or Dist::Zilla (or some plugin to generate META
 file)?

Your tarball doesn't include the dist.ini, nor does it include a
reference to the repository. I do know that the META files and the
Makefile.PL are not matching each other, which probably means your
dzil setup is broken and wrong. This may also explain why it used to
work (Makefile.PL writes a MYMETA which doesn't include the circular
dependency).

Leon

Re: Dist::Zilla version handling

[Leon Timmermans]

On Sat, Feb 23, 2013 at 3:57 PM, Ovid
publiustemp-moduleautho...@yahoo.com wrote:
 How do I assert the Perl version I want with Dist::Zilla? I can't find it in
 http://dzil.org/tutorial/ and when I tried the MinimumPerl plugin, it said
 my minimum version is 5.12 when I believe it to be 5.10.0.

perlver --blame $filename will tell you why it thinks you need 5.12,
though there are only 3 possible reasons in this case:
* The yada yada yada operator
* package-name-version
* postfix when.

Last time this happened to me it was the first option.

Leon

Re: Unauthorizated release

[Leon Timmermans]

On Sat, Jan 26, 2013 at 8:03 AM, Xavier x.guim...@free.fr wrote:
 I've upload development version of LemonLDAP::NG libraries, but they are
 displayed as unauthorizated release even if modules are registered by me.
 Any idea ?

As can be seen at
https://pause.perl.org/pause/authenquery?pause99_peek_perms_by=mlpause99_peek_perms_query=Lemonldap%3A%3ANG%3A%3APortal%3A%3A%25pause99_peek_perms_sub=Submit,
you're lacking permissions on a number of namespaces. You should talk
to coudot and let him fix that for you.

Leon

Re: DB_File is not installed?

[Leon Timmermans]

On Thu, Nov 22, 2012 at 1:43 PM, Shmuel Fomberg shmuelfomb...@gmail.com wrote:
 Hi All.

 I've released a module, Dist::Surveyor v0.007, and seeing reports from CPAN
 testers that DB_File doesn't exists.
 DB_File is not listed in the deps, because, well, it is core.

 http://www.cpantesters.org/distro/D/Dist-Surveyor.html#Dist-Surveyor-0.007

 Interestingly, most of the fails come from Solaris. but a few from Linux
 too.
 Any idea why the module is missing?

The *DB_File modules aren't build when their library (in this case,
libdb aka Berkeley DB) isn't present on the system. Only SDBM_File is
guaranteed to be present because it's bundled with perl.

I think all of them are prime targets for dual-living, which might
alleviate some of these issues (though external dependencies are
always tricky).

Leon

Re: RFC: the Author:: namespace

[Leon Timmermans]

On Sat, Sep 8, 2012 at 6:59 PM, sawyer x xsawy...@gmail.com wrote:
 No, I can't. Acme:: is people sharing jokes, which in most cases aren't
 supposed to be useful, they're JOKES. Author::PAUSEID,
 Task::BeLike::PAUSEID and Dist::Zilla::PluginBundle::PAUSEID are by people
 *not* sharing *anything* with *anyone* except using CPAN as their private
 repository. So, yes, there's a major difference.

Dist::Zilla author bundles are useful if anyone wants to contribute to
your project.

 Obviously CPAN is a place to upload modules so others can view, share and
 use them.

 By your claim, I can use CPAN to upload my last YAPC trip pictures (and
 hell, replace Flickr), because I've never seen any description of what CPAN
 is. So, no, there isn't a given description, but I think it's pretty
 obvious to both of us and anyone on this list and on CPAN. Using generic
 excuses as there's no sign on what goes in the pool, so I can pee in it
 don't help us much here.

Not saying it's a good idea, but it has been done before, and not by
the least of us:
http://backpan.perl.org/authors/id/M/ME/MERLYN/index.html

Leon

Re: Broken compilers, ignore or ???

[Leon Timmermans]

On Tue, Sep 4, 2012 at 4:00 PM, Martin J. Evans
martin.ev...@easysoft.com wrote:
 Thanks, I did not know that.

Klortho #11907 ;-)

Re: Broken compilers, ignore or ???

[Leon Timmermans]

On Tue, Sep 4, 2012 at 3:40 PM, Martin J. Evans
martin.ev...@easysoft.com wrote:
 I recently received an rt (https://rt.cpan.org/Ticket/Display.html?id=79190)
 saying some code in DBD::ODBC was wrong and a patch to fix it. The code was:

while (*cp != '\0') {
   *cp++ = toupper(*cp);
}

 and the fix (which shouldn't be required as the above code is fine) was:

while (*cp != '\0') {
   *cp = toupper(*cp);
   cp++;
}

The order of execution is undefined if you read a variable and assign
to it in the same (sub)statement. The compiler is allowed to read the
*cp on the right both before the cp++, as the only sequence point is
the semicolon at the end.

The patch as offered does the correct and safe thing of splitting it
up in two statement.

 The test code and his results are below. I can obviously avoid this issue
 with a simple change to the code but how many other places might this occur?
 Do I ignore this (as the reporter is happy to use a newer working compiler)
 or do I somehow check for a broken compiler and abort the Makefile? Has
 anyone else come across something like this and what did they do?

You fix it. GCC will actually want you against this if you enable
-Wall/-Wsequence-point

Leon

Re: How do I arrange for Makefile.PL to create a modulino instance script?

[Leon Timmermans]

On Fri, Aug 31, 2012 at 3:29 PM, David Christensen
dpchr...@holgerdanske.com wrote:
 module-authors:

 I am working on a modulino [1] and would like to use ExtUtils::MakeMaker to
 generate a Makefile such that make (or make all) copies the module file
 (lib/MyModulino.pm) to a script file (perl-bin/mymodulino.pl) and sets the
 execute bit.


 Any suggestions?

Why do you want to do this? I can see absolutely no reason why this
would be preferable over a traditional module/script split *in a CPAN
distribution* (which doesn't mean they can't be useful in other
situations). The system does not look for executables in the same
place as perl looks for modules, this sounds to me like you're only
making things more complicated for yourself.

Leon

Re: MIN_PERL_VErSION

[Leon Timmermans]

On Sun, Aug 5, 2012 at 5:23 AM, Geoffrey Leach ge...@hughes.net wrote:
 So, what am I doing wrong?

 FWIW, the problem that gives rise to this question

 g++ ... TagLib.c
 In file included from /usr/include/c++/4.2/bits/basic_ios.h:44,
  from /usr/include/c++/4.2/ios:50,
  from /usr/include/c++/4.2/ostream:45,
  from /usr/local/include/taglib/tbytevector.h:33,
  from /usr/local/include/taglib/tbytevectorlist.h:30,
  from TagLib.c:178:
 /usr/include/c++/4.2/bits/locale_facets.h:4420:40: error: macro
 do_open
 requires 7 arguments, but only 2 given
 /usr/include/c++/4.2/bits/locale_facets.h:4486:55: error: macro
 do_open
 requires 7 arguments, but only 2 given

 I'm guessing (no way to verify) that the problem arises out of the fact
 that the tester is running v4.2 of g++, while I have 4.7.0

 I'm running Fedora 17

The problem has nothing to do with perl versions. It is simple and
highly annoying: perl has a do_open macro, but libstdc++ has do_open
methods. This clashes in ugly ways. The simplest way to deal with this
is to undefine do_open before loading any C++ headers, but you may hit
other defines (in particular do_close). Perl's API is made for the
flat namespaces of C, not the hierarchical namespacese of C++. Macro's
that are almost sane in C turn out to be highly problematic in C++.

It gets even worse on Windows, where perl will define short macros
such as read() and write() by default. The NO_XSLOCKS define is your
friend there.

Leon

Re: Seeking advice on module name: Config::CPP?

[Leon Timmermans]

On Fri, Mar 23, 2012 at 10:49 PM, David Oswald daosw...@gmail.com wrote:
 I maintain Inline::CPP.  Currently that module's Makefile.PL jumps
 through a bunch of hoops to detect the C++ compiler most compatible
 with the C compiler that built perl, and to detect what default C++
 libraries should be linked in when building Inline::CPP client code.
 A lot of work has gone into tweaking to obtain better success rates
 with as wide a variety of platforms as possible.

 This work could be applicable to other modules that wish to build XS
 code based on C++.  Additionally, I would like the ability to continue
 development (there's a lot of work still to do) on this task
 independently of Inline::CPP (I don't like uploading a new Inline::CPP
 for smoke testing every time I want to smoke test a change to
 Makefile.PL while leaving the core modules virtually unchanged).

 So I intend to split this functionality out of Inline::CPP's
 Makefile.PL by creating a new module to handle the detection/guessing
 logic.

 That begs the question of what to call it.  Config already reveals
 information about how Perl was built (C compiler, etc.).  This is
 essentially an extension of that functionality.  Therefore, it makes
 sense to me to call it something like Config::CPP.  But
 unfortunately, Config shares its top-level namespace with modules that
 are used to deal with configuration files (Config::Auto,
 Config::General, Config::JSON, etc.).

 My question is what would be an appropriate name for this module?

This sounds very similar to ExtUtils::CppGuess. If you don't want to
merge it with that, something in the ExtUtils namespace would be
appropriate IMO.

Leon

Re: The module authors pledge

[Leon Timmermans]

On Tue, Nov 8, 2011 at 5:22 PM, Neil Bowers n...@bowers.com wrote:
 One of the problems I see with CPAN is that there are many modules
 which have been left unattended. Many of these have outstanding bugs,
 and a good number have patches and forked versions, some of which you can
 find on RT. You'll also find people offering to take over the maintainership
 of modules. While reviewing modules I've identified a lot of fixes, and
 documentation improvements, but it can take a lot of effort to get them out.

 If the author or current maintainer of a module is unresponsive, there's
 a well-defined, but lengthy, process to request co-maintainership.
 There are good reasons for this -- I'll assume you've read them.
 But in reality, plenty of authors lose interest

 To make life easier for the perl modules cabal, how about a voluntary
 pledge[*], which module authors can take publically, and in particular
 can take to modu...@perl.org. I'll be emailing the following to
 modu...@perl.org:

    I hereby give modu...@perl.org permission to grant co-maintainership
    to any of my modules, if the following conditions are met:

    (1) I haven't released the module for a year or more
    (2) There are outstanding issues on RT which need addressing
    (3) Email to my CPAN email address hasn't been answered after a month
    (4) The requester wants to make worthwhile changes that will benefit CPAN

    Should I die, then the time-limits in (1) and (3) do not apply.

 This means it will be archived, and easily accessed. I'll put this in the
 README for my modules.

 If others, and particularly the modules cabal, think this is a good idea,
 maybe we could have a canonical place this this, which can be easily
 referred to. Perhaps PAUSE could let me record it, so there's one place
 the modules cabal can check? Or you could put it in module metadata?

 So, what do y'all think?

I've been having the same idea. I'd say the right place is a clearly
named file your CPAN home dir, preferably something explicit and
standardized about when you're ok with it and when not.

Leon

Re: The module authors pledge

[Leon Timmermans]

On Thu, Nov 10, 2011 at 1:32 PM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 da...@cpan.org wrote:
 Metadata can already be attached to distributions in an extensible
 fashion. It's really about the code, not the author/maintainer - one
 can have different opinions on/policies for different distros.

True, though most of the time that probably won't be necessary.

Leon

Re: How to break apart a large distribution?

[Leon Timmermans]

On Tue, Oct 18, 2011 at 5:28 AM, Fields, Christopher J
cjfie...@illinois.edu wrote:
 The BioPerl core developers (including myself) have decided to work on 
 breaking up the huge code base into separate distributions on CPAN, using 
 dependencies to install only the needed modules (something WAY overdue).  I 
 noticed that several distributions have undergone similar paths (LWP being a 
 recent example).

 Any pointers we could use?  Can this be gradually done (BioPerl is HUGE, 
 around 1000 modules), or should we have these all ready to go at once?

I've been pondering the same. For parts of the codebase that don't use
much dynamic module loading it may be possible to automatize this
using Perl::PrereqScanner. I think we could actually use some
clustering algorithm after that (irony points for reusing biology
knowledge there).

Leon

Re: Math::BigInt inheritance problems

[Leon Timmermans]

On Sun, Oct 9, 2011 at 4:27 PM, Paul Bennett paul.w.benn...@gmail.com wrote:
 Hi all,

 I know this isn't the best place to ask for help with specific coding help,
 but I'm bumping up against what appears to be the edges of Perl normality
 here, and I figure there's gotta be at least one person reading this who is
 better-informed than me about the modules in question.

 Ideally, I'm hoping one or more of FLORA, LETO, pjacklam, or TELS is reading
 this, or at least someone who can put me in direct contact with one of them.

 I'm looking for people who know about inheriting from Math::BigInt::GMP
 and/or Math::BigInt::Pari to help me improve
 http://matrix.cpantesters.org/?dist=Net-IPAddress-Util -- latest source is
 at
 http://code.google.com/p/perl-ipaddress-simple/source/browse/#svn%2Ftrunk%2Flib%2FNet%2FIPAddress

 I'm convinced I'm doing something obviously and stupidly wrong, but I can't
 for the life of me see the forest for the trees. See also
 https://rt.cpan.org/Public/Bug/Display.html?id=67204

I think the obvious mistake you're making is using inheritance in the
first place. Why are you doing that? Your interface is not «an IP
address is really a number», so why would you make it one?

Leon

Re: Math::BigInt inheritance problems

[Leon Timmermans]

On Sun, Oct 9, 2011 at 4:44 PM, Paul Bennett paul.w.benn...@gmail.com wrote:
 Ah, but an IP address *is* really a number. An unsigned 128-bit integer, in
 fact, with some additional properties that are specific to the semantics of
 IP addresses themselves.

Do you really want your end users to think of IP addresses as numbers?

 True, certain operations (multiplication and division spring to mind) are --
 probably -- bad ideas, but addition, subtraction, bitwise operations,
 bitshifting, comparison (including range comparison and sorting), and many
 other good numbery things definitely apply.

You're confusing implementation and interface. I'm not saying bigints
are a wrong implementation for this, I'm saying you shouldn't expose
that to your end users. Precisely because almost all numeric
operations do not make sense on an IP address.

Leon

Re: Module::Build::Tiny

[Leon Timmermans]

 If you're using Dist::Zilla, you *should* not need anything besides
 META.json to install a simple module if you just set dynamic_config=0.
 (This should is, of course, largely unimplemented.)

I hope a lot of Module::Built::Tiny will end up getting reused for that purpose.

 Overall, it looks interesting, but I would hope that it at least adds
 some runtime support if not also C/XS.

If not, there will be another Build.PL implementation that does.

 Sadly, cpanm seems to not support dynamic_config.  I'm not sure whether
 one of the other two clients can satisfy prereqs from META, run
 `prove -lr t`, and install the files from lib/ yet.

In the meta spec 2.0, dynamic_config is defined more strictly than in
previous versions; it only refers to the configuration phase. There
are some complications with static building/installing.

Leon

Re: Module::Build::Tiny

[Leon Timmermans]

On Mon, Aug 29, 2011 at 7:50 AM, Aristotle Pagaltzis pagalt...@gmx.de wrote:
 I find this module intriguing.

I'm happy to hear that :-)

 In my understanding, the complexity of Module::Build piled up
 because the same tool tries to cover both installation and
 authoring use cases.

There are many things that contribute to that. I think there's a more
general everything-and-the-kitchensink issue going on in
Module::Build. In Module::Build::Tiny I'm trying to go into the
opposite direction: modularize everything that's reusable so the
central module is actually quite small and simple.

 But is the implementation up to par?

Not yet, but it's getting close. I'm still dealing with some
portability issues, but the core idea of it seems sound. For a pure
perl module that runs only on Unix on perl 5.10.1 or higher, it should
be up to par now already. If not bug reports are welcomed. I'm only
using it for two relatively unimportant modules so far, but I'm
planning to try it with more modules as soon as the known issues have
been ironed out.

 Essentially: if I’m using Dist::Zilla for authoring, what regular
 features not explicitly mentioned in MBT’s POD would I have to
 avoid? Do things like optional or build-/test-only deps work?
 (I’d assume these do.) Or can I assume that everything will work
 unless otherwise pointed out?

Dependencies are handled in the CPAN client (and written by
Dist::Zilla), so that should be no problem.

 (I’d also be interested in whether any omissions mentioned in the
 POD are design choices or the idea is to add them in the future,
 and which if so.)

HTML documentation support should definitely be added before I'd
consider it finished; the others are design choices. That said, I'm
not opposed to implementing any of the others if it can be done in a
tiny enough way. If I end up adding extensions (which would
essentially mean a rewrite of MBT) then even the tininess restriction
would be gone for the other ones I guess.

On Mon, Aug 29, 2011 at 5:07 PM, David Golden dagol...@cpan.org wrote:
 for C/XS modules, a lot
 of libraries are needed to compile the XS, location the C compiler,
 etc.  This is ugly, complicated stuff to get right portably, which is
 why MBT doesn't do it (yet)

I have a prototype tying together ExtUtils::CBuilder and
ExtUtils::ParseXS, it only supports simple XS modules and is so far
only tested on Linux, but it was pleasantly simple to implement.

 Eric raises the question why bother and I think for module authors,
 at least right now, there is no burning platform to switch.  Schwern
 has been trying to get people to stop using EU::MM for years and I
 think the MBT is a stepping stone towards that vision.  Once it
 figures out the hard bits of interacting with the toolchain, it should
 be relatively easy for it or successors to add the missing features
 within a well-defined framework.

Yeah, most of all MBT is an experiment. It's proof that writing a
Build.PL implementation doesn't have to be all that hard. It's a
process of getting the modules out there that make it easier. Being a
viable alternative to existing builders is a bonus really. At some
point there will be a non-tiny successor that will do everything
Module::Build can and more without becoming an monolith.

 Perl 5.10.1 supports configure_requires and is already unsupported by
 P5P, though the Perl toolchain maintainers have an informal agreement
 to support older Perls (5.6 at least, though that may shift to
 something in the 5.8 series with decent Unicode support before long).

Yeah, I think that on the medium timescale 5.8's lack of
configure_requires is the main handicap. Fortunately that problem will
fix itself if given enough time.

Leon