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

[James E Keenan]

Recap:

On 1/23/20 3:03 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)


[snip]


#

So, what do I need to do to get Dist::Zilla and Travis to play nice with 
each other?  (Attached: the Travis config I wrote and the existing 
dist.ini file.)


As reported earlier in this thread, removing '--auto' from the Travis 
configuration, as recommended by Dan Book, did the trick.


2.  For testing on Windows, how do I add an Appveyor configuration to a 
distribution maintained with Dist::Zilla?


I haven't tried an Appveyor configuration/run yet, but since I had 
problems with Travis, I assume I'll also encounter problems with Appveyor.




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.


Thank you very much.
Jim Keenan

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

[James E Keenan]

On 1/23/20 3:18 PM, Dan Book wrote:
On Thu, Jan 23, 2020 at 3:04 PM James E Keenan <mailto:jkee...@pobox.com>> 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

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

[James E Keenan]

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 Dist::Zilla and Travis to play nice with 
each other?  (Attached: the Travis config I wrote and the existing 
dist.ini file.)


2.  For testing on Windows, how do I add an Appv

Re: executable only Perl distributions & CPAN

[James E Keenan]

On 09/12/2018 08:02 AM, David Cantrell wrote:

On Fri, Sep 07, 2018 at 01:18:28PM -0700, Karen Etheridge wrote:

On Fri, Sep 7, 2018 at 12:59 PM, Diab Jerius  wrote:

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.

Option 1 is correct -- create an App::pltvectors module which is indexable
and installable.  However, it doesn't need to be an empty package -- not
only can it contain documentation for your script, but it could also
contain most of the functionality from the script as well, turning the
script into a wrapper that calls the module. That also allows others to
make use of the code in their own scripts.


It would also make it easier to write tests for your code - you'd be
able to load the module and call individual methods in it and check
their return values and side-effects instead of having to shell out to
the script a zillion times.



+1 to that as well!

Re: executable only Perl distributions & CPAN

[James E Keenan]

On 09/07/2018 04:18 PM, Karen Etheridge wrote:



On Fri, Sep 7, 2018 at 12:59 PM, Diab Jerius > wrote:



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.


Option 1 is correct -- create an App::pltvectors module which is 
indexable and installable.  However, it doesn't need to be an empty 
package -- not only can it contain documentation for your script, but it 
could also contain most of the functionality from the script as well, 
turning the script into a wrapper that calls the module. That also 
allows others to make use of the code in their own scripts.


+1

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

[James E Keenan]

On 09/06/2017 11:12 AM, Dan Book wrote:
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


I concur with Dan.

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

[James E Keenan]

On 05/03/2017 04:12 AM, Smylers wrote:

BC writes:


I'd like some feedback and advice for naming some modules I am
contemplating.

   Image::Stereo::MPO
   Image::Stereo::JPS
   Image::Stereo::JPG


Sounds good to me — you've clearly considered this carefully, and your
explanations make sense.

Smylers



I concur with Smylers.  +1

What is best practice for 'git reset'?

[James E Keenan]

I am maintainer of a CPAN distribution whose most recent official 
release is version 2.12.


Since 2.12 was published, we have made the following development releases:

2.12_001
2.12_002
2.12_003
2.12_004

In the git repository, we have tags for:

2.12_002
2.12_003
2.12_004

(Somehow 2.12_001 was overlooked or has not yet been set.)

I now realize that much of the code (mostly tests, but some source) 
added in 2.12_003 and 2.12_004 is conceptually flawed.  For other 
developers and myself to treat 2.12_004 as the starting point for future 
development would not be fruitful.


What I would like to do is to go back to 2.12_002 and start development 
anew from there -- but without pretending that 2.12_003 and 2.12_004 
were never released.  I would like 2.12_005 to be equivalent to 2.12_002 
but with only very safe, minor touchups.


Would the following be the recommend sequence of git commands?

$ git checkout master
$ git checkout -b start-anew
$ git reset --soft 2.12_002
$ git commit -m "Rewind to tag 2.12_002"
# hack, hack, hack
$ git add ...
$ git commit -m "Slight touchups to what was 2.12_002"
$ git checkout master
$ git merge start-anew
$ git tag "2.12_005"

Thank you very much.
Jim Keenan

Re: Namespace advice for Git-related package

[James E Keenan]

On 10/27/2016 11:25 AM, Smylers wrote:

James E Keenan writes:


Alternatively, Devel::Git::MultiBisect would indicate that this is a
tool for Perl development use.



And that's what I ultimately went with!  This is indeed a developer's tool.

http://search.cpan.org/dist/Devel-Git-MultiBisect-0.01/

Thank you very much.
Jim Keenan

Namespace advice for Git-related package

[James E Keenan]

I am in the process of developing a CPAN library which I am considering 
calling Git-Multisect-Perl.  The library would have packages with names 
starting with 'Git::Multisect::Perl::' and would contain an associated 
command-line utility to be called 'multisect'.


Given a Perl library or application kept in git for version control, it
is often useful to be able to compare the output collected from running
one or several test files over a range of git commits. If that range is
sufficiently large, a test may fail in more than one way over that
range.

If that is the case, then simply asking, "When did this file start to
fail?" is insufficient. We may want to capture the test output for each
commit, or -- more usefully -- may want to capture the test output only 
at those commits where the test output changed.


Though the library is currently on github.com as 'test-multisect', I'd 
like to change that because putting 'Test::' first in a Perl package 
name usually means an extension to Test::Simple, Test::Builder or 
Test::Harness.


It appears that the top-level namespace 'Git::' is used for both 
libraries that wrap git and those that do something useful with git. 
This library will fall into the latter category.  (In hindsight, perhaps 
we should have created a top-level 'Gitx::' namespace.)


'Multisect::' is chosen to contrast with 'bisect'.  When we speak of 
bisection in the context of, say, Perl 5 core development and use of 
Porting/bisect.pl, we're usually looking for a single answer to a 
question, e.g., at which specific commit did this test file start to 
experience failures.  Recently, however, we have a case where a file 
failed in different ways over many months.  That's the actual use case 
which led me to develop this library.


The '::Perl' in the namespace is intended to say, "This is a way to 
apply the concept of multisection to typical needs in Perl development 
such as CPAN distributions and P5P, but we don't want to foreclose the
possibility of future libraries which use git to perform multisection in 
other problem spaces."


I'm in the advanced stages of development of this library so, while I 
welcome advice, I hope to avoid bikeshedding and I recognize that 
whatever name I go with will make some people unhappy.  So be it.


Thoughts?

Thank you very much.
Jim Keenan
CPANID: jkeenan

Re: How to avoid circular module dependencies within a distribution?

[James E Keenan]

On 10/18/2016 02:05 AM, David Christensen wrote:

module-authors:

I am in the process of writing a Perl distribution that currently
contains a dozen or so packages, several dozen exportable subroutines,
and over a hundred exportable constants.


At this point I feel compelled to ask:

Why?

Why do you want to design a library with so many exportable subroutines 
and (worse!) constants?


Now, I concede that the statements above are merely background for your 
questions about circular dependencies.  So my questions run the risk of 
sending discussion off in a different direction.  And we don't yet have 
your code to look at.


But, on the basis of the experiences of the Perl 5 Porters in 
maintaining POSIX.pm -- which suffers from these problems, see 
http://search.cpan.org/~rjbs/perl-5.24.0/ext/POSIX/lib/POSIX.pod#CAVEATS 
-- I would be reluctant to use any library with a large number of 
exportable symbols and consequent risk of namespace pollution.


My 2 cents.

Thank you very much.
Jim Keenan

Re: Comment on module name Data::ETL

[James E Keenan]

On 05/04/2016 09:27 AM, Smylers wrote:

Robert Wohlfarth writes:


I'm weighing 3 ideas...
2. Create a top-level namespace for ETL.

Idea 2 looks like so...
* ETL
* ETL::Extract
* ETL::Extract::Excel
* ETL::Extract::DelimitedText
* ETL::Extract::XML
* ETL::Load
* ETL::Load::MSAccess


Not necessarily. That would be effectively claiming the ETL:: namespace
is for your suite of modules.

An alternative would be to create the ETL:: top-level namespace and then
put your framework under another level of hierarchy there, leaving space
for other ETL modules to share ETL::. As in:

• ETL::$Brand
• ETL::$Brand::Extract
• ETL::$Brand::Extract::Excel
• ETL::$Brand::Extract::DelimitedText
• ETL::$Brand::Extract::XML
• ETL::$Brand::Load
• ETL::$Brand::Load::MSAccess

— where $Brand is a word/phrase of your choice (either just a fanciful
name you like, or one you think sums up your particular ETL module suite
over other (potentially yet to be written) options.



This is what I would recommend as well.

Re: good form for discontinuing a module

[James E Keenan]

On 06/07/2015 02:38 PM, Chris Marshall wrote:

The PDL::FFTW module is out-of-date and has been essentially broken
for a long time without anyone being aware of it.  It has been marked
deprecated in favor of PDL::FFTW3 and I think now is the time to finally
remove it from CPAN.

Should I just go ahead an delete it or is there another, intermediate
way to "more softly" transition in case someone, somewhere is actually
using/requiring PDL::FFTW?



If someone is actually using PDL::FFTW, then they already have it -- 
right?  So their current use has no dependency on whether or not the 
module still is indexed on CPAN.


So, depending on how long a deprecation period you or the maintainers 
announced, I don't see a barrier to deletion.


Thank you very much.
Jim Keenan

Re: Curating old dists on CPAN

[James E Keenan]

On 04/30/2015 06:10 PM, Neil Bowers 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.

Neil




I don't believe that any distribution should be moved from CPAN to 
backpan without the consent of the author or maintainer unless he or she 
is dead.

Re: =head1 SEEN ALSO BY

[James E Keenan]

On 04/04/2015 10:43 AM, Aristotle Pagaltzis wrote:

Hi Tim,

* Tim Bunce  [2015-04-04 13:25]:

Independently of that, I'd love to see something like a 'mentioned by'
page. It would list all other distros that mention (via an L
link) a module in this distro.


d’oh – of course.


It would look like the revese dependencies page.


Or more to the point, “what links here” as seen in many wikis.


Bonus points for also recording and showing the header of the pod
section that the L<> was seen in.


That was the first thought that popped into my head after the d’oh, too.
:-)

I like! Now someone’s just gotta do it…



I'm not volunteering to do this, but ... it does sound like the sort of 
thing that would benefit from some attention at the upcoming New York 
City Perl Hackathon.


If someone were to write up a specification, it could be posted on our 
Projects page:


https://github.com/nyperlmongers/nyperlhackathon2015/wiki/Projects

Thank you very much.
Jim Keenan

Re: Test failing on Windows but not elsewhere

[James E Keenan]

On 03/09/2015 07:54 PM, Leon Timmermans wrote:

On Mon, Mar 9, 2015 at 11:44 PM, James E Keenan  wrote:


Suggestions?



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

Leon



Thanks, Leon, that appeared to work:
http://matrix.cpantesters.org/?dist=CPAN-Mini-Visit-Simple

Test failing on Windows but not elsewhere

[James E Keenan]

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?

Thank you very much.
Jim Keenan

How avert warning re MYMETA.* ?

[James E Keenan]

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?


Thank you very much.
Jim Keenan

Re: "throw away" module namespace

[James E Keenan]

On 12/12/2014 11:38 AM, Yanick Champoux wrote:

On 14-12-12 11:33 AM, Chris Marshall wrote:

Else, any recommendations on how to
accomplish the goal of not locking in the
namespaces until the organization of the
various components settle down?


Just throwing ideas: an alternative would be to have your module lives
on GitHub, and use the fact that cpanm can also install modules directly
from there:



+1 !

Re: Broken CPAN Modules

[James E Keenan]

On 09/16/2014 06:16 PM, Gabor Szabo wrote:

Actually, while I managed to install quite a few modules, there were a few
that were "not found" on CPAN by cpanm:
eg.
Dancer,  Catalyst::Runtime and WWW::Shorten

For example I just saw this:

$ cpanm Catalyst::Runtime

Catalyst::Runtime

--> Working on Catalyst::Runtime

[snip]

! Failed to fetch distribution Catalyst-Runtime-5.90072



I just used perlbrew to upgrade my everyday perl to 5.20.1.  I then used 
cpanm to install Catalyst, Catalyst::Runtime and Dancer.


No problems whatsoever.

jimk

Re: Top level name proposal - ComputeCluster

[James E Keenan]

On 09/04/2014 10:23 AM, John Macdonald wrote:

