Re: MetaCpan SEO
Hi!
On Wed, Nov 20, 2013 at 11:09:44AM +, Smylers wrote:
• Get a job at Google (they seem to always be recruiting).
• Join the search algorithm team.
• Enhance the algorithm to address the above.
That's the most interesting approach to SEO I've ever seen :-)
greetings,
domm
--
#!/usr/bin/perl http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
Hi!
On Tue, Sep 13, 2011 at 10:34:33PM +0200, Aristotle Pagaltzis wrote:
The only Google product I ever use if I can help it is their web
search, and then only because all of the competitors are next to
worthless in comparison. I wish someone were able to step up to
Google on that front.
http://duckduckgo.com/ seems quite nice. And it's written in Perl :-)
--
#!/usr/bin/perl http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Where should I put temp files for testing?
Hi!
On Tue, Apr 05, 2011 at 07:15:32AM +0300, Shlomi Fish wrote:
My inclination is to use FIle::Temp to create a temporary directory to hold
all the files and subdirectories I need and then clean this out when I'm
done. I just didn't know if there was a different or better common practice
in use by other module authors.
File::Temp sounds like a good idea for that.
++
I usually controll the CLEANUP parameter via some ENV setting:
my $cleanup = $ENV{NO_CLEANUP} ? 0 : 1;
my $dir = tempdir(CLEANUP = $cleanup);
If the test fails I can run it again:
NO_CLEANUP=1 prove -vl t/test_using_temp_dir.t
and take a look at the temp files created.
--
#!/usr/bin/perl http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Weekend entertainment
Hi!
On Sun, Nov 15, 2009 at 10:47:30AM -0500, David Golden wrote:
thoughts. I would rather see the author withdraw it voluntarily.
I would suggest renaming the dist to Acme::Lingua::NigerianSPAM, which
makes it clear that the author is not mocking the country and/or people
of Nigeria, but only the very annoying spammers who deserve all the
mocking they can get.
--
#!/usr/bin/perl http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Test Windows Build on Module
Hi!
On Mon, Aug 03, 2009 at 01:04:57PM -0400, Kartik Thakore wrote:
Can I get some windows testing to see if the build works?
maybe you can use this:
http://use.perl.org/~Alias/journal/39318
--
#!/usr/bin/perl http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
ShipIt or Module::Release or Dist::Zilla or ..
Hi!
While deploying a lot of custom but CPAN-style code today I once again
was bored by the mostly repetitive stuff I had to do (you know, update
Changes, bump the version, run the tests, blabla).
I was tempted to enhance the script we're using (which mostly does the
git-side of the process, i.e. tag the release and upload it to our
custom cpan), but on the other hand I knew that there are some things on
CPAN that should make this process easier. CPAN beeing CPAN, there are several
things available, and I couldn't find a quick overview about what's
$best
So, what would you choose to handle releasing of modules that use
Module::Build and git and follow the general CPAN dist best practices?
ShipIt doesn't like Module::Build, even though there's a patch available
(not applied for more than a year:
http://rt.cpan.org/Public/Bug/Display.html?id=33081
)
Module::Release doesn't seem to handle git
Dist::Zilla is more about managing a dist, not releasing it (and I don't
want to wait for the glorious future of Dist::Zilla :-)
Adam Kennedy seems to be working on similar things, but what exactly?
So. It seems there's nothing off the shelf that fits my needs. I
wouldn't mind contributing to one of the above projects (or to another
one..). But to which?
What do you use for taking the boring stuff out of module releases?
--
#!/usr/bin/perl http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Need help improving my Kwalitee
Hi!
On Mon, Jul 21, 2008 at 02:57:20PM -0700, Bill Ward wrote:
My module Number::Format has some red areas in its Kwalitee report
http://cpants.perl.org/dist/kwalitee/Number-Format
When I release 1.60, I tried to fix a lot of the kwalitee issues with
the previous version, 1.52. However, it appears that some of my
fixes didn't work. For example, my META.yml file was barebones in
1.52, and I wanted to bring it up to modern standards. I could not
find any tool that would help me generate it, so I cobbled one
together by hand using examples from other modules. Yet I still see
dings against the kwalitee there.
Maybe cpants_lint.pl (comes with Module::CPANTS::Anaylse) is helpfull.
Although I have to admit that there are some nasty bugs in cpants ATM,
and I'm still low on tuits. I will spend some time on cpants before
YAPC, though...
Also, how do I test the kwalitee without releasing a new version and
waiting for CPANTS to find it? I wish the CPANTS site had
instructions on how to install the Kwalitee code on my own box for
pre-release testing. I see a number of modules in CPAN that relate to
kwalitee but am not sure which one(s) I need.
Gabor recently asked me to write up how to set up a complete CPANTS
testing thingy (that tests all of CPAN). I've starte this, but it's
currently only available from svn:
http://code.google.com/p/cpants/source/browse/trunk/Module-CPANTS-ProcessCPAN/lib/Module/CPANTS/ProcessCPAN.pm
--
#!/usr/bin/perl http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Fwd: New CPANTS metrics
Hi!
Uh, wow, why do CPANTS discussions always start when I'm low on tuits...
A lot of your issues have already been addressed, and as my time is
short ATM, I'll only awnser some of the remaining
extracts_nicely: How much of a problem is this, really?
A lot of people hate tarballs/zip-files that spew their content into the
current dir. Especially if the offending dists contains lots of files.
Or a file with the same name as one you had in the dir...
has_buildtool: How many CPAN modules does this even apply to?
185
http://cpants.perl.org/dist/shortcoming?metric=has_buildtool
has_working_buildtool: ditto
326
http://cpants.perl.org/dist/shortcoming?metric=has_working_buildtool
This metric was introduced to list dist that come with outdated versions
of Module::Install. It might of course be extended to problems in other
buildtools (say, if MakeMaker becomes deprectated)
metayml_conforms_to_known_spec: valid metric; how useful is this, though?
metayml_is_parsable: Isn't this redundant to conforms to known spec?
well, something might be parsable, but not conformant.
metayml_conforms_spec_current: Yeah, whatever.
Yeah, whatever.
extractable: How many CPAN modules have EVER been released with a
weird packaging format? Is this addressing a real problem in the
world?
There are some very ancient dists that don't extract. In the first
verions of CPANTS this was actually reported, but currently dists that
fail this are completly ignored. Which is a bug...
* Finally, we come to the large body of misguided and unuseful tests:
has_test_pod: Useless. Why should every end-user have to test the
correctness of the module's POD? The original developer should test
it, and the kwalitee metric should test that the module's POD is
correct (no_pod_errors). Including it as part of the module's test
suite is useless.
While the current implementation definitly sucks (and should be changed
to work with The Oslo Consensus), I think this metric is valid. For
example, it makes sure that somebody who takes over maintainership
(without access to the authors work environemt (maybe the author died or
is just missing)) has everything she needs.
no_cpants_errors: Module author should not be dinged for bugs in
CPANTS testing.
no_cpants_errors is the best way to get some feedback from authors.
CPANTS got lots of improvements because authors complained (rightly)
that CPANTS was failing in interesting ways and caused their
no_cpants_errors metric to be flagged red.
As you might imagine, some dists contain some very sick/interesting
things. And I might have a twisted mind, but not twisted enough to come
up with every absurdity the combined crazyness of CPAN authors gives
birth to.
proper_libs: Misguided. Why should end-users care about the
structure of the module build tree? They shouldn't.
CPANTS is not only targetted at end users. In fact, its focus shifted to
helping developers write nice dists.
use_strict: Misguided. use strict is a valuable tool for
developers, but it is not necessary (or even desirable) in all
circumstances.
Huh? Do you us to head back to the funny times of Matts Script Archive?
has_example: Possibly useful, but poorly implemented (or possibly
poorly documented). Most modules that include examples do so in an
Examples section of the POD, not in a separate file or directory.
The has_example documentation implies that it'll only be satisfied by
a separate file or directory.
Can you back up the statement regarding Most modules .. do so in an
Examples section? If yes, I'd love to integrate the code you have
written to do so into CPANTS, to make it even better.
Having (some) examples in a seperate dir ready to run makes it much
easier to figure out how a dist works. No cuttingpasting from POD (with
all the nice problems that might induce).
is_prereq: Awful. I write many of my modules to without depending
on prerequisites; this reduces the load on end-users. I expect that
many other module authors do the same. Should I include other
authors' modules just to improve their kwalitee scores? More
importantly, why should Acme::FromVenus get a point for this test,
just because the author put up a dummy distro, Acme::FromMars, which
uses it? Some of my modules are very useful for end-users' code, not
so much for module developers' code. So I get dinged for this?
is_prereq is an optinal metric and thus does not count for the CPANTS
game. And yes, Apps ususally won't get prerequed. Tough luck.
--
#!/usr/bin/perl http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: How to declare dependency on other modules?
Hi!
On Fri, Apr 11, 2008 at 03:10:05PM +0200, Dominique Quatravaux wrote:
On Fri, Apr 11, 2008 at 1:04 PM, Gabor Szabo [EMAIL PROTECTED] wrote:
So if I am using Tk::Widget::A and Tk::Widget::B... Tk::Widget::Z all
provided by Tk.
Should I add all of them as prerequisite of my module or should I add only
Tk?
I'd prefer for CPANTS to allow both. TIMTOWTDI.
It's not so much an issue of a (new) metric, but of fixing various
prereq issues. Take for example App::Wack, which prereqs App::Ack.
App::Ack is provided by the dist namend 'ack'. But for various reasons,
CPANTS does not know (and cannot guess) that App::Ack is provided by
ack. So CPANTS thinks that there's an error in App::Wack and strips
Gabor off one of his dearly needed kwalitee points...
And besides that, the real problem isn't within CPANTS. It is prereq'ing
stuff via some 'magic' (eg prereqing 'Catalyst::Runtime'), when you
actually want Catalst::Request, Catalyst::Response, Catalyst::Action and
the 20+ other things in the dist 'Catalyst::Runtime'
--
#!/usr/bin/perl http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
How to depend on a specific version of Perl?
Hi!
What is the suggested / best practice method of depending on a certain
version of Perl?
I remember some discussions on the Module::Build list about adding some
keys to META.yml, but as far as I know there was no consensus.
I'd like to tell CPAN/CPANPLUS/the user that they need $version of Perl
for installing a given dist. I don't want CPAN/CPANPLUS to go and
install that version of Perl. Any hints?
--
#!/usr/bin/perl http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