Hi,

I wanted to get general comment/concensus about a top level name that I
am proposing.

I'm starting to organize a set of modules for managing jobs on a
computer cluster.  I intend it to work much like DBI - with a top level
abstract interface that programs can use, actually implemented by
drivers that translate the common interface into the interface used by
the particular type of compute cluster that is being accessed.
Initially, I will provide a driver for SGE, since that is what we have
and use in our lab (but after I have that running, my PI can get me
access to a couple of other type of compute cluster to add some more.

For naming, I am planning to use:

 ComputeCluster - top level name
   - will provide switching functions to create a class of object
for a particular cluster type



Could that be shortened to simply:  Cluster ?

Re: Module to test SQL data

[James E Keenan]

On 12/9/13 5:03 AM, Francesc Guasch wrote:

On Fri, Dec 06, 2013 at 07:01:32PM -0500, James E Keenan wrote:




It's not a big deal, I add a Makefile.PL. I must admit I struggled
with Dist::Zilla myself when I had to install my own module in
other servers.


Today I found a few minutes to checkout the latest version
of Test-SQL-Data from
https://github.com/frankiejol/Test-SQL-Data.  Thanks for
adding the Makefile.PL.  What follows reflects my own
opinions and should not be taken as a definitive evaluation.

I pay a lot of attention to the degree to which a CPAN
distribution's test suite exercises its source code.  I use
Devel::Cover to study that.  So the first thing I did was to
say:

perl Makefile.PL && make && cover -delete && \
HARNESS_PERL_SWITCHES=-MDevel::Cover make test && \
cover -summary

$ cover -summary
Reading database from /Users/jkeenan/gitwork/Test-SQL-Data/cover_db
[trimmed]

 -- -- -- -- --
File  stmt   bran   condsub
 -- -- -- -- --
blib/lib/Test/SQL/Data.pm 97.4   71.0   66.7  100.0
 -- -- -- -- --

That's *very* impressive test coverage right out-of-the-box!

However, ...

I then turned to study the source code.  I think what you
have written is, fundamentally, *not* something that belongs
in the Test::* namespace on CPAN.  That's because what your
module does is to provide methods for *initializing a
database in preparation for testing and debugging during
development*.  Your module does not provide new functions
that work on the Test::Builder framework.

Let me elaborate a bit on that.

Test::Builder is a module which provides a singleton object
which on which basic test methods are called and which keeps
track of the status of tests.  (See: perldoc Test::Builder)
You and I will almost never use Test::Builder directly.
Instead, we will use modules like Test::Simple, Test::More,
Test::Class, Test::XPath, etc., which (a) inherit that
Test::Builder singleton object; (b) provide functions which
wrap around (and cleverly disguise) Test::Builder's methods.
So the following functions:

Test::Simple::ok()
Test::More::ok()
Test::More::is()
Test::More::like()
...

... are all working with the same object.  Broadly speaking,
all such functions are expected to evaluate an expression
and either (a) say whether it's "ok" -- Perl-true -- or not;
or (b) compare the value we "got" with some value we
"expected".  All such functions are then expected to take an
argument which is the "name" or human-readable "description"
of an individual test.  These functions produce output
according to the Test Anything Protocol (TAP) so that the
results can be aggregated by distributions like
Test::Harness and TAP::Harness and utilities like 'prove'.

My hunch -- I'll let others corroborate this -- is that you
don't need any of that in Test::SQL::Data.  My
recommendations are that you:

* Remove the 'use Test::More;' from the module.
* Remove the few calls of Test::More::ok() from inside
  your _check_count() and match_table().
* Rename the module to something not beginning with "Test::".
* In your test suite, use basic Test::More functions like ok(),
  is() and like() to test the *return values* of functions like
  _check_count and match_table().

What you will then be left with is a module which focuses on
methods for preparing a database for use during the kind of
testing and debugging one does during a software development
cycle.  What that module should be named and how well your
module serves its intended purpose is a discussion I'll
leave to others.

HTH

Thank you very much.
Jim Keenan

Re: Module to test SQL data

[James E Keenan]

On 12/4/13 3:12 AM, Francesc Guasch wrote:

On Tue, Dec 03, 2013 at 07:09:16PM -0500, James E Keenan wrote:





2. Is the source code publicly available somewhere, e.g., github.com?


I don't know what I was waiting for. Here it is now:

 https://github.com/frankiejol/Test-SQL-Data


Okay.  Now, although I will probably catch hell from the Toolchain Gang 
for saying this, the fact that your distribution is structured *only* 
with dzil poses a barrier to my evaluating it.


Your README says that to install one should call 'dzil test', then 'dzil 
install'.  However, for 'dzil test' to complete I have to install 
someone's (not your) authordeps bundle:


$ dzil authordeps | cpanm
...
--> Working on Dist::Zilla::Plugin::VersionFromModule
Fetching 
http://search.cpan.org/CPAN/authors/id/C/CJ/CJM/Dist-Zilla-Plugins-CJM-4.20.tar.gz 
... OK


That's more work than I want to do to evaluate a module.  If you 
supplied a Makefile.PL, that would give me an incentive to take a second 
look.


Thank you very much.
Jim Keenan

Re: Module to test SQL data

[James E Keenan]

On 12/4/13 3:12 AM, Francesc Guasch wrote:

On Tue, Dec 03, 2013 at 07:09:16PM -0500, James E Keenan wrote:



1. Is this module built on the Test::Builder framework in the way
that Test::Simple, Test::More, Test::Most, etc., are?


It is not built on Test::Builder. It requires Test::More.
It performs tests on the data and runs ok and not_ok.



Test::Builder is what's inside Test::Simple, Test::More, etc.  So your 
distro is built on Test::Builder -- which is what I was hoping for.



2. Is the source code publicly available somewhere, e.g., github.com?


I don't know what I was waiting for. Here it is now:

 https://github.com/frankiejol/Test-SQL-Data

Re: Module to test SQL data

[James E Keenan]

On 11/27/13 7:31 AM, Francesc Guasch wrote:

Hi. I wrote a module to help writing tests for modules that
perform operations in SQL databases. I was considering the
name

 Test::SQL::Data

In short, it helps running SQL tests: database preparing and
result matching.

When the module loads it prepares the database. It can be
empty or pre-load some SQL data before running your code.
Then you can use the module again to check if your
expected results match the contents of the tables of the
database.

Any concerns ? Thank you.


This sounds useful, but let me ask some questions that I suspect other 
people are thinking about as well:


1. Is this module built on the Test::Builder framework in the way that 
Test::Simple, Test::More, Test::Most, etc., are?


2. Is the source code publicly available somewhere, e.g., github.com?

Thank you very much.
Jim Keenan

Re: Problem naming a module

[James E Keenan]

On 11/25/13 8:04 AM, Philippe Bruhat (BooK) wrote:

On Mon, Nov 25, 2013 at 12:27:58PM +0100, Aristotle Pagaltzis wrote:



[snip]


The other option is to give up on being descriptive, and come up with a
"brand" name. In which case, Fleur is just as fine as anything else. :-)



No, it's not.  "Fleur" implies a superclass of "Rose", which this is 
not. :-)

Re: What to call a module that rewrites Perl code

[James E Keenan]

On 9/2/13 5:36 PM, Robert Rothenberg wrote:

Thank you for your comments.

To answer various questions/suggestions/comments:

- It will be for rewriting Perl, exclusively, using PPI, with Perl-centric
rules, so "Code" is not an appropriate namespace. (I don't think the PPI
namespace is appropriate, since in theory, it could use something else.
Note also Perl::Tidy and Perl::Critic.)

- It will be for modifying actual script/module files, as opposed to
modifying code on the fly, so "Filter" is not an appropriate namespace.

- "Perl::Transform" is good name, but I think means the same thing as
"Rewrite".  Since the latter is shorter, it wins. (I don't like the way
"Perl::XForm" looks, and that makes it look like it has something to do
with forms in X-Windows.)

- I'm thinking Perl::Rewrite is the best name, for now, since it rewrites
code using PPI. Bit by bit I will develop it on GitHub
https://github.com/robrwo/Perl-Rewrite - for now it just has some stub
rules, until I flesh out the interface etc.



This sounds like a worthy project -- and one that would be valuable for 
organizations with a lot of legacy Perl code.  Good luck on your efforts!


Jim Keenan

Re: Taking over maintenance of a module

[James E Keenan]

On 5/11/13 12:26 AM, Matt Simerson wrote:


I've noticed that quite a few modules have maintainers, who take  over when an 
author goes AWOL. What is the process for for achieving that?



perldoc -q module

or

perldoc perlfaq7

Re: Mail::DMARC

[James E Keenan]

On 10/5/12 4:52 AM, Davide Migliavacca wrote:

Hi,

I am currently working at an implementation of DMARC support in a Perl module.
My guess for the name would be Mail::DMARC (as Mail::DKIM provides
support for DKIM).
Module will provide an XS wrapper for libopendmarc from opendmarc.org,
(my approach would be to package a Mail::DMARC::libopendmarc module
used my Mail::DMARC with some configuration switch) and possibly an
alternate pure Perl implementation not requiring libopendmarc (which
might be embedded in the Mail::DMARC module itself or with a
Mail::DMARC::pure separated module).

It's been a long time since I last worked on a module as an author, so
any comments on naming or - for that matter - anything else will be
grealy appreciated.



Both the name and the plan sound reasonable to me.

jimk

Re: Please help me name my text template module... or else!

[James E Keenan]

On 10/8/12 5:03 PM, Brian Katzung wrote:

... or else we'll all have to live with my name for it. :-)

I tried posting on comp.lang.perl.modules (I forgot which how-to doc
suggested it) when naming Data::XHash and got zero feedback.

Since the Pause naming article suggests modu...@perl.org and
module-authors@perl.org, I hope I've got the best places now. (If not,
where should I be asking these days?)

My "yet another text template module" has these as some major design goals:

* Absolutely bare-bones syntax (it is my hope that even non-programmer
users (with some limited training) can edit templates)
* "String-sized" templates (like "useful and still fits in a
varchar(255)")
* Control over maximum text length and number of template "steps"
executed in order to prevent accidental or malicious
denial-of-service attacks



Well, at the risk of making "yet another suggestion" for how to get 
feedback, let me ask:  Have you posted your code on github or a similar 
site?  Or could you make available the SYNOPSIS and DESCRIPTION part of 
the POD?



It is content agnostic, and initially targeted toward application
message localization, but there is nothing that makes it specific to
that use. I plan on using it in a CMS system I have in mind, but there's
nothing that makes it specific to that either. It's not a derivative of
another template system. (I searched CPAN for template-related stuff,
including Template::Toolkit and company, Text::Template, and
(HTML::)Mason and didn't see anything similar; if I missed another
similar package, I would love to hear about that too.)

I've been developing under "Text::TemplateLite" (for light-weight
syntax, size, and resource usage), but I realize it's yet another one of
those "Simple, Easy, Reduced, Tiny,..." names and I'm hoping someone can
share some specific wisdom rather than general guidelines.



It may turn out that Text::TemplateLite is the best available name.  But 
it would be nice to see a bit more before making a final recommendation.


(And names can always be changed.)

jimk

Re: Finance::OFX is missing

[James E Keenan]

On 12/31/11 10:39 PM, Brandon Fosdick wrote:

On Dec 30, 2011, at 19:39 , James E Keenan wrote:

On 12/30/11 2:00 PM, Brandon Fosdick wrote:

Well, it's sort of missing. It's still listed on search.cpan.org 
(http://search.cpan.org/~bfoz/Finance-OFX-2/lib/Finance/OFX.pm) but I got a 
report from a user that CPAN says that it's unavailable. I tried it myself and 
got:


Confirmed.  All I can suggest is to write: cpan at perl dot org.



Thanks. I'll give it a try.



I was able to see Finance-OFX-2 at that link tonight.  So it looks like 
we're okay.


jimk

Re: Hello PAUSE

[James E Keenan]

On 1/10/12 7:05 PM, Jed Lund wrote:

Hello all (again),

I think I may have made my first mistake by not suggesting a possible set
of names that I am considering in order to provide a place to start for
feedback from this distribution.


[snip]

For the DateTime::Format mashup I am considering.

DateTime::Format::Mashup::Shiras
DateTime::Format::Mashup::Shiras::Types



There is a perl-datetime mailing list 
(http://lists.perl.org/list/datetime.html) which is a better place to 
ask concerning naming of DateTime-related modules.  In particular, there 
is a policy (the details of which I can't remember at the moment) 
between those modules that should go into the basic DateTime namespace 
and those which should go into the extension namespace, DateTimeX.


Thank you very much.
Jim Keenan

Re: Finance::OFX is missing

[James E Keenan]

On 12/30/11 2:00 PM, Brandon Fosdick wrote:

Well, it's sort of missing. It's still listed on search.cpan.org 
(http://search.cpan.org/~bfoz/Finance-OFX-2/lib/Finance/OFX.pm) but I got a 
report from a user that CPAN says that it's unavailable. I tried it myself and 
got:




   The module Finance::OFX isn't available on CPAN.

   Either the module has not yet been uploaded to CPAN, or it is
   temporary unavailable. Please contact the author to find out
   more about the status. Try 'i Finance::OFX'.




Confirmed.  All I can suggest is to write: cpan at perl dot org.

Re: namespace check request

[James E Keenan]

Tim Esselens wrote:

Hi,

I have written a small perl module, and would like to include it on CPAN.

https://github.com/blaze-x/net-ldap-filter-sql

Am I using the correct namespace?
--
kind regards,
Tim Esselens



You're inheriting from Net::LDAP::Filter, so this looks okay to me.

jimk

Re: Which Build Module?

[James E Keenan]

David Cantrell wrote:


If EU::MM does the job easily, then use it.


Agreed.  In research I did on CPAN modules that contain XS, 
ExtUtils::MakeMaker was still used 10 times as often as Module::Build.


Granted, that largely reflects historical legacies.  But it also 
indicates that EU::MM is far from deprecated and is likely to be in use 
long into the future (FBOW).



Otherwise, consider Module::Build, but be aware that for a great many
users it will introduce an extra dependency, as it was not in core until
5.10.0.



You can install ExtUtils::ModuleMaker from CPAN and then use the 
'modulemaker' command-line utility to select either MakeMaker or 
Module::Build.


HTH

Jim Keenan

Re: Namespace request

[James E Keenan]

Ruslan N. Marchenko wrote:

Hi list,




For now it utilises root space FRA, however I understand that I need to
choose something more apropriate. I'm thinking on Net::Appliance::FRA or
Net::Appliance::Firewall...


I like Net::Appliance::*.  Net::Appliance::FRA is nice and short -- but 
for that same reason is not very self-documenting.  So I recommend 
something matching Net::Appliance::Firewall*


mis dos centavos

Jim Keenan

pause.perl.org: cert expired

[James E Keenan]

pause.perl.org
Issued by: CAcert Class 3 Root
Expires: May 10, 2012 6:18:36 PM EDT

Who should be notified?

Thank you very much.
Jim Keenan

Re: CPAN Testers, and {build,test}_requires.

[James E Keenan]

Daniel Pittman wrote:

G'day.





Oh, and finally, if anyone has any comments on the module — for all that it is
really about as trivial as a module can be and all — I would welcome them
publicly or privately.



Attempted to test version 1.1.

I note in your Makefile.PL, you have:

  'BUILD_REQUIRES' => {
'Carp' => '0',
'File::Find' => '0',
'File::Temp' => '0',
'Log::Any' => '0',
'Log::Any::Adapter' => '0',
...
  },
  'PREREQ_PM' => {
'File::Basename' => '0',
'Log::Any::Adapter::Base' => '0',
'Log::Any::Adapter::Util' => '0',
'Unix::Syslog' => '0'
  },

Without claiming to understand anything about Dist::Zilla, my gut 
reaction is that your settings are wrong.  Why are Log::Any and 
Log::Any::Adapter placed under BUILD_REQUIRES rather than PREREQ_PM?


Here's what I see in Log::Any::Adapter::Base:

package Log::Any::Adapter::Base;
use Log::Any;

My hunch is that you need Log::Any -- and none of the other Log::* 
modules -- in PREREQ_PM rather than in BUILD_REQUIRES.


jimk

Goodbye Perl6::Say

[James E Keenan]

Recently I had occasion to discuss with Damian Conway whether the 
continued presence of distribution Perl6::Say was still warranted.  We 
both agreed that it was time for this distro to retire to the backpan.


Perl6::Say was created by Damian in the early part of this decade as one 
of the first examples of how Perl 6 syntax could be backported into Perl 
5.  I recall Damian illustrating the use of its say() function in his 
closing talk at YAPC::NA::2003 in Boca Raton (was that the one about 24 
modules in 24 hours?).  The Perl6::Say distribution made its CPAN debut 
in March 2004; I became co-maintainer in July 2006.  It worked well on 
Perl 5.8 and somewhat well on Perl 5.6.2.


But with the release of Perl 5.10.0 in December 2007, Perl6::Say's days 
became numbered.  Why say Perl6::Say::say() when you can simply say 
say()?  It is my belief that, cet. par., you should always be using 
either the latest version of Perl 5 or the immediate preceding version, 
I felt that the release of Perl 5.12.0 would be an appropriate time to 
send the Perl6::Say CPAN distribution out to pasture.  Damian agreed, 
and so tonight I scheduled it for deletion via PAUSE.


If you'd like to visit Perl6::Say before it goes off into the shadows, 
please do so before Sunday at http://search.cpan.org/dist/Perl6-Say/.


Thank you very much.
Jim Keenan

Re: Registering a file as failed if it prompts for user input

[James E Keenan]

Ben Morrow wrote:

PERL_MM_USE_DEFAULT=1 perl Makefile.PL

Thanks for the suggestion, Ben.

It seems to work some of the time, but not all the time.

For example, the first time my program called 'perl Makefile.PL' for 
distribution 'F/FL/FLORA/Net-SSLeay', I got this:


$ perl Makefile.PL
Cannot determine perl version info from lib/Net/SSLeay.pm
Cannot determine license info from lib/Net/SSLeay.pm
*** Found OpenSSL-0.9.7l installed in /usr
*** Be sure to use the same compiler and options to compile your 
OpenSSL, perl,

and Net::SSLeay. Mixing and matching compilers is not supported.
Do you want to run external tests?
These tests *will* *fail* if you do not have network connectivity. [n]

... which would hang indefinitely in my automated environment.

When, however, I tried your suggestion, it DWIMmed:

$ PERL_MM_USE_DEFAULT=1 perl Makefile.PL *** Be sure to use the same compiler and options to compile your 
OpenSSL, perl,

and Net::SSLeay. Mixing and matching compilers is not supported.
Do you want to run external tests?
These tests *will* *fail* if you do not have network connectivity. [n] n
Checking if your kit is complete...
Looks good
Writing Makefile for Net::SSLeay


However, when I tried running it on G/GR/GRICHTER/HTML-Embperl, I got this:

$ PERL_MM_USE_DEFAULT=1 perl Makefile.PL Build with support for Apache mod_perl?(y/n) [y]Searching for Apache 
sources...

Look at ..
Look at ../src
Look at ./src
Apache source not found, enter path name or q to quit []Searching for 
Apache sources...

Look at
Look at /src
Look at ./src
Apache source not found, enter path name or q to quit []Searching for 
Apache sources...


... and so on indefinitely.

Registering a file as failed if it prompts for user input

[James E Keenan]

As part of our project to refactor ExtUtils::ParseXS, I am in the 
process of building functionality to identify CPAN distributions that 
contain .xs files and to run 'perl Makefile.PL && make' (or their 
Module::Build equivalents) on those distributions.


At this point in development, I only want to concern myself with 
distributions where Makefile.PL completes successfully and without user 
input.  I want the process of running the program to be as automated as 
possible; I don't want to have to respond to STDIN prompts during the 
course of a particular distribution's Makefile.PL.  In fact, I would 
like to treat distributions that prompt me for input as equivalent to 
exiting with non-zero exit codes.


Example:  If I am working with CPAN distribution 'Authen-Krb5-Admin', 
this happens:


  [Authen-Krb5-Admin-0.11] 547 $ perl Makefile.PL
  checking for Kerberos 5 prefix ... /usr
  checking for libk5crypto ... not found (using libcrypto)
  Authenticate as user/instan...@realm] for testing [jimk/admin]:

I don't want to do anything further with this distribution because at 
this point I want to exclude it from the list of distributions I'm going 
to use in my real project.  I want to treat it as if 'perl Makefile.PL' 
exited with a non-zero value.


Is there any way to accomplish this?

Thank you very much.
Jim Keenan

Re: Structure of a CPAN distribution: sample .pl files; .tar.gz for use in testing

[James E Keenan]

Jonathan Rockway wrote:

* On Sat, Feb 27 2010, Skriptke wrote:

I did a similar question recently:
http://www.nntp.perl.org/group/perl.module-authors/2010/02/msg8235.html

The conclusion: Add any library, etc.. to directory 'share'.  Use
install_share 'share'; of Module::Install; to install this.  Then used
File::sharedir to recover these files.


I don't think this is relevant to James' problem.  He seems to only want
files during testing, not after the module is installed.


Actually, the files in question are not needed during my own testing of 
the distribution or during 'make test'.  Since, their purpose is purely 
illustrative, they really count just as "extra documentation."




In that case:


Two questions related to the directory structure of a distribution
intended for CPAN:

1.  What is the current best practice for including sample Perl 5
programs intended to illustrate usage of the module?  What directory
should they be placed in?


I put them in examples/.  Unfortunately, search.cpan doesn't make any
effort to advertise this, so you will have to do it yourself.  ("Take a
look at the examples in "examples/".)


I will try this: an examples/ directory just under the top level.




2.  Is it possible to include another archive file in a CPAN
distribution and not have it interfere with the normal operations of
the distribution?


I have done this and have not seen any problems.  Tar is not recursive,
so you'll just have the tar.gz in the right place.  (Just make sure the
file isn't skipped in MANIFEST.SKIP; I usually have .tar.gz in mine.
"make manifest" and verify before "make dist", for maximum safety :)



Currently I have a .tar.gz in a directory called 't/testdata/'.  I will 
re-test this to make sure it DWIMs.  (I, too, usually have '.tar.gz' in 
my MANIFEST.SKIP and so I got burned on this at first.  I've since 
adjusted the MANIFEST.SKIP.)


Thanks, Skriptke and Jonathan.  I will report further results.

jimk

Structure of a CPAN distribution: sample .pl files; .tar.gz for use in testing

[James E Keenan]

Two questions related to the directory structure of a distribution 
intended for CPAN:


1.  What is the current best practice for including sample Perl 5 
programs intended to illustrate usage of the module?  What directory 
should they be placed in?


2.  Is it possible to include another archive file in a CPAN 
distribution and not have it interfere with the normal operations of the 
distribution?


Example:  I have a subroutine which has to gracefully handle certain 
.tar.gz files that have a non-standard directory structure.  I want this 
tarball to be available for use in my t/*.t tests, but I don't want it 
to be decompressed when a user says 'gunzip' or 'tar' (or when 'make' 
does something).

Re: how to mv files on PAUSE

[James E Keenan]

Bill Ward wrote:

On Mon, Feb 15, 2010 at 11:50 AM, Bill Weinman  wrote:


On 2010-02-15 11:52 AM, Bill Ward wrote:


I think you probably should just delete it and re-upload it.



That would have been my inclination -- but apparently it takes three days
to delete a file and in the mean time it wouldn't let me upload the same
file to a different location.

What I've done in that case is to slightly rename the file... e.g. by

adding a letter 'a' to the version number.  Sometimes I forget to update the
README or something.


Although that may have permitted you to do an immediate re-upload, I 
would argue that that's not the best course of action.  If I were 
browsing CPAN for the purpose of selecting a module, I wouldn't 
necessarily know how to interpret an 'a' in a version number.


Version numbers are difficult enough as it is without introducing more 
complications!




The 3-day thing seems a little overly cautions - I'd rather have it be

"delete immediately" and maybe have a 3-day "undelete" option, personally.
But in the long run 3 days doesn't take that long to pass.



I'm sure that CPAN veterans could give you the full rationale.   But the 
three-day policy has been in place for at least as long as I've been 
putting modules on CPAN (2002) and I've never had problems with it.


Thank you very much.
Jim Keenan

Re: problem building my Server-Control from CPAN - 98 "Use of uninitialized value" warnings

[James E Keenan]

Jonathan Swartz wrote:
I'm having a strange first-time problem building my new Server-Control 
distribution from CPAN on Fedora.


To reproduce this, I first run this reset script to remove 
Server-Control from my .cpan and system:



[snip]


   cpan[1]> install Server::Control
   CPAN: Storable loaded ok (v2.15)
   Going to read '/home/swartz/.cpan/sources/authors/01mailrc.txt.gz'
   ... [usual output]
   Server-Control-0.04/
   Server-Control-0.04/bin/
   Server-Control-0.04/bin/apachectlp
   ... [usual output]


I see that on CPAN you are now up to version 0.10.  Are you still 
experiencing this problem?

Re: Location of MyConfig.pm governing cpan configurations changed involuntarily

[James E Keenan]

David Cantrell wrote:



Does that not assume that you're using Apple's build of perl?



Apparently it's independent of which build of Perl you're using.  I 
build Perl from source, so 'which perl' is '/usr/local/bin/perl'. 
Nevertheless, my personal CPAN configuration in ~/.cpan/CPAN/MyConfig.pm 
is being ignored in favor of the "official" location.


jimk

Re: Location of MyConfig.pm governing cpan configurations changed involuntarily

[James E Keenan]

David Golden wrote:



So on OSX, if your .cpan directory is under ~/Library/Application\
Support/.cpan then you should probably customize CPAN's 'build_dir'
option to a path without spaces:


Which is what I did.  My build/ and sources/ directory remain under 
~/.cpan/; only CPAN/MyConfig.pm is in the File::HomeDir-dictated location.



[snip]

History of the issue is here:
http://rt.cpan.org/Public/Bug/Display.html?id=32841



I just read through that ticket.  I agree with a lot of what David 
Wheeler said in both his OP and later posts.  It's a PITA to have CPAN 
configuration, source, and build data in two different locations.  It's 
also very un-Unixish to have a wordspace in a path to hold user-selected 
data that does not pertain to a Mac GUI application, as distinct from 
vendor data.


Jim Keenan

Re: Location of MyConfig.pm governing cpan configurations changed involuntarily

[James E Keenan]

James E Keenan wrote:

[snip]
However, when I was using the 'cpan' shell yesterday, I found that it 
was no longer honoring configuration settings in 
~/.cpan/CPAN/MyConfig.pm.  Instead, it was reverting to settings found 
in the "vendor perl" location established when I got this iBook way back 
in May 2004:  ~/Library/Application\ Support/.cpan/CPAN/MyConfig.pm.  I 
knew that something was wrong when I started to see 'cpan' try to 
download files from mirrors listed in the 'vendor Perl' MyConfig.pm that 
have long since ceased to function.  Based on those settings, 'cpan' 
tried to 'make' modules with '/usr/local/bin/make' -- but I don't have 
and 'make' in /usr/local/bin!


Can anyone diagnose this problem and tell me how I can once again govern 
my 'cpan' shell configuration from ~/.cpan/CPAN/MyConfig.pm?




Before this post made it to the list yesterday, I had off-list 
discussion with Michael Schwern and David Golden.  Both inquired whether 
I had done an update to File::HomeDir lately -- and File::HomeDir proved 
to be the culprit (not CPAN.pm or Perl 5.10.1).


I know that for several years Adam Kennedy has been attempting to 
provide more rigorous, OS-specific definitions of 'home directory' in 
File::HomeDir.  As part of that effort, he had discussions with Chris 
Nandor re the best definition of homedir on Mac OS.  The result is that, 
for the time being, at least, the official location for CPAN 
configuration data on Mac OS is indeed ~/Library/Application\ 
Support/.cpan/CPAN/MyConfig.pm.


On Sept 7 I installed Catalyst on my iBook.  Catalyst is one of those 
distributions which pulls in half of the CPAN; the latest File::HomeDir 
and Mac::Carbon came in the wash.  That involuntary and unannounced 
redefinition of the concept of homedir on my Mac led to my bad 
experience using the 'cpan' shell for the first time after that date.


Jim Keenan

Location of MyConfig.pm governing cpan configurations changed involuntarily

[James E Keenan]

I experienced a problem yesterday which recalls the 'cpan' usage problem 
 described in this group on Sept 11 by Shawn H Corey 
(http://www.nntp.perl.org/group/perl.module-authors/2009/09/msg7854.html). 
 Yesterday I was using the 'cpan' shell for the first time in a couple 
of months on my laptop.  The laptop is Mac OS X 10.4.11/PPC.


Since at least November 2006 I have governed my CPAN configurations by 
changing values in ~/.cpan/CPAN/MyConfig.pm.  (I can testify to that 
date because during that month's Chicago Perl Hackathon, Michael 
Schwern++ made some adjustments to that MyConfig.pm that greatly 
improved my 'cpan' shell usage experience!)


However, when I was using the 'cpan' shell yesterday, I found that it 
was no longer honoring configuration settings in 
~/.cpan/CPAN/MyConfig.pm.  Instead, it was reverting to settings found 
in the "vendor perl" location established when I got this iBook way back 
in May 2004:  ~/Library/Application\ Support/.cpan/CPAN/MyConfig.pm.  I 
knew that something was wrong when I started to see 'cpan' try to 
download files from mirrors listed in the 'vendor Perl' MyConfig.pm that 
have long since ceased to function.  Based on those settings, 'cpan' 
tried to 'make' modules with '/usr/local/bin/make' -- but I don't have 
and 'make' in /usr/local/bin!


Consulting the POD for CPAN.pm, I tried to run the 'mkmyconfig' program 
in the 'cpan' shell.  (This was the first I had heard of 'mkmyconfig'.) 
 But it stored that configuration in the 'vendor perl' location -- not 
in ~/.cpan/CPAN/.


I was reduced to diff-ing the two versions of MyConfig.pm, then manually 
updating that in the 'vendor perl' location with my 'urllist' and other 
settings from the other location.   But I really don't want to do this, 
because I never want to poke into ~/Library files.  (I never want to 
edit a file with a wordspace in its path!)


I have always resisted the temptation to directly update CPAN.pm.  I 
have no record of such an update in ~/.cpan/build/.  However, I *did* 
update to Perl 5.10.1 by building it from source on the day it debuted 
last month.  I suspect that an updated version of CPAN.pm came in 
therewith, as I'm now at $CPAN::VERSION = '1.9402';.


Can anyone diagnose this problem and tell me how I can once again govern 
my 'cpan' shell configuration from ~/.cpan/CPAN/MyConfig.pm?


Thank you very much.
Jim Keenan

Re: Anyone want to adopt Getopt::Auto?

[James E Keenan]

Aristotle Pagaltzis wrote:

* Aristotle Pagaltzis  [2009-06-18 04:25]:

I even delayed writing this note, thinking I’d get around to
making my changes available, but they’re insubstantial and
unfinished and it really doesn’t matter any more.




I see from another thread that this module was recently adopted by 
Geoffrey Leach.

Re: Anyone want to adopt Getopt::Auto?

[James E Keenan]

Aristotle Pagaltzis wrote:

* Aristotle Pagaltzis  [2009-06-18 04:25]:

I even delayed writing this note, thinking I’d get around to
making my changes available, but they’re insubstantial and
unfinished and it really doesn’t matter any more.


Actually, http://github.com/ap/Getopt--Auto has my work now. 


What commands should a git noob use to access/download this from github?

Re: Name space for provisional astronomical objects

[James E Keenan]

Alan Barclay wrote:

I've got a new module I'd like to publish.
[snip]

I'd suggest Astro::ID::Provisional as a namespace.  Astro already
exists, but ID doesn't. There are however other identifiers used in
astronomy, so adding in Provisional makes sense.




Go for it.

Re: Fwd: Data-Structure-Util fails tests on 5.10.0

[James E Keenan]

Andy Armstrong wrote:
As Nick explains Fotango no longer exist. 


Sad ... but it makes all those orange Fotango pens I collected at past 
YAPCs very valuable!

Re: Should I include second-order dependencies in Makefile.PL?

[James E Keenan]

Chris Dolan wrote:

On Jun 5, 2007, at 8:00 PM, Andy Lester wrote:



Yes.  Second-order dependencies are beyond your control.  You will 
have false dependencies when an underlying module changes.


Say that Mech has dependency on HTML::Wango, which in turn has a 
dependency on Test::Tango.  So my dependencies are listed as


HTML::Wango => 1.00,
Test::Tango => 1.00,

SCENARIO 1: The maintainer of Foo::Wango decides that Test::Tango is 
unnecessary, and does without it.  He released HTML::Wango 1.02.  
Someone installing Mech must now install HTML::Wango and Test::Tango, 
although NOTHING in the chain requires Test::Tango.

 [snip]



Still, scenario 1 is the killer.


SCENARIO 3: Combine 1 & 2.



The CPAN.pm default is "ask" and we 
know that most of the time most people just take defaults.  


Yes, I agree that Andy's first point is persuasive.  (I also agree with 
Chris that most people just accept the defaults.)


So I will include only the first-order dependencies in Makefile.PL.  But 
I will list the second-order dependencies in the README and in the POD.


Gentlemen, thanks for your rapid response!

jimk

Should I include second-order dependencies in Makefile.PL?

[James E Keenan]

I am preparing to take over maintenance of another CPAN contributor's 
distribution.  For argument's sake, let me generalize my problem. 
Suppose that the Makefile.PL includes the following key-value pair in 
WriteMakefile():



PREREQ_PM => {
'Alpha::Beta' => 0,
'Gamma::Delta' => 0,
'Epsilon::Zeta' => 0,
},

Let's stipulate that none of those prerequisites are core.  So when 
running the 'cpan' shell, my program will pause and print a message such as:


 Unsatisfied dependencies detected during 
[X/XY/XYZ-Takeover-Module-0.01.tar.gz] -

Alpha::Beta
Gamma::Delta
Epsilon::Zeta
Shall I follow them and prepend them to the queue
of modules we are processing right now? [yes] yes

I say yes and shift my attention elsewhere.  But wait!  What if 
Epsilon::Zeta also has dependencies on non-installed, non-core CPAN modules:


 Unsatisfied dependencies detected during 
[X/XY/XYZ-Epsilon-Zeta-0.01.tar.gz] -

Eta::Theta
Iota::Kappa
Shall I follow them and prepend them to the queue
of modules we are processing right now? [yes] yes

So I get a second pause.  And perhaps a third or a fourth.  I'd like to 
eliminate all pauses after the first.


Since it's likely that no one will have all the non-core prerequisites 
-- first-order *and* >first order -- on disk, I'd like to include all of 
them in the PREREQ_PM attribute to WriteMakefile().


Is there any reason *not* to do so?

Thank you very much.
Jim Keenan

Re: peer review for first CPAN module? (JavaScript minification)

[James E Keenan]

Peter Michaux wrote:

Hi,

I'm writing a new version of JavaScript::Minification on CPAN. This is
my first CPAN module and first Perl project! If someone is willing to
take a look to see if I've done something terribly wrong packaging the
code I would greatly appreciate any feedback.

Currently the new module is in a subversion repository. If you have
subversion you should be able to check it out and test it with

svn co http://dev.michaux.ca/svn/random/JavaScript-Minifier
cd JavaScript-Minifier
perl MakeFile.PL
make test


1.  Makefile.PL:  Do you really need to use Perl version 5.008006 to use 
this module?  Why won't just 5.8, or 5.6 do?


2.  README:  Replace boilerplate content.

3.  POD:  section on EXPORT should indicate which subs/variables are 
exportable on demand.


4.  See attached for test coverage.  Quite good for a first effort, and 
better than most CPAN distros.  However, the excessive, C-ish use of || 
conditions mentioned by Adriano lowers your condition coverage and means 
your code is actually less well tested than it may first appear.


5.  This is perfectly acceptable for a 0.01.  Go ahead and upload it to 
CPAN so that others have easier access to it and can send you patches.


Thank you very much.
Jim Keenan
Reading database from /Users/jimk/work/jsm/cover_db


 -- -- -- -- -- -- --
File   stmt   bran   condsubpod   time  total
 -- -- -- -- -- -- --
...ib/JavaScript/Minifier.pm   97.3   88.8   79.0  100.00.0  100.0   83.9
Total  97.3   88.8   79.0  100.00.0  100.0   83.9
 -- -- -- -- -- -- --


Run:  t/JavaScript-Minifier.t
Perl version: 5.8.8
OS:   darwin
Start:Thu May 24 23:02:16 2007
Finish:   Thu May 24 23:02:16 2007

blib/lib/JavaScript/Minifier.pm

line  err   stmt   bran   condsubpod   time   code
1 package 
JavaScript::Minifier;
2 
3  1119   use strict;
   1  4   
   1 24   
4  1122   use warnings;
   1  3   
   1 20   
5 
6 require Exporter;
7 our @ISA = qw(Exporter);
8 our @EXPORT_OK = 
qw(minify);
9 
10our $VERSION = '1.0';
11
12# 
-
13
14sub isAlphanum {
15***327  327  0974 my $x = shift;
16  #return true if the 
character is allowed in identifier.
17   327   10017422 return (($x ge 'a' && 
$x le 'z') || ($x ge '0' && $x le '9') ||
   100
   100
   100
   100
  ***   66
  ***   66
  ***   66
  ***   66
18  ($x ge 'A' && 
$x le 'Z') || $x eq '_' || $x eq '$' ||
19  $x eq '\\' || 
ord($x) > 126);
20}
21
22sub isSpace {
23***   2067 2067  0  13590 my $x = shift;
24***   20676631917 return ($x eq ' ' || $x 
eq "\t");
25}
26
27sub isEndspace {
28***   2069 2069  0   5538 my $x = shift;
29***   20696651764 return ($x eq "\n" || 
$x eq "\r" || $x eq "\f");
  ***   66
30

Re: Modules are missing on CPAN

[James E Keenan]

Andy Lester wrote:
At first I thought I might have deleted two revisions of WWW::Mechanize 
by mistake, but it's not just Mech:  SOAP::Lite is missing revisions.


http://search.cpan.org/dist/SOAP-Lite/ only shows SOAP::Lite up to 
0.60a, but I know for a fact that there's been a 0.67.


http://search.cpan.org/dist/WWW-Mechanize/ shows 1.29_01 that I uploaded 
earlier in the week, but 1.26 has disappeared.


A v1.26 of WWW-Mechanize definitely *was* present on CPAN, because as 
recently as May 19 it was getting tested:

http://www.nntp.perl.org/group/perl.cpan.testers/2007/05/msg490290.html

Re: Modules are missing on CPAN

[James E Keenan]

Andy Lester wrote:



http://search.cpan.org/dist/WWW-Mechanize/ shows 1.29_01 that I uploaded 
earlier in the week, but 1.26 has disappeared.


Different mirrors have different sets of modules.  For example:

* http://mirrors.ibiblio.org/pub/mirrors/CPAN/authors/id/P/PE/PETDANCE/
  shows 1.24 and 1.29_01


I see those two versions of WWW::Mechanize -- but no 1.26 -- at:
http://search.cpan.org/~petdance/WWW-Mechanize-1.29_01/
and at
http://www.cpan.org/modules/by-module/WWW/PETDANCE/

Re: CPAN::Porters

[James E Keenan]

Gabor Szabo wrote:

Hi,





What do you think?

Gabor



I think that is a good idea whose success, in practical terms, will 
depend on whether you can recruit people to the project who are expert 
in preparing binary packages for a specific OS.  To guide/coach people 
to prepare RPMs, for example, there needs to be at least one person who 
has done that before and done it well.  (Note:  I don't have any 
experience in this area.  Any RPMs or .debs or my CPAN modules are other 
people's work.)


In other words, the human problem comes first.

jimk

Re: META.yml not being refreshed

[James E Keenan]

Ken Williams wrote:






And will that solve the problem?  What caused the problem in the first 
place?


No idea, but if it's EU::MM that's supposed to be writing it and it's 
not writing it, it must be an EU::MM bug.  Or maybe a configuration 
problem.




This is what I did tonight:

1.  Upgrade to most recent version of ExtUtils::MakeMaker (6.32).
2.  Went thru the perl Makefile.PL-make-make install-make dist cycle in 
two of the sandbox directories where I develop my CPAN modules.  An 
older META.yml file was present in one of these sandboxes (for 
File-Save-Home) but I had deleted the META.yml file that once was in the 
other sandbox (for Perl6-Say).
3.  Observation:  'make dist' creates the META.yml file *in the tarball* 
and then adds it to MANIFEST -- but it does *not* create the META.yml 
file *in the sandbox*.  The older META.yml file for File-Save-Home was 
left untouched; no META.yml file was created in Perl6-Say's sandbox. 
But when I unpacked the tarball, I found META.yml in each -- and in a 
newer format than the older tarball.


So I conclude that at some point in the past I must have unpacked a 
tarball into a sandbox, thereby depositing a META.yml file there.


So, it's 'make dist's job to make the META.yml file.  Good; then I don't 
have to worry about it.


Thanks for looking into this.
Jim Keenan

Re: Who controls svn.perl.org?

[James E Keenan]

Jerry D. Hedden wrote:

Jerry D. Hedden wrote:


Who do I need to contact to get access permission on
svn.perl.org so I can add the 'threads' and
'threads::shared' modules to it?



Andy Lester wrote:


I recommend using Google Code hosting at code.google.com
instead.   Setup is trivial, as is adding people to the
project.  Both of those require human intervention if you
host it on svn.perl.org.



For my own modules, I might consider it, but for core
modules, I feel they should go somewhere more 'official'.



Jerry:  When we revived the Phalanx Phoenix project in NYC, I had 
exactly the same questions as you -- and logically so, because we used 
svn.perl.org in the first phase of Phalanx in 2004-05.


But Andy and Robert Spier persuaded me to look at Google Code, and 
that's where we went.  It takes the burden of playing 'svnadmin' off 
both you and qw{Ask Robert}.


And, of course, for non-core modules, *all* repositories are unofficial, 
because we don't mandate development through a single repository.  Our 
only real repository is CPAN.


jimk

Re: James Freeman's other modules (was: Re: CGI::Simple)

[James E Keenan]

Fergal Daly wrote:


Changing the subject from Keenan to Freeman (James Keenan is not MIA),



Yes, the reports of my demise are quite premature.

Ironically, today we had the first meeting of Perl Seminar NY's Phalanx 
Phoenix project (http://www.perlmonks.org/index.pl?node_id=586406), 
whose explicit purpose is to train new maintainers of CPAN modules.


And thereby reduce the number of Perl modules abandoned in the future!

jimk

Re: no contact with author

[James E Keenan]

Eric Wilhelm wrote:

# from Darek Dwornikowski
# on Tuesday 02 January 2007 09:49 am:



i wrote to him twice, trying different emails. his personal webpage is
dead too.. I do not want to take over, I thought I could contact him
trough this list.



File a bug in rt?  


This is a good suggestion and should be followed by anyone who is having 
trouble contacting a module's author or last maintainer.  It documents 
your specific objective in trying to reach the author.  Should the 
module's maintainership ultimately need to be transferred, it provides 
documentation that the people at modules@perl.org can use to make an 
informed decision.


jimk

Re: List::RewriteElements

[James E Keenan]

James E Keenan wrote:




CPAN appears to be having some problem accepting uploads right now.  You 
can find v0.06 at 
http://thenceforward.net/perl/modules/List-RewriteElements/List-RewriteElements-0.06.tar.gz 






The CPAN hiccups cleared up after a couple of hours, so you can now get 
List-RewriteElements's latest version from CPAN.

Re: List::RewriteElements

[James E Keenan]

James E Keenan wrote:




I've just uploaded v0.06 to CPAN.  


CPAN appears to be having some problem accepting uploads right now.  You 
can find v0.06 at 
http://thenceforward.net/perl/modules/List-RewriteElements/List-RewriteElements-0.06.tar.gz


jimk

Re: List::RewriteElements

[James E Keenan]

Andy Armstrong wrote:


On 15 Dec 2006, at 21:39, David Landgren wrote:

I vote for Transform. Possibly more Data than List but I wouldn't  
argue it for long.



List:: has the connotation doing things to Perl arrays I think.



In Perl an array is a data structure which can hold a list, where a list 
is understood as an ordered set of elements.


While an array is the most frequently used way of holding and 
manipulating a list, it's often just a means to an end.  The result of 
that manipulation may or may not be -- or be represented by -- a Perl array.


In the case of List::RewriteElements, the result of the rewriting of a 
particular element in a list is immediately printed to STDOUT or to a 
file.  It is not held in an array.


So, while List::RewriteElements can certainly be used to transform 
elements of an array, a module name like 'Array::RewriteElements' would 
be overly narrow.


I suspect that people will most frequently use this module to transform 
data records held in a flat file, in which case we treat the individual 
records within the file as elements of a list.


jimk

Re: List::RewriteElements

[James E Keenan]

David Landgren wrote:




Question: (?:how)? does your module deal with positional records (that 
is, fixed width fields)? as opposed to delimited records?




Contradicting my earlier doubts about this, List::RewriteElements does 
can be used to rewrite elements of fixed-width records.


I've just uploaded v0.06 to CPAN.  The FAQ provides an example of such 
use and t/07_fixed_width.t tests the functionality.  Thanks for the 
suggestion, David!


jimk

Re: List::RewriteElements

[James E Keenan]

James E Keenan wrote:


David Landgren wrote:






Question: (?:how)? does your module deal with positional records (that 
is, fixed width fields)? 



It doesn't (at least not yet).


I think I'm wrong.

Thinking a bit more about the code, I suspect there's no inherent reason 
it can't handle fixed-width records.


I'm going to re-read Chapter 7.1 of Dave Cross' "Data Munging with Perl" 
and see what I can come up with.


jimk

Re: List::RewriteElements

[James E Keenan]

David Landgren wrote:

James E Keenan did write:

I am preparing a module for CPAN tentatively titled 
List::RewriteElements.  Given a list of data records, typically in the 
form of a flat file, optionally containing a header row, I am 
frequently asked to generate a new file in which each record is 
transformed according to some rule or deleted according to some 
criterion.  This module makes it easier for me to do so.



oooh, me too. I wish you had published this two months ago, because 
that's all I've been doing recently.




And, oooh, I wish you had gotten back to me two days ago.  I finally 
finished all the tests, docs, etc., and since I hadn't had any other 
feedback, I went ahead and uploaded it to CPAN under the name 
List::RewriteElements.  http://search.cpan.org/dist/List-RewriteElements/



[snip]


Question: (?:how)? does your module deal with positional records (that 
is, fixed width fields)? 


It doesn't (at least not yet -- to quote Andy, "patches welcome"). 
That's only because I have to deal with delimited records far more than 
fixed widths.


Perhaps in a future version!  Thanks for taking a look at it.

jimk

Re: Phalanx Phoenix: Mentored Maintenance of CPAN Modules

[James E Keenan]

James E Keenan wrote:
  We

would like to begin our F2F sessions in January 2006.


No, we're actually aiming for January 2007!

jimk

Phalanx Phoenix: Mentored Maintenance of CPAN Modules

[James E Keenan]

Perl Seminar New York, sponsor of monthly technical meetings in New York 
City since 2000 (http://tech.groups.yahoo.com/group/perlsemny/), 
announces the initiation of "Phalanx Phoenix:  Mentored Maintenance of 
CPAN Modules."


The original Phalanx project, initiated by Andy Lester 
(http://qa.perl.org/phalanx/), aimed at improving the code, testing and 
documentation of important, non-core Perl modules on CPAN.  A Perl 
Seminar NY team met in several sessions between January and June 2005 to 
"phalanx" (http://tinyurl.com/yku7jr) CPAN distributions Text-Template 
and HTML-Template.  We learned a tremendous amount about code 
maintenance and quality assurance -- and had a good time in our 
face-to-face collective hacking sessions.  We reported on our efforts at 
YAPC::NA::2005 in Toronto (http://hew.ca/yapc/phalanx/slides/index.html).


In the last year-and-a-half the Phalanx project has largely been 
dormant.  In part this was because the CPAN module authors on whose 
distributions the various Phalanx teams worked were not obliged to 
incorporate the teams' work into new versions of those CPAN distributions.


In that same time period, however, there has been more attention paid to 
the need to guarantee continued maintenance of CPAN distributions when 
their authors, due to changes in life circumstances, no longer can give 
them the maintenance attention they need 
(http://thenceforward.net/perl/yapc/YAPC-NA-2006/chicago.html).  The 
Perl community appears to lack a central place where CPAN authors who 
need to transfer maintenance responsibilities for their distributions 
can hook up with potential new maintainers.


Rising from the ashes like the storied Phoenix, the Perl Seminar NY's 
Phalanx project will address this problem via mentored maintenance of 
CPAN modules conducted in collective hacking sessions.  We seek to match 
up current CPAN authors/maintainers who need to transfer or share 
maintenance responsibilities with new CPAN participants who either can 
immediately assume maintenance or who can aim to do so when mentored by 
other current CPAN authors.


We are currently assembling a list of CPAN distributions whose authors 
are ready, willing and able to transfer or share maintenance 
responsibilities.  Once we have that list, each participating Perl 
Seminar NY member will pick a module to work on and develop a plan of 
work for that module.  We will discuss the plans of work face-to-face in 
collective hacking sessions conducted in a suitable location (e.g., 
http://www.drinkgoodstuff.com/ny/default.asp).  When the collective 
feels the plan is viable, we'll ask the current author/maintainer to 
sign the participant on as co-maintainer or to transfer primary 
maintenance responsibility outright.  The collective will then hold each 
participant to a high standard of quality in module maintenance.  We 
would like to begin our F2F sessions in January 2006.


We're conceiving of Phalanx Phoenix primarily as a collective hacking 
experience, so we view the face-to-face sessions as very important -- 
and also as the most fun!  But between sessions most of the work will be 
conducted online, so we don't want to exclude Perl hackers and would-be 
module maintainers who can't make our in-person sessions.


If you are a CPAN author who needs to share or transfer maintenance of a 
CPAN distribution, please email me (jkeen AT verizon DOT net) with the 
name of the distro.  Thank you very much.


Jim Keenan

Re: Give up your modules!

[James E Keenan]

David Golden wrote:




I want to endorse imacat on her contributions.  She runs one of the best 
smoke testers on cpan-testers: it's really strict and seems to catch 
lots of people out on subtle dependency problems.  She's also been very 
responsive to questions I've had about failed test reports.  These are 
contributions I value highly.





I second David's remarks.  When I was revising ExtUtils::ModuleMaker at 
this time last year, imacat's tests caught more, and more subtle, 
problems than anyone else's.  And I noted that in a talk I gave several 
times over the last year, including at YAPC in Chicago.


jimk

Re: Give up your modules!

[James E Keenan]

Ovid wrote:
> Hi all,
> 
> No names, but if you happen to be sitting on a module which other people 
> depend on and you're not going to fix bugs, give up the module, offer someone 
> co-maintainership or figure out *something* which gives users a way out. I 
> realize that not everyone has a pile of free time to constantly upgrade and 
> maintain modules, but if it's something widely used and you don't have time 
> for it, isn't the responsible thing to find a way to get those bug fixes out 
> there? 
> Cheers,
> Ovid
> 

This bears upon issues I discussed in a presentation at YAPC::NA::2006
in Chicago the month before last
(http://thenceforward.net/perl/yapc/YAPC-NA-2006/chicago.html).

In the subsequent discussion, people suggested that we need the following:

1.  Place for current module authors/maintainers who wish to transfer
maintenance of certain modules to so indicate.

2.  Place for people who are willing to take over maintenance of CPAN
modules to so indicate.

3.  (And this is the delicate part ...)  A way to encourage
authors/maintainers whose code needs transfer to a new maintainer to
effect that.

My hunch is that if we get (1) and (2) up and working, it will be easier
to accomplish (3).

jimk

Re: Test-time dependencies.

[James E Keenan]

Dmitri Tikhonov wrote:
> Dear fellow Perl module authors:
> 
> I have a test suite for my distribution (RT-Client-REST) that requires
> some modules that the module itself does not require (Test::Exception,
> for example).  Since it is not listed as a dependency, some people's
> tests fail[1,2].
> 
> Question: is it a good idea to put Test::Exception in as a dependency?
> My problem with this is that the module itself, once installed, does
> not use Test::Exception, so it is not really a dependency.  On the other
> hand, I want all tests to run (most of them test exceptions), so I do
> not want to 'skip' any tests.
> 

I've taken a number of approaches to this question:

1.  Include distributions in the PREREQ_PM key in Makefile.PL, which
forces installation just as it would for modules needed for the .pm files.

2.  Include the needed modules (or just enough of them as are needed for
the testing to work) under a t/lib/ or t/testlib/ directory.

3.  Put the individual tests which need the modules inside SKIP blocks.

Other people -- who are more fluent in writing Makefiles than I -- have
taken this approach:

4.  Do #3 above, but write Makefile.PL such that it prompts the user to
install the needed modules.

#3 is my current practice.  TMTOWTDI.

Jim Keenan

Re: Module maintainers: What have you experienced?

[James E Keenan]

James E Keenan wrote:
Last week I mentioned 
(http://www.nntp.perl.org/group/perl.module-authors/4576) that I will be 
leading a discussion at YAPC in Chicago on the process of taking over 
maintenance of CPAN modules.  This will be based partly on my own
experiences in taking over maintenance of ExtUtils::ModuleMaker from 
Geoff Avery, and partly on the responses I got from a survey letter I 
sent to about a dozen CPAN module maintainers earlier this month.




The presentation was well received.  It reflected the experiences of 
about a dozen other Perl programmers doing maintenance on about 17 
different distributions.  I am grateful for all who responded to the survey.


You can read the text or get a tarball of the slideshow here:
http://thenceforward.net/perl/yapc/YAPC-NA-2006/

jimk

Re: What to do about abandoned / unmaintained CPAN code?

[James E Keenan]

Linda W wrote:


I was going through the Win:: modules and wanted to try a few, but
got stuck when a basic one failed to work:
Win32::API (http://cpan.uwinnipeg.ca/dist/Win32-API).
[snip]
 So what is the procedure for dealing with abandoned modules?  Are
they put up for adoption or what?
-linda



Google the archives of this list for postings by brian d foy.  You'll 
get a feeling for how the PAUSE administrators deal with this problem. 
If you are willing and able to assume maintenance of some of that 
author's modules, please follow brian's suggestions about posting on 
modules@perl.org (which is different from this list), use.perl.org, etc.


I will be speaking at YAPC::NA::2006 in Chicago on the experiences of 
myself and others who have taken over maintenance of CPAN distributions 
from their authors or previous maintainers.  I hope that that 
presentation will focus attention on this issue.


Jim Keenan

Module maintainers: What have you experienced?

[James E Keenan]

Last week I mentioned 
(http://www.nntp.perl.org/group/perl.module-authors/4576) that I will be 
leading a discussion at YAPC in Chicago on the process of taking over 
maintenance of CPAN modules.  This will be based partly on my own 
experiences in taking over maintenance of ExtUtils::ModuleMaker from 
Geoff Avery, and partly on the responses I got from a survey letter I 
sent to about a dozen CPAN module maintainers earlier this month.


But why stop there?  My early sample was totally unscientific.  (In 
fact, I can't even remember how I drew it up.)  But if you would like to 
express your thoughts on this subject, you can view the questions at 
http://thenceforward.net/pipermail/module-maintainers/2006-May/02.html 
and respond as described therein.


Jim Keenan

Re: Devel::Timer, Jason Moore

[James E Keenan]

Jay Hannah wrote:

Jay Hannah wrote:


http://search.cpan.org/~jmoore/

Anyone have a way to contact Jason?



Bummer. The whois admin of sober.com doesn't know how to reach Jason 
either... Anyone else have any other ideas?


If not, thoughts on my adoption of Devel::Timer?




As part of preparation for a talk I'm giving at YAPC in Chicago, I've 
been interviewing people who've taken over maintenance of other people's 
CPAN modules.  In a recent similar case, the person who was submitting 
patches (a) posted the patches on rt.cpan.org and then (b) when the 
original author never responded, posted on [EMAIL PROTECTED]  The gurus 
of that list designated him co-maintainer in about a day's time. 
(Whether that is a general practice, I don't know, but it at least 
worked in this case.)


jimk

Re: Devel::Timer, Jason Moore

[James E Keenan]

Jay Hannah wrote:

Jay Hannah wrote:


http://search.cpan.org/~jmoore/

Anyone have a way to contact Jason?



Bummer. The whois admin of sober.com doesn't know how to reach Jason 
either... Anyone else have any other ideas?


If not, thoughts on my adoption of Devel::Timer?




As part of preparation for a talk I'm giving at YAPC in Chicago, I've 
been interviewing people who've taken over maintenance of other people's 
CPAN modules.  In a recent similar case, the person who was submitting 
patches (a) posted the patches on rt.cpan.org and then (b) when the 
original author never responded, posted on [EMAIL PROTECTED]  The gurus 
of that list designated him co-maintainer in about a day's time. 
(Whether that is a general practice, I don't know, but it at least 
worked in this case.)


jimk

Re: Module::Signature issues

[James E Keenan]

Robert Rothenberg wrote:


On 05/07/2006 02:34 PM Ken Williams wrote:



I've just re-released Pod::Readme without a signature, because the
signature problems are choking up Module::Build users.


Module::Build doesn't do anything with signatures - all it knows how to
do is generate a signature file when building a distribution.  I'd
suspect that the failures have more to do with the version of CPAN or
CPANPLUS users have.  Or if it's M::B in some way I don't understand, do
you have any error output?



It's CPAN/CPANPLUS, but M::B users are installing P::R


When I manually downloaded Pod-Readme-0.08 (which still included a 
SIGNATURE file), I got this error message:


[Downloads] 523 $ cd Pod-Readme-0.08
[Pod-Readme-0.08] 524 $ cpansign -v
Executing gpg --verify --batch --no-tty 
--keyserver=hkp://pgp.mit.edu:11371 
--keyserver-options=auto-key-retrieve SIGNATURE

gpg: Signature made Mon May  1 12:34:59 2006 EDT using RSA key ID BB72D9C5
gpg: requesting key BB72D9C5 from hkp server pgp.mit.edu
gpgkeys: key C5A2D18FBB72D9C5 not found on keyserver
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
gpg: Can't check signature: public key not found
==> BAD/TAMPERED signature detected! <==


Which is a signing problem ... but not the same signing problem I just 
reported in the case of Module-Build and PathTools.


jimk

Re: Module::Signature issues

[James E Keenan]

Ken Williams wrote:


On May 7, 2006, at 6:49 AM, Robert Rothenberg wrote:



I'm reminder of one other issue: there are Windows vs Unix end-of-line
issues that it sometimes chokes on.

I've just re-released Pod::Readme without a signature, because the  
signature

problems are choking up Module::Build users.



Module::Build doesn't do anything with signatures - all it knows how  to 
do is generate a signature file when building a distribution.  I'd  
suspect that the failures have more to do with the version of CPAN or  
CPANPLUS users have.  Or if it's M::B in some way I don't understand,  
do you have any error output?


 -Ken


Could the problem be in contacting the keyserver?

Just now I manually downloaded and unpacked Module-Build-0.28.  I 
followed the instructions in the SIGNATURE file (which, BTW, appears 
twice in the MANIFEST -- though apparently without causing error) and 
got this error message:


[Downloads] 508 $ cd Module-Build-0.28
[Module-Build-0.28] 510 $ cpansign -v
Executing gpg --verify --batch --no-tty 
--keyserver=hkp://pgp.mit.edu:11371 
--keyserver-options=auto-key-retrieve SIGNATURE

gpg: Signature made Fri Apr 28 00:14:21 2006 EDT using DSA key ID B7EF9476
gpg: requesting key B7EF9476 from hkp server pgp.mit.edu
gpg: keyserver timed out
gpg: Can't check signature: public key not found
==> BAD/TAMPERED signature detected! <==


I got the same results with PathTools:

[PathTools-3.18] 518 $ cpansign -v
Executing gpg --verify --batch --no-tty 
--keyserver=hkp://pgp.mit.edu:11371 
--keyserver-options=auto-key-retrieve SIGNATURE

gpg: Signature made Thu Apr 27 23:02:23 2006 EDT using DSA key ID B7EF9476
gpg: requesting key B7EF9476 from hkp server pgp.mit.edu
gpg: keyserver timed out
gpg: Can't check signature: public key not found
==> BAD/TAMPERED signature detected! <==


Since I wasn't attempting to install, these error messages were 
independent of the actual operation of CPAN.pm or the cpan shell.  But 
do they bear upon the problem I previously reported elsewhere and that 
RR's users seem to be experiencing?


Thanks.

jimk

Re: Module::Signature issues

[James E Keenan]

Robert Rothenberg (CPAN) wrote:


This is really frustrating. I'm not sure how to solve this, aside from
giving up on signing my CPAN uploads altogether.

That signature failures on automated CPAN Tester Reports show up as test
failures only reinforces this view.

I'm curious as to other authors' views on this.

What good are module signatures, anyway? 


Good question.  I've posted in a number of places that I repeatedly
experience failures in automated installation of modules via cpan
shell/CPAN.pm when the modules are signed -- even though those same
modules install perfectly well when I go through the manual process.
The threads in which I've posted this issue all peter out inconclusively
(unlike most threads based on my questions, which reach clear conclusions).

I don't claim to understand the security issues well.  I just know that
on my laptop I'm never successful in installing Module::Build,
PathTools, etc., with the cpan shell.

jimk

Re: Module::Signature issues

[James E Keenan]

Robert Rothenberg (CPAN) wrote:


This is really frustrating. I'm not sure how to solve this, aside from
giving up on signing my CPAN uploads altogether.

That signature failures on automated CPAN Tester Reports show up as test
failures only reinforces this view.

I'm curious as to other authors' views on this.

What good are module signatures, anyway? 


Good question.  I've posted in a number of places that I repeatedly 
experience failures in automated installation of modules via cpan 
shell/CPAN.pm when the modules are signed -- even though those same 
modules install perfectly well when I go through the manual process. 
The threads in which I've posted this issue all peter out inconclusively 
(unlike most threads based on my questions, which reach clear conclusions).


I don't claim to understand the security issues well.  I just know that 
on my laptop I'm never successful in installing Module::Build, 
PathTools, etc., with the cpan shell.


jimk

Re: RFC: Set-Gapfillers

[James E Keenan]

Flavio S. Glock wrote:

I'm not sure if it fills all requirements, but see also:
Set::Infinite
http://search.cpan.org/~fglock/Set-Infinite-0.61/lib/Set/Infinite.pm

- Flavio S. Glock

I've been giving further study to Set::Infinite.  I concede that I may 
not understand the documentation correctly, but it doesn't appear to DWIM.


My hunch is that the closest thing in Set::Infinite to what the proposed 
Set::Gapfillers does would be the 'minus' method.  Using some numbers 
taken from that method's example in the docs, I would call 
Set::Gapfillers as follows:


  $gf = Set::Gapfillers->new(
  lower   =>   7,
  upper   =>  20,
  sets=> [
  [  1,  4 ],
  [  8, 12 ],
  ],
  );

  $neededref = $gf->segments_needed();
  $gapfillref = $gf->gapfillers();
  $allsegref = $gf->all_segments();

  $Data::Dumper::Indent = 0;
  print "\n\nSet::Gapfillers::segments_needed\n";
  print Dumper ($neededref);

  print "\n\nSet::Gapfillers::gapfillers\n";
  print Dumper ($gapfillref);

  print "\n\nSet::Gapfillers::all_segments\n";
  print Dumper ($allsegref);
  print "\n";

... and I would get these results:

  Set::Gapfillers::segments_needed
  $VAR1 = [[7,7],[8,12],[13,20]];

  Set::Gapfillers::gapfillers
  $VAR1 = [[7,7],[13,20]];

  Set::Gapfillers::all_segments
  $VAR1 = [[7,7],[8,12],[13,20]];

Now let's plug the same numbers into Set::Infinite::minus:

  $set1 = new Set::Infinite( [ 1, 4 ], [ 8, 12 ] );
  $set2 = new Set::Infinite( [ 7, 20 ] );
  print "\nSet::Infinite::minus\n";
  print $set1->minus( $set2 );

I get these results:

  Set::Infinite::minus
  [1..4]

... which may be what this method is intended to do, but it's not what I 
 was looking for when I wrote Set::Gapfillers.


On Perlmonks (http://perlmonks.org/?node_id=539355), davidrw suggested 
an approach which, with the same numbers as above plugged in, would look 
like this:


  $lists = Set::Infinite->new([1,4], [8,12]);
  print "\n\nSet::Infinite::minus a la Perlmonks\n";
  print Set::Infinite->new([7,20])->minus($lists);

... which gives these results:

  Set::Infinite::minus a la Perlmonks
  [7..8),(12..20]

... which is *also* not what I want either.

So it appears that, at the very least, Set::Gapfillers and Set::Infinite 
are solving different problems ... which implies that there is room for 
both on CPAN (though I'm leaning to renaming it Set::Integer::Gapfillers 
to emphasize that integers are the only thing it's intended to work with).


Jim Keenan

Re: RFC: Set-Gapfillers

[James E Keenan]

Flavio S. Glock wrote:

I'm not sure if it fills all requirements, but see also:
Set::Infinite
http://search.cpan.org/~fglock/Set-Infinite-0.61/lib/Set/Infinite.pm

- Flavio S. Glock

Yes, I have looked into it, have already given it one mention in the SEE 
ALSO, and will look into it some more before releasing Set-Gapfillers. 
The latter is a more narrowly focused approach to solving one of the 
many problems which it appears Set-Infinite can tackle.  Thanks.

Re: RFC: Set-Gapfillers

[James E Keenan]

Terrence Brannon wrote:

On 4/9/06, James E Keenan <[EMAIL PROTECTED]> wrote:




  Set::Gapfillers - Fill in the gaps between integer ranges



What practical situation led to you needing this module? I'm curious.


Another Perl Seminar NY member and I have been working on a web 
application in which we parse web pages and make the parsed data 
available through a web interface.  The particular pages we are working 
with are identified by integers (e.g., 
http://www.nntp.perl.org/group/perl.jobs/4132).  We downloaded a few 
blocks of pages for testing purposes, then later needed a way to 
identify the blocks remaining for downloading -- the gapfillers.


I then realized that any solution I came up with was generalizable to 
any question concerning consecutive integers.  And so we have the basis 
for another CPAN distribution -- once we're sure it's named properly.


Jim Keenan

RFC: Set-Gapfillers

[James E Keenan]

I have created a module suitable for uploading to CPAN and request 
comments on its name.  Here is the first part of the documentation of 
what is currently called "Set-Gapfillers":


*

NAME
  Set::Gapfillers - Fill in the gaps between integer ranges

SYNOPSIS
  use Set::Gapfillers;
  $gf = Set::Gapfillers->new(
  lower   => -12,
  upper   =>  62,
  sets=> [
  [  1, 17 ], # Note:  Use comma, not
  [ 25, 42 ], # range operator (..)
  [ 44, 50 ],
  ],
  );

  $segments_needed_ref = $gf->segments_needed();

  $gapfillers_ref  = $gf->gapfillers();

  $all_segments_ref= $gf->all_segments();

  Any of the three preceding output methods can also be called with an 
"expand" option:


  $segments_needed_ref = $gf->segments_needed( expand => 1 );

DESCRIPTION
  This Perl extension provides methods which may be useful in 
manipulating sets whose elements are consecutive integers. Suppose that 
you are provided with the following non-intersecting, non-overlapping 
sets of consecutive integers:


  {  1 .. 17 }
  { 25 .. 42 }
  { 44 .. 50 }

  Suppose further that you are provided with the following lower and 
upper bounds to a range of consecutive integers:


  lower:  12
  upper:  62

  Provide a set of sets which:

  *   when joined together, would form a set of consecutive integers 
from the lower to the upper bound, inclusive; and


  *   are derived from:

  *   the sets provided;

  *   proper subsets thereof; or

  *   newly generated sets which fill in the gaps below, in between 
or above the provided sets.


*

Since the module deals exclusively with sets of consecutive integers, I 
could also see calling it "Set::Integer::Gapfillers".


Comments?

The full distribution can be obtained at: 
http://thenceforward.net/perl/modules/Set-Gapfillers-0.06.tar.gz


Thank you very much.

Jim Keenan

Re: OO list module

[James E Keenan]

Eric Wilhelm wrote:

# from James E Keenan
# on Sunday 26 February 2006 06:19 am:



I suspect you're mainly looking for feedback on
the interface, which I haven't really looked at yet.  



Yes, please.  The goal is primarily the interface.  


Fair enough.  I don't really understand reform() -- particularly:  what 
goes inside the code ref.  Is this how I would use it?


@a0 = qw(abel abel baker camera delta edward fargo golfer);
$l = L(@a0);
$reform = $l->reform( sub { return $_ } );

jimk

Re: OO list module

[James E Keenan]

Eric:

This looks promising.  I suspect you're mainly looking for feedback on 
the interface, which I haven't really looked at yet.  But in  testing it 
3 of the 4 test files were skipped.  Perhaps that's okay for a 
distribution in the experimental stage, but I know that it would give me 
pause if I were thinking about installing it from CPAN.


> [work] 502 $ svn checkout http://scratchcomputing.com/svn/list/trunk/ 
wilhelm

> A  wilhelm/t
> A  wilhelm/t/03-prereq.t

Checks out into Subversion nicely!
[snip]

> [work] 503 $ cd wilhelm

[snip]

> [wilhelm] 507 $ perl Build.PL
> Checking whether your kit is complete...
> Warning: the following files are missing in your kit:
> META.yml
> Please inform the author.
> Creating new 'Build' script for 'list' version '0.01'
> [wilhelm] 508 $ ./Build
> lib/list.pm -> blib/lib/list.pm
> Manifying blib/lib/list.pm -> blib/libdoc/list.3
> [wilhelm] 509 $ ./Build test
> t/00-loadok 1/1# Testing list 0.01 

> t/00-loadok 


> t/01-pod-coverageskipped
> all skipped: $ENV{TEST_POD_COVERAGE} is not set
> t/02-pod.skipped
> all skipped: $ENV{TEST_POD} is not set

Should a user really have to have these two environmental variables set 
in order to use this module?


> t/03-prereq..skipped
> all skipped: Test::Prereq::Build required to test dependencies
> All tests successful, 3 tests skipped.

> Files=4, Tests=1,  2 wallclock secs ( 0.73 cusr +  0.16 csys =  0.89 CPU)

And looking at the one test that does run ...

> [wilhelm] 510 $ prove -vb t/00-load.t
> t/00-load1..1
> ok 1 - use list;
> ok
> All tests successful.
> Files=1, Tests=1,  0 wallclock secs ( 0.10 cusr +  0.06 csys =  0.16 CPU)

... we see that the functionality is not yet tested.

jimk

Re: Why is module list not more up-to-date?

[James E Keenan]

Ricardo SIGNES wrote:



There's some sort of drive failure in the CPAN's master mirror.  Unfortunately,
it has not been written about here, yet:

  http://log.perl.org/


Thanks, Ricardo.  I was not previously aware of log.perl.org.

jimk

Why is module list not more up-to-date?

[James E Keenan]

Tonight I had occasion to check www.cpan.org's various pages. 
Specifically:  http://www.cpan.org/modules/01modules.index.html


I notice that the timestamp on this page says:

Fri Nov 18 22:56:49 2005 GMT

... 10 days ago.  And this appears to be the date that my CPAN.pm is 
using as a reference point.


My previous impression was that www.cpan.org would be more up-to-date 
than any other page such as search.cpan.org.  But the latter site lists 
distributions I've uploaded subsequent to Nov 18.


Can anyone say whether this is a temporary anomaly or, OTOH, the normal 
course of things?


Thank.

Re: When CPAN shell cannot find a module

[James E Keenan]

Randy Kobes wrote:

On Sun, 20 Nov 2005, James E Keenan wrote:






[snip]

Note that, if you know the distribtion you want to
install, CPAN.pm understands
  cpan> install KWILLIAMS/PathTools-3.14.tar.gz



That's the step I was looking for:  what to do once the 'i /somemodule/' 
command returns a results.  Thanks, Randy and Andreas.


jimk

When CPAN shell cannot find a module

[James E Keenan]

I'm wondering if my diagnosis of the following annoying problem is correct.

When I use the CPAN shell to install a distribution which does not 
include a package with the name of the distribution, the shell 
immediately tells me to use the 'i /distroname/' to find objects with 
matching identifiers.


If information on the distribution is located, then I have to guess as 
to which module within the distribution is one that I don't have 
up-to-date and which will therefore trigger the shell to proceed with 
installation.


Example:  Just now I saw on perl.cpan-testers that Ken Williams had 
uploaded a distribution named PathTools.  I checked it out at 
search.cpan.org and decided to install it.  Here is an edited transcript 
of my shell session:


# START from CPAN shell session #

cpan> install PathTools
CPAN: Storable loaded ok
Going to read /Users/jimk/.cpan/Metadata
  Database was generated on Fri, 18 Nov 2005 22:50:02 GMT
Warning: Cannot install PathTools, don't know what it is.
Try the command

i /PathTools/

to find objects with matching identifiers.

cpan> i/PathTools/
Unknown command 'i/PathTools/'. Type ? for help.

cpan> i /PathTools/
Distribution id = K/KW/KWILLIAMS/PathTools-3.14.tar.gz
CPAN_USERID  P5P (The Perl5 Porters Mailing List 
)
CONTAINSMODS File::Spec::Win32 File::Spec::Epoc File::Spec 
File::Spec::Unix File::Spec::OS2 File::Spec::VMS File::Spec::Functions 
File::Spec::Cygwin File::Spec::Mac Cwd


[1st guess:  File::Spec::VMS]

cpan> install File::Spec::VMS
File::Spec::VMS is up to date.

[Oops, that didn't work! ]

cpan> install File::Spec::Cygwin
File::Spec::Cygwin is up to date.

[Oops, that didn't work! ]

cpan> install File::Spec::Epoc
File::Spec::Epoc is up to date.

[I noticed that File::Spec's version is the same as that of this new 
PathTools -- 3.14 -- and decide to guess that. ]


cpan> install File::Spec

[Success at last! ]

Running install for module File::Spec
Running make for K/KW/KWILLIAMS/PathTools-3.14.tar.gz
CPAN: LWP::UserAgent loaded ok
Fetching with LWP:
  http://www.cpan.org/authors/id/K/KW/KWILLIAMS/PathTools-3.14.tar.gz
CPAN: Digest::MD5 loaded ok
Fetching with LWP:
  http://www.cpan.org/authors/id/K/KW/KWILLIAMS/CHECKSUMS
Checksum for 
/Users/jimk/.cpan/sources/authors/id/K/KW/KWILLIAMS/PathTools-3.14.tar.gz ok

Scanning cache /Users/jimk/.cpan/build for sizes
PathTools-3.14/
PathTools-3.14/Build.PL

[and everything is cool from here on]


# END from CPAN shell session #

So I eventually get the shell to work ... but I really don't see why it 
couldn't handle 'install PathTools' right from the get-go?


Anyone know why?  Is there a workaround?  Thanks.

Jim Keenan

Re: PPM "Fails" Question - What did I do wrong?

[James E Keenan]

On further analysis, I don't think your problems are due to some problem 
at ActiveState.  Games-Poker-HistoryParser-1.3 failed tests and threw 
many warnings when I tested it on Darwin.  See attachment.


jimk
Running make test
PERL_DL_NONLAZY=1 /usr/local/bin/perl "-MExtUtils::Command::MM" "-e" 
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/Commonok   
t/pod-coverage..ok 1/20# Games::Poker::HistoryParser::Output::XML: no 
public symbols defined
t/pod-coverage..ok   
t/pod...ok   
t/Sites.ok   
t/Sites_Party...ok 1/0Use of uninitialized value in substitution (s///) at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Sites/PartyPoker/FlopGames.pm
 line 388,  line 1.
Use of uninitialized value in join or string at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Sites/PartyPoker/FlopGames.pm
 line 389,  line 1.
Use of uninitialized value in join or string at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Sites/PartyPoker/FlopGames.pm
 line 389,  line 1.
t/Sites_Party...NOK 4
#   Failed test 'Output format - Dump'
#   in t/Sites_Party.t at line 36.
Use of uninitialized value in substitution (s///) at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Sites/PartyPoker/FlopGames.pm
 line 388,  line 1.
Use of uninitialized value in join or string at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Sites/PartyPoker/FlopGames.pm
 line 389,  line 1.
Use of uninitialized value in join or string at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Sites/PartyPoker/FlopGames.pm
 line 389,  line 1.
Use of uninitialized value in concatenation (.) or string at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Output/2P2.pm
 line 64,  line 1.
Use of uninitialized value in hash element at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Output/2P2.pm
 line 72,  line 1.
Use of uninitialized value in concatenation (.) or string at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Output/2P2.pm
 line 64,  line 1.
Use of uninitialized value in hash element at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Output/2P2.pm
 line 72,  line 1.
Use of uninitialized value in concatenation (.) or string at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Output/2P2.pm
 line 64,  line 1.
Use of uninitialized value in hash element at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Output/2P2.pm
 line 72,  line 1.
Use of uninitialized value in concatenation (.) or string at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Output/2P2.pm
 line 64,  line 1.
Use of uninitialized value in hash element at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Output/2P2.pm
 line 72,  line 1.
Use of uninitialized value in concatenation (.) or string at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Output/2P2.pm
 line 64,  line 1.
Use of uninitialized value in hash element at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Output/2P2.pm
 line 72,  line 1.
t/Sites_Party...NOK 5
#   Failed test 'Output format - 2P2'
#   in t/Sites_Party.t at line 37.
Use of uninitialized value in substitution (s///) at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Sites/PartyPoker/FlopGames.pm
 line 388,  line 1.
Use of uninitialized value in join or string at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Sites/PartyPoker/FlopGames.pm
 line 389,  line 1.
Use of uninitialized value in join or string at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Sites/PartyPoker/FlopGames.pm
 line 389,  line 1.
Use of uninitialized value in concatenation (.) or string at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Output/Text.pm
 line 62,  line 1.
Use of uninitialized value in concatenation (.) or string at 
/Users/jimk/.cpan/build/Games-Poker-HistoryParser-1.3/blib/lib/Games/Poker/HistoryParser/Output/Text.pm
 line 62,  line 1.
Use of uninitialized value in concatenation (.) or string at 
/Users/j

Re: PPM "Fails" Question - What did I do wrong?

[James E Keenan]

Troy Denkinger wrote:
I was looking around the ActiveState PPM repository today and I noticed 
that a module I released recently was reported as having failed on most, 
but not all, platforms.  I'd like this module to appear in the 
ActiveState repository, so I figure I better fix my code up.


My problem is that I don't really understand the error reported:

"Makefile out-of-date with respect to Makefile.PL"


I got this error yesterday when developing a module.  It caught the fact 
that I had made a slight change to Makefile.PL after my last call to 'make'.


I don't know that that explains why the ActiveState PPM build failed.  I 
do know that as that is a completely automated process, it's designed to 
report a FAIL for the slightest infraction.


Nothing to do but try again!

jimk

Re: Module abstract: Is its length still limited?

[James E Keenan]

Sam Vilain wrote:

On Mon, 2005-11-07 at 21:08 -0500, Ricardo SIGNES wrote:


* "Andreas J. Koenig" <[EMAIL PROTECTED]> [2005-11-07T17:29:50]


I will be very happy if you guys decide something and let me know.
I'll adjust the code for the forms on PAUSE then.


Here's my official vote:

(length $module_name + length $abstract + 3) should be under 80.

This means that the whole header and abstract will fit in one line.
That's more than 44 characters for short module names.  Longer module
names, which should be pretty descriptive, need shorter abstracts.

Wombat - a framework for building reusable fruit-counting applications
Application::Framework::FruitCounting - for reusable produce applications




My feeling is that this wouldn't really work when the module name gets
too long, for example when a namespace under which you are contributing
has chosen verbose terms.


I agree.  The maximum length of the abstract should be independent of 
the length of the module's name.


But I also like one aspect of Mark Stosberg's suggestion:  the 
truncation of overly long abstracts in space-constrained formats.  In 
the body of a module's documentation, I don't really care how long an 
abstract is.  If the author is foolish enough to write an overly long 
abstract, I'll simply ignore the module.


But where I do think ellipses should be used is in the tabular displays 
of search.cpan.org.  If, for example, the rule were formulated as "In 
search.cpan.org and other CPAN search engines, abstracts will be 
truncated starting after the 80th character," then -- going back to my 
original question -- I could revise ExtUtils::ModuleMaker to warn the 
user of the consequences of exceeding 80 characters (but not mandating 
that length, as EU::MM can be used for non-CPAN modules where the space 
constraint doesn't apply).


Jim Keenan

Re: Module abstract: Is its length still limited?

[James E Keenan]

Andreas J. Koenig wrote:


On Tue, 08 Nov 2005 10:41:27 +1300, Sam Vilain <[EMAIL PROTECTED]> said:



  > On Sun, 2005-11-06 at 07:51 +0100, Andreas J. Koenig wrote:
 >> > So, the question I would now ask:  How rigidly should I enforce the 
 >> > 44-character limit if I am guiding someone in the task of creating 
 >> > proper Perl modules?

 >> As the module list is dead, we cannot really argue in favor of 44
 >> characters except with the one argument of tradition/best practice. I
 >> believe when 3815 authos have managed to describe their modules in 44
 >> characters, then it should be doable for some other 3815000 modules
 >> too.

  > Yes, let's keep it short.  But how about increasing the limit to 60 or
  > so?  Many a time I would've liked an extra word or two.

 >> There's an old business advice that you shouldn't start an enterprize
 >> if you cannot describe its mission in a single sentence. I think its
 >> true for modules too.

  > There are very few sentences that fit in 44 characters.  60 characters I
  > think still honours this principle.

I will be very happy if you guys decide something and let me know.
I'll adjust the code for the forms on PAUSE then.

It's not clear to me which "guys" get to make this decision.  I don't 
know how the original 44-character limit came about.


IMHO, 44 characters is nowadays too short and 60 maybe too short as 
well.  I'd prefer to err on the side of generosity and say 100 
characters.  Or perhaps:  Only as many characters as will fit in one 
line in a typical browser at a default font size on the author's home 
page on CPAN (68-ish).  Or perhaps:  the magic 78 recommended by Damian 
for lines in text editors.  As you can see, this is largely a question 
of taste.


But this decision can be informed by empirical research.  Perhaps we 
should take a look at ABSTRACTs for distros written by very prolific 
CPAN contributors such as DCONWAY, AUTRIJUS, BDFOY, etc., and see what 
they have done in this regard, i.e., how long are their ABSTRACTs?

Re: Module abstract: Is its length still limited?

[James E Keenan]

A. Pagaltzis wrote:

* James E Keenan <[EMAIL PROTECTED]> [2005-11-05 13:35]:


Since the 44-character limit never applied to modules except
those intended for CPAN, and since it does not now appear to
apply to modules as they appear on search.cpan.org, I'm
inclined toward the latter approach.  Comments?



I’d favour three different warnings – one for “abstract too long
for CPAN”, one for “abstract is excessively long” (maybe at 200
chars or so?), and one for “abstract is missing”.

All advisory, though, no errors.

Thanks.  I'll probably incorporate some version of your and Ricardo's 
suggestions in the next version of ExtUtils::ModuleMaker.


jimk

Re: Module abstract: Is its length still limited?

[James E Keenan]

Andreas J. Koenig wrote:

On Mon, 05 Sep 2005 20:48:10 +1200, Sam Vilain <[EMAIL PROTECTED]> said:



  > This was probably for the sake of the text-only modules list, which has
  > since fallen out of maintenance.

But it's still relevant for the database table that is behind

https://pause.perl.org/pause/authenquery?ACTION=apply_mod

And that's the same table that produces CPAN/modules/03modlist.data.gz
which in turn is providing some data to CPAN.pm and CPANPLUS.pm

So, the question I would now ask:  How rigidly should I enforce the 
44-character limit if I am guiding someone in the task of creating 
proper Perl modules?


This question is relevant because I have taken over maintenance of 
ExtUtils::ModuleMaker and a bug has been reported which bears upon the 
44-character limit for ABSTRACTs 
(https://rt.cpan.org/NoAuth/Bug.html?id=15537).  At the current time 
modulemaker is throwing an error message when one exceeds the 
44-character limit ... but goes ahead anyway and creates a correct, 
CPAN-uploadable framework for a Perl extension.  I either have to 
enforce the limit or relax it and change the error message to an 
advisory warning.


Since the 44-character limit never applied to modules except those 
intended for CPAN, and since it does not now appear to apply to modules 
as they appear on search.cpan.org, I'm inclined toward the latter 
approach.  Comments?


jimk

Updates of ExtUtils::ModuleMaker, ExtUtils::ModuleMaker::PBP Now Available

[James E Keenan]

Version 0.43 of Perl extension ExtUtils::ModuleMaker is now available on 
CPAN (http://search.cpan.org/dist/ExtUtils-ModuleMaker/) as is version 
0.08 of ExtUtils::ModuleMaker::PBP 
(http://search.cpan.org/dist/ExtUtils-ModuleMaker-PBP/).


ExtUtils::ModuleMaker was created by Geoff Avery and is a replacement 
for the most typical use of the 'h2xs' utility bundled with all Perl 
distributions: the creation of the directories and files required for a 
pure-Perl module to be installable with 'make' and distributable on CPAN.


ExtUtils::ModuleMaker::PBP subclasses ExtUtils::ModuleMaker to create 
the same type of distribution framework as its parent, but in the style 
recommended by Damian Conway in "Perl Best Practices."


A more complete description of the new functionality provided by these 
extensions has been posted to comp.lang.perl.modules and may be viewed here:


http://tinyurl.com/8nflb

This description is also available at:

http://mysite.verizon.net/jkeen/perl/modules/ExtUtils-ModuleMaker/ANNOUNCE.html

I hope you find these new extensions useful.  Comments to jkeenan [at] 
cpan [dot] org.


Jim Keenan