Re: Seeking a suitable forum to discuss Scalar/List::Util
On Thu, May 14, 2015 at 12:48 PM, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: I'm loathe to suggest make a new mailing list or somesuch, mostly because that likely misses most of the people who'd be interested in it. Partly I might just suggest these two lists, unless people on either list object to the traffic. I second the suggestion of the cpan-workers mailing list. You'll get a good cross section of high-upriver maintainers who are probably the right audience for what you're looking for. -- David Golden x...@xdg.me Twitter/IRC: @xdg
Re: Curating old dists on CPAN
On Thu, Apr 30, 2015 at 6:46 PM, James E Keenan jk...@verizon.net wrote: 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. +1 Who knows what on DarkPAN is using it? I think removal always needs to be intentional. But as I've said, I'm OK with some curation group fixing things up, marking them unsupported/deprecated, and releasing them when authors are no longer responsive. -- David Golden x...@xdg.me Twitter/IRC: @xdg
Re: Proposal for building module info
On Fri, Feb 10, 2012 at 4:47 AM, Neil Bowers n...@bowers.com wrote: At the moment I have everything internally under a CPAN::Curation:: namespace, but if released separately I don't think that's appropriate. I think that namespace is fine -- it's about your project, after all. CPAN::Module::Metadata for the data class? CPAN::Module::GetMetadata for the builder? CPAN::Module::Metadata::Factory? The CPAN distribution already has CPAN::Module. Since your classes have nothing to do with CPAN.pm or installing CPAN modules, I think it's confusing to put your code under that namespace. If you're really not happy with Curation, perhaps CPAN::Summary would be a more fitting name, or CPAN::Mashup if you want to be cute about it. David
Re: Spam to CPAN Developers? (Fwd: Betonmarkets CTO position)
On Tue, Sep 6, 2011 at 5:52 AM, Olof Johansson o...@cpan.org wrote: Well, that's not true. They are however one of very few that could pass as ham, and will therefore pass through many spam filters. The problem is that there is a list of 8630 non obfuscated e-mail addresses in the /authors/00whois.xml file. I'm not sure this can or should be changed, but it makes CPAN authors an easy target. Since aut...@cpan.org generally forwards somewhere useful, it's not the whois file that matters. I've gotten similar spam (from another company) that got my email off github. I think recruiter spam is just one of those things to ignore. At least it's *topical* unlike the email about winning a million pounds in a British lottery. -- David
Re: Module::Build::Tiny
On Mon, Aug 29, 2011 at 1:50 AM, Aristotle Pagaltzis pagalt...@gmx.de wrote: I find this module intriguing. Thank you. It grew out of Acme::Module::Build::Tiny -- which was an exercise to determine the *minimal* API that Build.Pl/Build needed to allow the toolchain to install a module. (Thus cutting out all the authoring cruft that bled into Module::Build over the years.) Kudos to Leon for taking it from Acme and making it real. In my understanding, the complexity of Module::Build piled up because the same tool tries to cover both installation and authoring use cases. That is one part of the complexity (OO subclassing is the other part). I suspect that the majority of the lines of code are due to author support, not installation support. But is the implementation up to par? Essentially: if I’m using Dist::Zilla for authoring, what regular features not explicitly mentioned in MBT’s POD would I have to avoid? Do things like optional or build-/test-only deps work? (I’d assume these do.) Or can I assume that everything will work unless otherwise pointed out? I haven't used it in my own modules. With Dist::Zilla to hide the ugliness of Makefile.PL from me, I just let it use that. Most if not all of what dzil does should still work. The exception would be plugins that want to hack directly on a generated Makefile.PL (e.g. Dist::Zilla::Plugin::DualLife). I could answer this for myself if I had *exact* understanding of how much of the work falls upon the .PL at install time, and how many of the toolchain features are implemented in the CPAN client and thus unaffected by MBT’s minimalism. MBT uses many external libraries (many core, some not yet core :-) to do what it does. Here's a very simplistic version of the install process (not specific to MBT): * PL -- resolve any dynamic configuration issues; write prereq data into somewhere the toolchain can find it (MYMETA is the new standard, but EUMM and MB had their own custom ways to do it); alert users to things missing * make/Build -- assemble all files to be installed into blib/ -- for pure perl module, this is usually just copying from lib/, unless there are other foo.PL modules to generate foo.pm; for C/XS modules, a lot of libraries are needed to compile the XS, location the C compiler, etc. This is ugly, complicated stuff to get right portably, which is why MBT doesn't do it (yet) * test -- run tests in t with Test::Harness (or possibly TAP::Harness); the make/Build tools is responsible for determining the list of files to run, including possible recursion in t/, as well as setting any necessary environment variables (e.g. PERL5LIB) * install -- assemble a manifest of files to be installed from blib/ and hand off to ExtUtils::Install to do the dirty work One of the hard parts throughout the stuff above is getting the library paths correct. For installation, that means sorting out where to install given PREFIX/INSTALL_BASE or custom library paths. For testing, that means ensuring the right PERL5LIB/PATH given the various ways they could be set, e.g. in an original PERL5LIB, via -I bar flags to perl Makefile.PL or perl Build.PL, or via use lib statements in *.PL (More that you wanted to know, perhaps.) (I’d also be interested in whether any omissions mentioned in the POD are design choices or the idea is to add them in the future, and which if so.) I don't personally plan to do more work on it now that the Build.PL/Build API has been demonstrated. I'll leave that to Leon to respond to. Most of the original Acme::Module::Build::Tiny limitations were design decisions to stay consistent with the Tiny philosophy of providing 90% of the functionality of the heavy module in a fraction of the code. I wasn't trying to rewrite M::B. I was trying to write a new, minimalist replacement sufficient for most things on CPAN that didn't require any changes to CPAN/CPANPLUS/cpanminus. Eric raises the question why bother and I think for module authors, at least right now, there is no burning platform to switch. Schwern has been trying to get people to stop using EU::MM for years and I think the MBT is a stepping stone towards that vision. Once it figures out the hard bits of interacting with the toolchain, it should be relatively easy for it or successors to add the missing features within a well-defined framework. Perl 5.10.1 supports configure_requires and is already unsupported by P5P, though the Perl toolchain maintainers have an informal agreement to support older Perls (5.6 at least, though that may shift to something in the 5.8 series with decent Unicode support before long). By the time that MBT has enough track record for widespread adoption, I would hope that Perl 5.10.1 becomes the oldest perl supported by the toolchain and then MBT or other Build.PL solutions will be the future and we'll finally put a stake in the heart of ExtUtils::MakeMaker. -- David
Re: Module::Build::Tiny / dynamic_config=0
On Mon, Aug 29, 2011 at 2:25 PM, Eric Wilhelm enoba...@gmail.com wrote: I think the most complicated part is supporting whatever builder+installer assumptions people have encoded into their configurations -- maybe the client could read buildrc? For that, I'd prefer to see a new way for CPAN clients to share common configuration information. Think how ~/.gitconfig provides config info used by lots of git ecosystem tools. I'd like that for CPAN so one isn't configuring mirrors, INSTALL_BASE, etc. for each client individually. I had some stub code for that, but have set it aside in favor of other projects. I don't think .buildrc is the answer, though. It has a number of limitations, particularly with respect to paths with spaces. -- David
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Fri, Jul 29, 2011 at 7:58 AM, sawyer x xsawy...@gmail.com wrote: I like to work in HTTPS (and we should, really, in a secure world). Many websites already moved to it by default such as github.com, all google sites, workflowy.com, foursquare and more. Those are all sites for which users log-in and keep lots of personal information. They are not reference sites. SSL prevents (or at least makes it difficult to do) proxy caching. Thus, every client needs to hit the origin server directly and idempotent requests (which is the vast majority of them) can't be served up by intermediate caching, which wastes server cycles and bandwidth. That is fundamentally bad design when the use case does not require protection of user information. The only time MetaCPAN should be forcing https is for author log-in and logged-in sessions. (I support offering it as an option, but it doesn't need to be the default). Most of what we do online is private. Not I want to hide this because it's illegal private, but this is personal, so mind your own business private. SSL does not hide the hostname (and port) you are connecting to; it will only hide the actual HTTP request and response. On the actual subject of whether MetaCPAN is becoming a defacto standard -- consider that search.cpan.org has a Google PageRank of 7. MetaCPAN has quite a ways to go before it will have that level of significance in search results. (Maybe if p3rl.org routed to MetaCPAN instead of search.cpan.org, that would help.) I think MetaCPAN is a great project and is evolving quickly, but hyperbole doesn't serve any real benefit. -- David
Re: PDF in Marpa::XS distribution?
On Mon, Jul 18, 2011 at 9:31 AM, Chris Marshall devel.chm...@gmail.com wrote: I recommend putting a link in the POD to the PDF on a web site. A 4X increase in the size of the distribution is a pretty expensive way to publish. How about a short synopsis in the POD with the link for more detail if needed---unless, of course, the Marpa::XS is not usable without reading the PDF? I concur -- particularly because in practice, there is no standard for how extra docs should be installed and made accessible to users. Yes, one could use File::ShareDir to install it, but then you still have the problem of getting the user to know where to find it. On the other hand, if it's in the tarball and not installed, then 99% of users will download the tarball, unpack it to temp space and then discard the build directory and tarball and all that extra size is for naught. A web link is the way to go. -- David
Re: How to list optional dependencies?
On Tue, Jul 12, 2011 at 5:20 PM, Gabor Szabo szab...@gmail.com wrote: As I could not find and answer I wonder if there is a well defined tool for this in any of the packaging tools of Perl? If not, what is the recommended way to say in Makefile.PL and/or Build.PL: I don't require Module::Name version 2.7 but I'd work much faster/better/cleaner if I had it. Shall I install it? The official way to list these dependencies is defined in the CPAN::Meta::Spec (cf http://goo.gl/paQGy ) The only distribution creation tool that can create metadata consistent with the full spec (that I'm aware of) is Dist::Zilla. See Dist::Zilla::Plugin::Prereqs, but it works like this in your dist.ini: [Prereqs / RuntimeRecommends] Foo::Bar = 1.23 [Prereqs / TestRecommends] Test::Differences = 0.61 Module::Build offer more limited capabilities to set Runtime/Recommends modules using 'recommends' (as previously mentioned). I believe with ExtUtils::MakeMaker you would have to manually set extra META fields. (I don't recall whether Module::Install gives you any sugar for it.) Unfortunately, I don't think any of the CPAN *clients* do anything yet with recommendations of this sort. The tools for creating more expressive prerequisites just made it into Perl 5, Version 14 and my personal goal is to get support into CPAN.pm in time for Perl 5, Version 16. -- David
Re: Quick and dirty guide to running Perl on Windows (was Re: Making sure your module works on other OS-es as well)
On Sat, Jul 9, 2011 at 4:03 AM, Eric Wilhelm enoba...@gmail.com wrote: Not to mention the general case of a CPAN author, where you can't assume that they could be bothered to *obtain* a windows/mac OS, let alone I think you're missing the point of my post, which was to offer a way for people to try it without a lot of hassle if they were inclined to do so but not sure how. I certainly wasn't preaching that all CPAN authors must set up Windows VMs. -- David
Re: Making sure your module works on other OS-es as well
On Mon, Jul 4, 2011 at 5:35 PM, dhu...@hudes.org wrote: This all brings up a point about maintenance of Perl: it is one thing to not release new features in 5.10.1 it is another to say since we have already 514 we won't consider bug fix releases for 5.10.1 Bundling stuff into core and making bug fixes unavailable to older Perl is another mess. I'm very sympathetic to your concern. For a long time, Perl didn't have any formal support policy. That has changed in recent years under Jesse Vincent's leadership and Perl now has a policy: http://perldoc.perl.org/perlpolicy.html#MAINTENANCE-AND-SUPPORT The fundamental issue with backporting bugs to older Perls is lack of volunteer time to do the work. As Jesse's new policy puts it, Perl 5 is developed by a community, not a corporate entity. I think one reason that Perl is generally pretty up to date on Debian-based systems is that the debian-perl group is very active and contribute regularly to the perl5-porters that maintains the Perl source. I don't really know what the story is for other OS groups. -- David
Quick and dirty guide to running Perl on Windows (was Re: Making sure your module works on other OS-es as well)
On Fri, Jul 1, 2011 at 9:23 AM, David Cantrell da...@cantrell.org.uk wrote: I went through a period of trying to make sure my code worked on Windows, but I've given up. Not because it's hard to do - it generally isn't - but the complete lack of a reasonable set of tools* on Windows, which just makes me angry whenever I have to touch the blasted thing, made me stop. * starting with a useable shell and editor, documentation, and remote text-based access. No doubt it doesn't help that I have no need for Windows, either personally or professionally, so have no motivation to put the effort into learning it. Definitely the lack of remote text based access makes it harder. But for anyone willing to run Windows in a virtual machine, it's not terribly hard anymore. Personally, I use VirtualBox on Ubuntu with a Windows 7 guest. I suggest WinXP if you have old licenses kicking around, as it's a little less annoying about validation and such. Gabor has made it really easy to get Padre and Strawberry Perl together: http://padre.perlide.org/download.html I also note that gvim runs wonderfully on Windows: http://www.vim.org/download.php#pc -- if you prefer that over Padre, then you only need to install Strawberry Perl: http://strawberryperl.com/ When I was working on Windows regularly, the regular cmd.exe shell worked well enough once I added a bunch of ported gnu programs to my path: http://unxutils.sourceforge.net/ -- that let me keep typing ls, cp, mv etc. IMPORTANT -- be sure to rename/delete all of the tar/zip programs because they are buggy and you don't want your CPAN config finding them. You also need to rename any that conflict with windows programs (I seem to recall find I renamed to myfind or something like that.) If you use git for source control and want to use it to get your code onto the windows box, I recommend using TortoiseGit: http://code.google.com/p/tortoisegit/ Best of luck! -- David
Re: Making sure your module works on other OS-es as well
On Sat, Jul 2, 2011 at 7:40 PM, Shmuel Fomberg ow...@semuel.co.il wrote: On 2011/07/03 1:02, David Cantrell wrote: Oh, and by the way, can someone make the server reject report from ancient Perl versions? Why? Because it gives the feeling that we support them. I think that there is someone who is running a smoker on Perl 5.6. do we want authors to get error reports because some feature that they used does not exists or was buggy on that version? I'm not advocating of throwing everything before 5.12, but I think that version 5.8.9 if the earliest we should accept. This meme comes up in some variety or another a few times a year. Let me respond before the bikeshedding gets too advanced. CPAN Testers reports are just data, they aren't being curated in any way. If authors don't want failure reports on ancient Perls, they are advised to be explicit with use 5.006 or use 5.008009 or whatever is the earliest version they choose to support. Likewise, if authors don't wish to be notified about reports, they can customize notification on the preferences site: https://prefs.cpantesters.org/ -- David Golden
Re: wrong license from META.yml
Dear Herbert, The module-authors list has nothing to do with search.cpan.org and can't do anything to resolve this bug. As per the Feedback page, you need to email cpansea...@perl.org. c.f. http://search.cpan.org/feedback Regards, David On Sat, Jun 11, 2011 at 11:08 PM, herbert breunung deirdre_s...@web.de wrote: hello , im not very amused, because I stated in http://cpansearch.perl.org/src/LICHTKIND/Kephra-0.4.3.29/META.yml that Kephra is under the gpl and CPAN says postres license: http://search.cpan.org/~lichtkind/Kephra-0.4.3.29/ i will change it to gpl_2 with the next version, maybe that will fix that. thanks herbert
Announcing Module::Build 0.3800
I'm pleased to announce the release of Module::Build 0.3800. It should be appearing soon on a CPAN Mirror near you. The major enhancement since the 0.36XX series is support for CPAN Meta Spec version 2 files (MYMETA.json and META.json). Also, if you haven't kept up with Module::Build, the 0.3607 release was nearly a year ago and there have been over 20 development releases, mostly fixing various bugs. An excerpt from the last year of Changes files is included below. -- David ### Module::Build Changes files since 0.3607 in April 2010 ### 0.3800 - Sat Mar 5 15:11:41 EST 2011 Summary of major changes since 0.3624: [ENHANCEMENTS] - Generates META.json and MYMETA.json consistent with version 2 of the CPAN Meta Spec. [David Golden] Also in this release: [BUG FIXES] - Autogenerated documentation no longer includes private actions from Module::Build's own release subclass. [Report by Timothy Appnel, fix by David Golden] 0.37_06 - Mon Feb 28 21:43:31 EST 2011 [BUG FIXES] - prerequisites with the empty string instead of a version are normalized to 0. (RT#65909) [OTHER] - More Pod typo/link fixes [Hongwen Qiu] 0.37_05 - Sat Feb 19 20:43:23 EST 2011 [BUG FIXES] - fixes failing ppm.t in perl core [OTHER] - Pod typo fixes [Hongwen Qiu] 0.37_04 - Wed Feb 16 15:27:21 EST 2011 [OTHER] - moved scripts/ to bin/ for less confusing porting to bleadperl 0.37_03 - Wed Feb 16 09:54:05 EST 2011 [BUG FIXES] - removed an irrelevant test in t/actions/installdeps.t that was causing failures on some Cygwin platforms [OTHER] - dropped configure_requires as some CPAN clients apparently get confused by having things in both configure_requires and requires - bumped Parse::CPAN::Meta build prereq to 1.4401 - bumped CPAN::Meta prereq to 2.110420 - Pod typo fixes [Hongwen Qiu] 0.37_02 - Mon Feb 7 21:05:30 EST 2011 [BUG FIXES] - bumped CPAN::Meta prereq to 2.110390 to avoid a regression in 2.110360 0.37_01 - Thu Feb 3 03:44:38 EST 2011 [ENHANCEMENTS] - Generates META.json and MYMETA.json consistent with version 2 of the CPAN Meta Spec. [David Golden] [BUG FIXES] - t/signature.t now uses a mocked Module::Signature; this should be more robust across platforms as it only needs to confirm that Module::Build is calling Module::Signature when expected [OTHER] - Added CPAN::Meta and Parse::CPAN::Meta to prerequisites and dropped CPAN::Meta::YAML 0.3624 - Thu Jan 27 11:38:39 EST 2011 - Fixed pod2html directory bugs and fixed creation of spurious blib directory in core perl directory when running install.t (RT#63003) [Chris Williams] 0.3623 - Wed Jan 26 17:45:30 EST 2011 - Fixed bugs involving bootstrapping configure_requires prerequisites on older CPANPLUS clients or for either CPAN/CPANPLUS when using the compatibility Makefile.PL - Added diagnostic output when configure_requires are missing for the benefit of users doing manual installation 0.3622 - Mon Jan 24 21:06:50 EST 2011 - No changes from 0.36_21 0.36_21 - Fri Jan 21 11:01:28 EST 2011 - Changed YAML::Tiny references to the new CPAN::Meta::YAML module instead, which is the YAML-variant that is going into the Perl core 0.36_20 - Fri Dec 10 15:36:03 EST 2010 *** DEPRECATIONS *** - Module::Build::Version has been deprecated. Module::Build now depends directly upon version.pm. A pure-perl version has been bundled in inc/ solely for bootstrapping in case configure_requires is not supported. M::B::Version remains as a wrapper around version.pm. - Module::Build::ModuleInfo has been deprecated. Module::Build now depends directly upon Module::Metadata (which is an extraction of M::B::ModuleInfo intended for general reuse). A pure-perl version has been bundled in inc/ solely for bootstrapping in case configure_requires is not supported. M::B::ModuleInfo remains as a wrapper around Module::Metadata. - Module::Build::YAML has been deprecated. Module::Build now depends directly upon YAML::Tiny. M::B::YAML remains as a subclass wrapper. The YAML_support feature has been removed, as YAML is now an ordinary dependency. 0.36_19 - Tue Dec 7 13:43:42 EST 2010 Bug fixes: - Perl::OSType is declared as a 'configure_requires' dependency, but is also bundled in inc (and loaded if needed) [David Golden] 0.36_18 - Mon Dec 6 16:46:49 EST 2010 Changes: - Added dependency on Perl::OSType to refactor and centralize management of OS type mapping [David Golden] - When parsing a version number out of a file, any trailing alphabetical characters will be dropped to avoid fatal errors when comparing version numbers. These would have been dropped (with a warning) anyway during an ordinary numeric comparison. (RT#56071) [David Golden] Bug fixes: - A Perl interpreter mismatch between running Build.PL and running Build is now
Re: What is your preferred way to get help?
On Sun, Jan 16, 2011 at 5:09 AM, Gabor Szabo szab...@gmail.com wrote: My objective is getting more people to contribute to CPAN. I don't necessarily want more modules. I'd prefer to get more people involved in maintaining and improving the already existing module. Reactions off the top of my head: * Be wary of the parallel between open source projects and CPAN. There are some CPAN-based projects like Padre, Moose or DBIC, but a lot of it is just single libraries with a single lead developer. There are some middle ground areas, too, like Dist::Zilla, with one lead developer (Ricardo) and a lot of people writing plugins for it, all loosely communicating issues and discoveries via IRC on #distzilla. So I encourage you to tune your talk differently depending on which kind of project someone wants to participate in. * For small or single developer projects, volunteers that are not self-motivated and self-directed are often not very helpful, because the opportunity cost of teaching them and managing them is too high. * I agree with Shlomi that a good foundation for any form of participation is knowing how to write a good bug report and a test case to go with it. Sending me a patch without a test case is usually worse (in my opinion) than sending me a test case without a patch. * Knowing how to use subversion and git is also pretty fundamental * Low hanging fruit: contribute a fix to a problem that you personally encountered. That could be a code fix, or improved documentation or even an example program illustrating the issue. It's low hanging fruit because it's an already solved problem and the motivation to share a solution is likely to be higher than the motivation to dive into someone else's bug and sort out the code. -- David
Re: contemplating module libraries
On Fri, Dec 10, 2010 at 7:40 PM, David Christensen
dpchr...@holgerdanske.com wrote:
Does 'configure_requires' support map to a Perl version?
It really maps to CPAN client versions, but Perl 5.10.1 ships with
CPAN and CPANPLUS that understand configure_requires. Older Perls
only need to upgrade CPAN and/or CPANPLUS to support it.
STFW, it looks like BUILD_REQUIRES and CONFIGURE_REQUIRES are supported as
of Perl 5.10.1:
http://perldoc.perl.org/5.10.1/ExtUtils/MakeMaker.html
*You* need an ExtUtils::MakeMaker that supports them in order to
create your distribution. Your end users do not. However, for users
with older EU::MM, you need to not pass those keys to WriteMakefile()
and you need to add the BUILD_REQUIRES to PREREQ_PM instead.
This sort of complicated Makefile.PL manipulation is why many people
have switched to Module::Install or Dist::Zilla instead as they take
care of those details for you.
Thanks -- I read that recently. But I missed the citation to Writing Perl
Modules for CPAN:
http://www.amazon.com/dp/159059018X/ref=cm_sw_su_dp
Should I get this book, or is there a newer/ better resource?
It was a great book but is now very, very out of date. The tutorials
on PerlMonks are probably better:
http://perlmonks.org/index.pl?node_id=592240
make all:
-- run pod2text against main module and put that into README.
-- run pod2html against listed files and put that into HTML
files.
make mcpani
-- run mcpani and inject tarball into my CPAN Mini Mirror
make release
-- copy tarball and *.html files to file server
If I wanted to migrate this functionality to a newer tool, how well suited
would Module::Install, Module::Builder, and Dist::Zilla be?
Personally, as I suggested in my article, I would probably use
Module::Build for customizations like that. (Though there are
probably Dist::Zilla plugins for a lot of it, too.)
Module::Build already can create the README for you with the
create_readme parameter. If you have HTML install paths in Config
(or define them yourself in the Build.PL or on the command line) and
have Pod::HTML installed, Module::Build will generate the HTML for you
automatically.
For the rest, it's trivially easy to subclass. You would just need
to create a subclass module, drop it into an inc/ and do this in
Build.PL (e.g. for inc/MyBuilder.pm):
use lib 'inc';
use MyBuilder;
MyBuilder-new( ... )-create_build_script;
In MyBuilder.pm, you'd have things like:
use Module::Build;
our @ISA = qw/Module::Build/;
sub ACTION_mcpani { ... }
sub ACTION_release { ... }
See Module::Build::Cookbook for examples. You can also see the
Build.PL and inc/ subclass example here:
http://search.cpan.org/~dagolden/ylib-0.002/MANIFEST
The Module::Build distribution itself uses a Build subclass that
includes code to ship M::B (Build upload) and is a good example of
what is possible. You'll see in the ACTION_distdir in the subclass
that it autogenerates some Pod and then
writes itself out of the Build.PL that ships so end users never even
see the subclass. Tricky!
https://github.com/dagolden/module-build/blob/master/inc/ModuleBuildBuilder.pm
Hope those help. Regards,
David
Re: contemplating module libraries
On Fri, Dec 10, 2010 at 5:03 PM, David Christensen
dpchr...@holgerdanske.com wrote:
I don't produce a meta.yml in my distributions. It's my understanding that
the CPAN indexer does that for me after I upload a distribution tarball.
It does not. It's your responsibility to include META.yml.
ExtUtils::MakeMaker will generate it for you since EU::MM 6.46 or so.
It's my understand that PREREQ_PM is for specifying external modules needed
once the distribution has been installed and is put into operation.
Correct. If you need modules available to *run* the Makefile.PL,
those need to be included as configure_requires in the META file and
recent CPAN/PLUS/minus will ensure they are available before running
Makefile.PL. You can conditionally add them as arguments to EU::MM
like so:
use ExtUtils::MakeMaker;
my %WriteMakeFileArgs = (
# ... normal stuff here
CONFIGURE_REQUIRES = {
'Some::Prereq' = 1.23,
},
);
delete $WriteMakefileArgs{CONFIGURE_REQUIRES}
unless eval { ExtUtils::MakeMaker-VERSION(6.52) };
WriteMakefile(%WriteMakefileArgs);
That will let you add it to configure_requires in META when you build
the distribution, but not breaks things for end-users trying to
install your modules.
Sounds like they should be in build_requires, not requires.
That sounds like Module::Build stuff:
http://perldoc.perl.org/5.10.0/Module/Build/Compat.html
Recent ExtUtils::MakeMaker supports BUILD_REQUIRES, with the same
caveats as CONFIGURE_REQUIRES.
I've been using ExtUtils::MakeMaker for years and it has met my simple
single-module distribution needs. But as I attempt to extend the tool and
use the extended tool for sets of distributions, the going is getting tough.
I'm wondering if I should upgrade, and to what -- Module::Install,
Module::Build, or Dist::Zilla?
C.f.
http://www.dagolden.com/index.php/1173/what-tools-should-you-use-to-create-a-cpan-distribution/
Regards,
David Golden
Re: Recommended builder?
On Sun, Dec 5, 2010 at 1:56 AM, Octavian Rasnita orasn...@gmail.com wrote: Ok, so using Module::Starter with Module::Install would be a good choice because Module::Starter also creates some simple test files and they may be a big part of the tests for very simple modules. Do you know if there is a way to do the same thing with Dist::Zilla? Dist::Zilla is great, but it doesn't create those simple test files. Is there a plugin for it that can do this? Absolutely. There are lots of plugins for various default tests. See any of the Dist::Zilla::PluginBundle::NAME distributions on CPAN for examples. Mine is fairly well documented as to what it includes: http://p3rl.org/Dist::Zilla::PluginBundle::DAGOLDEN Also, here's a great article explaining pieces of a dist.ini bit by bit: http://blog.urth.org/2010/06/walking-through-a-real-distini.html The Module::Starter equivalents are D::Z::Plugin::CompileTests and PodSyntaxTests and PodCoverageTests. Note that the latter two put things in the xt/ directory so you will also want either ExtraTests (which copies xt/* to t/*) or CheckExtraTests (which just tests xt before release). I favor (and wrote) the latter. Dist::Zilla plugins are part of the learning curve, but the advantage is that they are so modular that it's easy to assemble a set that does what you like (e.g. ExtraTests vs CheckExtraTests. My advice is to browse some PluginBundles and get a sense for what it can do for you. As a conclusion, for the moment my prefered way would be to use Module-Starter with M::I for simple apps and Dist::Zilla with its default EU::MM for more complex apps. Once you've gotten familiar with Dist::Zilla, you'll probably start using it for simple stuff, too. See http://github.com/dagolden/version-next for example -- it's one .pm file, one test file, a dist.ini file, a Changes file and a .gitignore file. But if you don't want the Dist::Zilla learning curve to slow down a release you really want to ship quickly, Module::Starter and M::I will work just fine. -- David
Re: Recommended builder?
On Sat, Dec 4, 2010 at 2:22 PM, John M. Gamble jgam...@ripco.com wrote: Module::Build -- this is the 'pure perl' alternative. It is very easy to customize compared to EU::MM but you can't rely on users having a new enough Module::Build for any given feature unless you target Perl 5.10.1 (which added the ability for CPAN/CPANPLUS to bootstrap tools you need *before* running Build.PL) What features do you mean? I shifted over to Module::Build when I was still using Perl 5.6. My packages are not complicated (single .pm file; pure perl; the create_makefile_pl set to 'traditional' for non-Build users), so maybe there's something else? For a simple distribution, Module::Build with a 'traditional' generated Makefile.PL is a good option. (Though older Module::Build::Compat's were rather buggy, as long as *you* have a new M::B when you generate the traditional Makefile.PL, things should work fine.) However, unless you're doing some customization, it doesn't really matter whether you use it or ExtUtils::MakeMaker. If you want to use newer features, like 'share_dir', then your end users need to have an up-to-date Module::Build and that is only possible if they have up-to-date CPAN/CPANPLUS or if they are running 5.10.1, which came with sufficiently modern CPAN clients to respect the 'configure_requires' key. If you do want things like share_dir, and if you really want to avoid bug reports from people with out of date M::B, then M::I offers a better, backwards compatible approach. (As do Dist::Zilla's generated Makefile.PL's, for the most part) Huh. I would never have considered Module::Build complicated (but then again, I don't have complicated modules). It's not that it's complicated, but I found that M::B makes life easier for authors, at the occasional expense of end users who don't have the right M::B installed. However, I have found that most of what M::B did to make life easy as an author I can get with Dist::Zilla, and it creates a Makefile.PL that is as backwards compatible as possible. Note: I am the current maintainer of Module::Build, so I have some experience with the large set of bugs and edge cases that people experience with it that certainly colors my outlook on it. -- David
Re: Using a better compression than .gz for one's CPAN modules
On Sun, Nov 28, 2010 at 4:22 PM, Aristotle Pagaltzis pagalt...@gmx.de wrote: I agree with the notion. But let me ask how much pressure changing the compression format on CPAN would exert on the world to adapt itself to it. Note too the quote is written from the perspective of the world: no mention goes to the fortunes of the unreasonable man himself… I'm not sure which side you're arguing with that. Here's how I see it: allowing a new compression format means that someone will inevitably release a distribution with it that someone will try to install with an older toolchain that won't handle it. Based on my prior experience with other such issues, a large portion of the bug reports, complaints, nasty personal comments and what not will accrue to the toolchain and its maintainers and not the author who released the not-backwards-compatible distribution. Thus, I have no personal incentive as a toolchain co-maintainer to do the work, since the only thing I'll get back from it is a hassle. And since only when a significant fraction of CPAN is released in that format will the compression benefits add up, the hassles come quick and the benefits aren't seen for a long time. On the other hand, if someone wants to recompress all of CPAN into XYZ compression scheme and release their own client that deals with it (or patch cpanm or whatever), then they can have the benefits (and any resulting hassles) themselves. -- David
Re: What hurts you the most in Perl?
On Fri, Nov 26, 2010 at 11:20 AM, Todd Rinaldo to...@cpanel.net wrote: I very much wish, however, that forks could get a return variable from the fork process like threads can. This has always frustrated me. To be honest, though, the fact that Linux forks are copy on write, takes much of the value out of threads as far as I'm concerned. See Parallel::Iterator for an example of how to do this. It pipes data to the child process and reads back a result. -- David
Re: Using a better compression than .gz for one's CPAN modules
On Fri, Nov 26, 2010 at 3:59 PM, Shlomi Fish shlo...@iglu.org.il wrote: There are two kinds of fool. One says, “This is old, and therefore good.” And one says, “This is new, and therefore better.” That put aside sticking with an older solution may be preferable due to the better adoption ratios mentioned by David and others, but to quote George Bernard Show: The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.. ( http://en.wikiquote.org/wiki/George_Bernard_Shaw ). Of the many places I choose to be unreasonable for the sake of progress, squeezing out a little bit more size reduction in tar balls is not where I'm going be spending my energies. C.f. http://www.dagolden.com/index.php/1148/bootstrapping-cpan-pm-using-httplite/ as well as the abbreviated auto CPAN config and the CPAN Mirror auto-selection in the current development series of CPAN.pm. -- David
Re: Reducing rsync cost
On Wed, Nov 24, 2010 at 4:23 AM, Nicholas Clark n...@ccl4.org wrote: Instead of running rsync over the whole tree, it can change to run a top level script that runs rsync over the parts that have to be copied, and then run the symlink generation on the parts that can be recreated locally. The new fast CPAN mirrors use File::Rsync::Mirror::Recent, which uses the new RECENT.* files to manage the synchronization process. Those files record recent changes (adds/deletes) to the frequently changing authors/ and modules/ directories. The fast mirrors use those files to sync with PAUSE every minute or so with very low overhead. The fast mirrors admins are authorized by Andreas to hit PAUSE directly, but I believe that anyone can use it with open CPAN mirrors offering rsync service. While it needs to run as a daemon, as of version 0.0.8-TRIAL, all the memory intensive work happens in child processes and the main daemon is pretty lightweight. (Mine is holding at about 8.8 MB of memory). The current list of fast mirrors are cpan.shadowcatprojects.net, cpan.dagolden.com, cpan.hexten.net and cpan.cpantesters.org. While you probably shouldn't hit those every minute without checking with the admins (e.g. me for cpan.dagolden.com) you can probably use F::R::M::Recent to hit them several times an hour with no problem. See http://tinyurl.com/35t9u3k for instructions on using F::R::M::Recent. Regards, David
Re: What hurts you the most in Perl?
On Wed, Nov 24, 2010 at 7:01 AM, Gabor Szabo szab...@gmail.com wrote: The other day I was at a client that uses Perl in part of their system and we talked a bit about the language and how we try to promote it at various events. Their Perl person then told me he would not use Perl now for a large application because: 1) Threads do not work well - they are better in Python and in Java. 2) Using signals and signal handlers regularly crashes perl. 3) He also mentioned that he thinks the OO system of Perl is a hack - that the objects are hash refs and there is no privacy. Out of curiosity, do you know what version of Perl they were running? With respect to #1, I'd like to see more energy around lightweight processes. E.g. what can we steal from Erlang. Parallel::Iterator is a nice example of what can be done using processes instead of threads, but it's not a general solution. With respect to #3, it doesn't sound like a technical objection, but a style objection. There is pretty much no privacy in perl at all -- it has nothing to do with objects. Even inside out objects can be defeated with PadWalker. I think the only option to overcome an objection like that is to attempt to demonstrate the benefits of flexibility to choose the right OO system for a particular purpose. Need stronger encapsulation, look at Class::InsideOut or Object::InsideOut. Want a powerful (if slowish) post-modern OO framework, choose Moose. Etc. -- David
Re: Using a better compression than .gz for one's CPAN modules
On Fri, Nov 19, 2010 at 1:53 PM, Shlomi Fish shlo...@gmail.com wrote: 1. Will the CPAN testing and downloading toolchian will handle modules uploaded as .tar.bz2? (Allow to install them, unpack them, etc.) How about tar.xz. .bz2, yes. .xz, possibly, but not reliably. CPANPLUS uses Archive::Extract, which can handle .xz if there are xz binaries installed. However, CPAN::DistnameInfo is the standard tool for identifying distribution metadata from a tarball filename and last I checked, it doesn't support .xz extensions, so you'll confuse things that depend on it. 2. Can I easily pack archives into tar.bz2 or tar.xz using Module-Build and/or Module-Install ? Not natively. You would need to subclass make_tarball. -- David
Re: Permissions on Lemonldap::NG namespaces
Hi, Xavier. Have you tried to change the permissions from the PAUSE interface? https://pause.perl.org/pause/authenquery?ACTION=share_perms Look at section 3. Regards, David On Mon, Oct 18, 2010 at 5:41 PM, Xavier x.guim...@free.fr wrote: Hi all, I'm the maintainer of Lemonldap::NG::* modules on CPAN, but we are 2 to manage the project. Is it possible to agree coudot (Clément Oudot) to maintain: * Lemonldap::NG::Portal * Lemonldap::NG::Manager * Lemonldap::NG::Handler * Lemonldap::NG::Common Best regards, Xavier
Re: RFC: Hump
On Fri, Aug 20, 2010 at 6:40 PM, Xiong Changnian xiong-c...@xuefang.com wrote: I'm looking for a top-level namespace to put Hump under. I expect quite a few submodules under the *::Hump:: but filling in that * is my goal today. Absent violent objection, I plan to keep the 'Hump' part of the name. Is this Perl-specific? Most perl developer tools seem to be winding up under Module::* or Dist::* I agree with Ricardo that Hump has some negative meanings (as well as positive ones like carry) so I do suggest you consider those factors as well. -- David
Re: Frozen Bubble 2.2.1
On Thu, Aug 5, 2010 at 3:20 AM, Guillaume Cottenceau gcott...@gmail.com wrote: Kartik and friends rewrote SDL_perl (a Perl module with SDL bindings) using a different API. Then they ported my Perl-based game to using that new Perl module, and to be CPAN-friendly. My game previous versions were 2.0.0, 2.1.0, 2.2.0, so now I would like it to be versioned 2.2.1. But prior to that, I would like to release a beta version because I suspect a couple of corner cases to contain bugs. So we're looking for a way to version it 2.2.1-beta1 or something similar, in order for it to NOT be included in stable distributions or replace 2.2.0 for regular users. Then we'll release 2.2.1 in a couple of weeks when no more important bugs are known. Thanks for your patience :) Let me restate what I think the situation is: * Frozen Bubble is now (or will be) a CPAN distribution rather than a standalone program distributed independently * You would like the CPAN version to indicate a beta status so that OS packagers don't blindly replace it for users I don't know exactly what criteria OS packagers use for deciding what is or isn't beta, but presumably the tarball name is significant. They may or may not be Perl experts familiar with CPAN conventions. I would suggest the following: * To be consistent with your prior versioning (dotted-decimal), require a minimum version of Perl that understands v1.2.3 numbering. That means 5.6.0 at a minimum, 5.8.1 is better, 5.10.0 is best but you might not want to impose that requimrent on end-users. * For the *modules* inside the distribution, follow CPAN conventions and include an underscore in the version number within the modules if they are beta e.g. our $VERSION = v2.2_1 Your final release should bump the last number and use a decimal our $VERSION = v2.2.2 (For the sake of simplicity and compatibility with Perl 5.10.0, I suggest that you NOT use the version.pm module.) * For the *distribution* (i.e. the tarball) you have more choices. For Perl people it would be sufficient to have this: Frozen-Bubble-v2.2_1.tar.gz But for people unfamiliar with CPAN conventions, I suggest one of the following: a) Frozen-Bubble-beta-v2.2_1.tar.gz b) Frozen-Bubble-v2.2_1-TRIAL.tar.gz c) Frozen-Bubble-v2.2.1-TRIAL.tar.gz In (a), you put beta in the title of the distribution, but leave the underscore in the version number. This tells PAUSE (the CPAN indexer) not to index this distribution, which is what you want for a beta. You might confuse some parts of the ecosystem like CPAN Testers, which will think that Frozen-Bubble is a different distribution than Frozen-Bubble-beta, but that's a fairly small price to pay. The (b) and (c) forms are not very common and take advantage of a little-known feature of PAUSE. Appending -TRIAL to the version number is another way of telling PAUSE not to index the distribution. If you do that, you have the choice of (b) or (c) as the underscore is no longer significant in the tarball name. Hopefully, that is also enough to warn off packagers. * If you accept -TRIAL as the answer that gives you a tarball name that packagers will know not to distribute and are consistent in always using it for your betas, then you could even stop using an underscore in the $VERSION variable and just use a period. our $VERSION = v2.2.1; * Just as a reminder, you still always want to bump the version numbers of your modules as you go from beta to final. CPAN conventions don't really support the concept of 2.2.1-beta followed by 2.2.1 (final). Numbers are expected to be monotonically increasing. You might want to adopt your own convention of odd numbers being development/beta and even numbers being releases. That's probably far more complex that you ever imagined, but I hope it gives you some useful direction. As I said in my article, it's really too bad that version numbers aren't boring. Thank you for writing such a cool game in Perl! PS: is an XY problem bound to a specific gender? do you think giving the problem to an XX person would solve it faster? :) The XY problem refers to wanting to do X, thinking Y is the right approach and asking how to do Y, but X is vital context and people might have better solutions than just Y. c.f. http://www.perlmonks.org/index.pl?node_id=542341 -- David
Re: Frozen Bubble 2.2.1
On Thu, Aug 5, 2010 at 7:45 AM, Kartik Thakore thakore.kar...@gmail.com wrote: thia dist_name = in M::B correct? Yes. Though maybe I should just implement a feature to add '-TRIAL', since I'll need that anyway for CPAN Meta 2 support. (Dist::Zilla already supports -TRIAL). -- David
Re: -TRIAL dists (was: Frozen Bubble 2.2.1)
On Thu, Aug 5, 2010 at 2:46 PM, Eric Wilhelm enoba...@gmail.com wrote: Does search.cpan.org understand -TRIAL now? Last I looked, it was properly handled (i.e. not indexed) by PAUSE, but would leak through in a few other places where it appears that an assumption was being made without checking the index. CPAN::DistnameInfo added support for '-TRIAL' in 0.10 back in March of this year and I'm pretty sure that's what Graham is using for search.cpan.org. It's certainly possible that it's leaking through elsewhere. rjbs has been doing -TRIAL releases of Dist::Zilla and may have a better sense of where any remaining issues are. It also looked like '-TRIAL' was intended to be used as a pre-release without bumping any version numbers, so you could have -TRIAL1, -TRIAL2, etc all with the version e.g. 5.6.2. Am I understanding that right? I believe that was specific to perl distributions, not CPAN distributions, but it may work for those as well. -- David
Re: Frozen Bubble 2.2.1
On Wed, Aug 4, 2010 at 4:12 PM, Guillaume Cottenceau gcott...@gmail.com wrote: Hum. This is for an application (a game), not a module, and I want it to be clearly labelled as a beta release. So fine with There are no standard conventions for alphanumerics, and you just make life hard for the machines, which means no help for the humans. but I don't see the big problem for machines and I don't know how to say hey this is beta only with numbers; especially if 5.005_03 is equivalent to 5.5.30, I don't see how this could be considered to mark it beta/dev :/ Thanks for your help.. Let me try to clarify. For a given Perl module called Foo, the $Foo::VERSION variable defines the version number that the perl interpreter will use to check against a minimum required version: use Foo 1.02; You can't put alphanumerics in $Foo::VERSION and have things behave nicely. However, a distribution -- by which I mean a tarball containing Perl modules, can have any name/number you want.. By convention, it should follow the same rules as for Perl module numbers, but it doesn't have to. The big downside to alphanumerics is that various CPAN ecosystem tools may not know how to interpret it as a number. If you don't plan on releasing this to CPAN, then you don't have to worry about it. If you do, then you should be aware of the conventions. They evolved organically over time, if that helps explain why things are the way they are. -- David
Re: Frozen Bubble 2.2.1
On Wed, Aug 4, 2010 at 4:42 PM, Kartik Thakore thakore.kar...@gmail.com wrote: How do we make this work? I get a error doing this. I think you need to be a lot more specific about this. I'm beginning to suspect an XY problem. Walk us through -- step by step -- what you're trying to accomplish, the steps you're taking, and the errors that you're seeing. -- David
Re: Problem with target of http://search.cpan.org/dist/Marpa/?
On Wed, Jul 7, 2010 at 11:14 AM, jeffreykegler jeffreykeg...@mac.com wrote: My thought is that the target of http://search.cpan.org/dist/Marpa/ is decided by the CPAN infrastructure. Any ideas as to how I'd go about resolving this issue? Email cpansea...@perl.org as per http://search.cpan.org/feedback -- David
Re: Which Build Module?
On Wed, Jul 7, 2010 at 10:01 AM, Joshua ben Jore twi...@gmail.com wrote: What? That's certainly not what happens for me. I just ensured I had no ~/.cpan or ~/perl5, installed perlbrew, then installed new perl-5.12.1. When I ran the newly created cpan client, my default `o conf yaml_module' is YAML and not Parse::CPAN::Meta. I just tried requesting an upgrade to CPAN and my client is already up to date (1.94_56). There are two situations in which CPAN.pm reads YAML files. (1) A distribution contains META.yml or produces a MYMETA.yml after running Build.PL/Makefile.PL -- in this case, Parse::CPAN::Meta is preferred and CPAN.pm will fall back to the configured 'yaml_module' setting if Parse::CPAN::Meta is not installed or if Parse::CPAN::Meta throws an error during parsing. (2) CPAN.pm is reading distroprefs or its own cached data -- in this case CPAN.pm uses the configured 'yaml_module' (which is also used to create the cached data files) -- David
Re: Which Build Module?
On Tue, Jul 6, 2010 at 1:53 PM, Todd Rinaldo to...@cpanel.net wrote: Just so you know, AFAIK: 1. ExtUtils::MakeMaker (EU::MM) is not dead and will shortly be under new management. EU::MM is still being used for current and new modules. 2. Dist::Zilla is a packaging tool, not an installer. Typically EU::MM is generated from Dist::Zilla managed packages. 3. Module::Install uses EU::MM under the hood. I think the broader point is that using ExtUtils;:MakeMaker directly and writing to it by hand in the Makefile.PL is fading in preference to using front-ends like Module::Install or Dist::Zilla to make EU::MM less painful to use and extend. I know that's a generalization, but I suspect it holds true for many or most of the higher volume authors and/or jointly-managed projects. -- David
Re: Which Build Module?
On Tue, Jul 6, 2010 at 3:40 PM, Joshua ben Jore twi...@gmail.com wrote: FWIW, even the most up-to-date CPAN.pm comes broken out of the box for configure_requires because we say we prefer the YAML module to read the configure_requires out of $whatever.yml and don't fail-over to use the thing that's actually packaged with perl. That's incorrect. CPAN.pm prefers Parse::CPAN::Meta and will attempt to parse with it. If it's not available (or the parse fails), it will fall-back to the CPAN-defined preferred YAML module. Parse::CPAN::Meta is read-only and CPAN's preferred YAML module is so that it can write (and read back) data as it processes things. -- David
Re: Conditional dependencies
On Tue, Jun 29, 2010 at 2:37 PM, Matt Grimm matt.t.gr...@gmail.com wrote: For example, I have a logger class wrapped around Log4perl that supports screen, email, and syslog appenders, and each appender can be individually toggled on or off. Is it better to force the dependencies on the underlying syslog and email modules at the top of the logger class, or is it acceptable to bury those imports in the methods that actually do the initialization of each appender? It sort of comes down to whether I want the issue detected at compile time or run time I suppose, but is generally frowned upon to put imports down inside class methods? I tend to think about it like this: (a) Mandatory for operation? Load it at compile time. (And list it as a prerequisite in Makefile.PL/Build.PL) (b) Optional and almost always loaded in normal operation? Load it at compile time. Even if there possible fallbacks, get it out of the way at compile time. (c) Optional and only needed some of the time? Load it at runtime if/when needed. -- David
Fwd: EU::MM LIBS winnowed too-early at .PL-time?
I'm forwarding to the makema...@perl.org list, as this is not likely
to be of general interest to all module authors.
-- David
-- Forwarded message --
From: Joshua ben Jore twi...@gmail.com
Date: Wed, Jun 9, 2010 at 3:22 PM
Subject: EU::MM LIBS winnowed too-early at .PL-time?
To: Perl Module-Authors module-authors@perl.org
Hi,
In Judy I have a PREREQ_PM using Alien::Judy which by it's action
installs libJudy.so and Judy.h. I also have a LIBS and INC which refer
to the thing being installed. It appears that my Makefile.PL's LIBS
argument is being tossed because the specified directories and their
contents don't exist but *will* by the time it will be actually used.
PREREQ_PM = {
'Alien::Judy' = 0
},
INC = -I$Config{sitearch}/Alien/Judy,
LIBS = -L$Config{sitearch}/Alien/Judy -lJudy
Can I get EU::MM to stop filtering my LIBS for me?
Josh
Re: CPAN Meta Spec Version 2 released
On Mon, Apr 19, 2010 at 7:55 AM, Elliot Shank p...@galumph.com wrote: Oof. Version numbers: All components after the first are restricted to the range 0 to 999. That's going to be a problem for those of us who include things like VCS revisions and CI build numbers in version numbers. You can do that as long as you use regular decimals and not dotted-decimals. Dotted-decimals have a round-trip problem when being compared to decimals. Depending on the order that things are converted, you can get different answers. Consider v1.2.1000.3. How should that be converted to a decimal version? Following the rule that every dotted component after the first is multiplied by 10e-(3*n), you might think 1 + 2 * 0.001 + 1000 * 0.01 + 3 * 0.1 or 1.00303. But if you ask version.pm to numify it, you get this: $ perl -Mversion -wE 'say version-new(v1.2.1000.3)-numify' 1.002103 Now consider how version.pm converts those decimals back to dotted form: $ perl -Mversion -wE 'say version-new(1.002103)-normal' v1.2.100.0.300 $ perl -Mversion -wE 'say version-new(1.00303)-normal' v1.3.0.3 Not all parts of the toolchain support prerequisites specified in dotted decimal form. How will users convert to decimal? We can't know. Perl itself will interpret dotted decimals slightly differently in use NAME VERSION depending on the version of Perl. If a module uses dotted decimals, are the user putting the dotted decimal on the use line or a decimal version? If a decimal version, which one? The rule in the CPAN Meta Spec that limits dotted decimal components after the first to the range 0 to 999 is designed to ensure unambiguous interoperability. CPAN Authors are free to use dotted decimals outside that range, but any spec that contains them will be treated as invalid. -- David
Re: Tidy up your PAUSE directories
On Thu, Apr 1, 2010 at 1:08 PM, Jeffrey jeffreykeg...@jeffreykegler.com wrote: On Mar 31, 2:51 am, tim.bu...@pobox.com (Tim Bunce) wrote: It would be handy if there was a way for authors to indicate that new maintainers are sought. Perhaps via the META.yaml/(.json) file. It would also be handy if that (or another) mechanism would also indicate orphaned modules -- modules abandoned by the author, but not taken up by anyone else. If nobody cares to adopt an abandoned module, that might indicate it's a good candidate if and when we decide to trim CPAN. It's not in the CPAN META spec now and is not going to be in the 2.0 spec released later this year, so other mechanisms are necessary. To me, PAUSE would seem to be the right place to do it, as it doesn't require authors to re-release a distribution just to indicate a change in status. PAUSE permissions need to support open for claiming that would let the next upload by anyone claim the permissions. -- David
Re: Trimming the CPAN
On Tue, Mar 23, 2010 at 5:14 AM, Shlomi Fish shlo...@iglu.org.il wrote: It still has Curses-UI-0.71 from February 2002, and many other previous versions. All of this takes space on the CPAN , takes time to mirror and download, and clutters the various interfaces like search.cpan.org. So I've been thinking that maybe we should trim the CPAN and remove older versions like that so it will contain much less cruft. What do you think? Who is complaining about space? Anyone who wants just the latest distributions can already get just that with CPAN::Mini. Mirror time is a one-time cost and only for someone hosting a full mirror. I don't see why shaving some time off that first-time rsync is a big deal. Clutter on search.cpan.org is inside a drop-down box. That's not clutter. Other than fastidiousness, I don't see the big deal. -- David
Re: Q about prerequisites
On Thu, Mar 25, 2010 at 12:58 PM, cr...@animalhead.com wrote:
'BUILD_REQUIRES' = {'LWP' = 5.834,
BUILD_REQUIRES was only recently added to ExtUtils::MakeMaker in 6.56.
You need to add 'configure_requires' to META.yml specifying
ExtUtils::MakeMaker 6.56.
That won't help users with old CPAN/CPANPLUS clients that do not honor
configure_requires, but I think most CPAN Testers use an updated
version.
-- David
Re: Q about prerequisites
On Thu, Mar 25, 2010 at 7:39 PM, cr...@animalhead.com wrote:
diagnosis. So I'll put CONFIG_REQUIRES = {EU:MM = 6.56} into
Makefile.PL, and check that it propagates to META.yml.
Nit: It's CONFIGURE_REQUIRES, not CONFIG_REQUIRES. Also, you'll
probably want to put that in a section that only runs if EU::MM is =
6.56.
-- David
Re: Q about prerequisites
On Thu, Mar 25, 2010 at 11:04 PM, cr...@animalhead.com wrote:
Your comment put that in a section that only runs...
has me all confused.
I just put CONFIGURE_REQUIRES = {EU:MM = 6.56} into Makefile.PL.
It went into META.yml.
This is a small module and has no sections that I can think of.
What do you mean?
Here is an example from Module-Starter. Note the (eval {
ExtUtils::MakeMaker-VERSION(...) }) stanzas, which avoid older EU::MM
from complaining about invalid arguments to WriteMakefile;
WriteMakefile(
NAME= 'Module::Starter',
AUTHOR = 'Andy Lester a...@petdance.com',
VERSION_FROM= 'lib/Module/Starter.pm',
(eval { ExtUtils::MakeMaker-VERSION(6.21) } ? (LICENSE = 'perl') : ()),
ABSTRACT_FROM = 'lib/Module/Starter.pm',
EXE_FILES = [ 'bin/module-starter' ],
PREREQ_PM = {
'Test::More'= 0,
'Test::Harness' = 0.21,
'ExtUtils::Command' = 0,
'File::Spec'= 0,
'Getopt::Long' = 0,
'Pod::Usage'= 1.21,
},
(! eval { ExtUtils::MakeMaker-VERSION(6.46) } ? () :
(META_ADD = {
resources = {
homepage = 'http://code.google.com/p/module-starter/',
repository =
'http://module-starter.googlecode.com/svn/trunk/',
bugtracker =
'http://rt.cpan.org/NoAuth/Bugs.html?Dist=Module-Starter',
},
})
),
dist= { COMPRESS = 'gzip -9f', SUFFIX = 'gz', },
clean = { FILES = 'Module-Release-*' },
);
Some Makefile.PL's do it slightly differently, by putting all args
into something like %WriteMakefileArgs and then deleting them out
before calling WriteMakefile:
delete $WriteMakefileArgs{LICENSE}
unless eval { ExtUtils::MakeMaker-VERSION(6.31) };
WriteMakefile(%WriteMakefileArgs);
I hope that clarifies what I meant.
-- David
Re: Consensus on MakeMaker vs. Module::Build vs. Module::Install?
On Mon, Mar 22, 2010 at 3:35 PM, Bill Moseley mose...@hank.org wrote: So, I'm curious. Is there any kid of consensus on what to use for new modules and why? Or is it still mostly a matter of opinion? It's completely a matter of opinion. Schwern, who maintains ExtUtils::MakeMaker, has said in the past that people should be using Build.PL. Module::Install gives EU::MM a friendlier interface -- I'd even say a new lease on life -- at the cost of increased complexity from its black box and the risk that you, as a distribution the author, might have to re-release everything if a bug is discovered in Module::Install. Module::Build has gotten much smoother and there's little that Module::Install does that it can't do now (e.g. File::ShareDir support), but still has a bootstrap problem for users of Perl 5.10.1 who haven't upgraded CPAN/CPANPLUS and thus don't have support for configure_requires. I've started using Dist::Zilla, which you can think of as a distribution compiler. It generates all the boilerplate cruft for you, including either a Makefile.PL or Build.PL. It has the benefits of Module::Install of a simpler, declarative interface (actually, just an INI style config file), without the downside of inflicting Module::Install on people who use your module. Unfortunately, right now it's only good for pure Perl distros with only static prerequisites (that describes most of CPAN, though). So... my opinion is: (a) never write an ExtUtils::MakeMaker yourself, it's just too painful to get right (b) if you have to do anything custom in your build or test process -- strongly consider Module::Build because you can customize in Perl, which makes life much easier (c) if you have to do dynamic prereqs or are building XS, use either Module::Install or Module::Build. (d) if you are doing pure perl with static prerequisites, seriously consider Dist::Zilla, or use whichever of Module::Build or Module::Install that you're most familiar with. (e) If you really care about separating requires and build_requires dependencies for downstream users and OS packagers, use Module::Build, which is the only thing that always does it correctly and is supported by CPAN and CPANPLUS. (There is a hack to add BUILD_REQUIRES to ExtUtils::MakeMaker, but it's recent and not well supported.) -- David
Re: ... is just needed temporarily during building or testing. Do you want to install it permanently (y/n) [yes]
On Tue, Mar 9, 2010 at 4:37 AM, Gabor Szabo szab...@gmail.com wrote: CPAN.pm is configured to automatically follow prerequsites but it still stops and ask the question ... is just needed temporarily during building or testing. Do you want to install it permanently (y/n) [yes] Why is that and can I configure the CPAN client to automatically answer yes to such questions? http://search.cpan.org/~andk/CPAN-1.9402/lib/CPAN.pm#Config_Variables build_requires_install_policy to install or not to install when a module is only needed for building. yes|no|ask/yes|ask/no Set that to yes. N.B. As of the latest CPAN.pm development version, the default for that is now yes, the default for the regular prerequisites_policy is follow, and if the latter is follow CPAN now automatically sets the PERL_AUTOINSTALL for default dependencies. That doesn't help people with an existing config, but at least going forward it should be less annoying to new users. -- David
Re: ... is just needed temporarily during building or testing. Do you want to install it permanently (y/n) [yes]
On Tue, Mar 9, 2010 at 7:56 AM, Foo Bar f...@bar.com wrote: http://search.cpan.org/~andk/CPAN-1.9402/lib/CPAN.pm#Config_Variables build_requires_install_policy to install or not to install when a module is only needed for building. yes|no|ask/yes|ask/no Unfortunately that doesn't helpt with == Auto-install the 1 optional module(s) from CPAN? [y] Correct. That's generally the fault of authors using Module::Install with Module::AutoInstall trying to be helpful. You can set various environment variables to avoid those: http://search.cpan.org/~adamk/Module-Install-0.94/lib/Module/AutoInstall.pm#ENVIRONMENT -- David
Re: Dynamic prerequisite installation
On Thu, Mar 4, 2010 at 1:28 AM, cr...@animalhead.com wrote:
as I've done in Makefile.PL below, and use what's available. It's
dynamically installing a module that I'm sending this to ask about.
You don't need to dynamically install a module. You just need to
dynamically create the PREREQ_PM. Then, assuming you're running CPAN
or CPANPLUS, it will read the PREREQ_PM out of your generated
Makefile, detect what's missing and attempt to install it.
if (@enginePrereq) {
# what do I do here to make JS or JE be installed?
}
Nothing. You don't need this
'PREREQ_PM' = {'LWP' = 5.6,
'Scalar::Util' = 0,
'URI' = 1.3,
@enginePrereq}, # all this does is complain
That's correct. It complains. It would complain about URI if you
didn't have URI, too.
You've already done exactly what you need to do. If you're interested
in testing it, try cpan . from the distribution directory. That
should go through the full CPAN install process, including
installation of whatever prerequisite you added.
-- David
Re: PAUSE ID request (FROGGS; Tobias Leich)
Kartik, you can do this yourself on PAUSE. Login and click on the link for Change Permissions. Or just go here: https://pause.perl.org/pause/authenquery?ACTION=share_perms -- David On Thu, Mar 4, 2010 at 7:23 AM, Kartik Thakore thakore.kar...@gmail.com wrote: Hi David, Can FROGGS get co-maint access on SDL modules? Thank you On Thu, Mar 4, 2010 at 7:15 AM, Tobias Leich em...@froggs.de wrote: Hi, I requested a PAUSE ID yesterday and I didnt got an answer till yet. Maybe the spamfilter got it. Can you help me? Thanks, Tobias Leich. -Ursprüngliche Nachricht- Von: Perl Authors Upload Server [mailto:upl...@pause.perl.org] Gesendet: Mittwoch, 3. März 2010 13:38 An: em...@froggs.de Betreff: PAUSE ID request (FROGGS; Tobias Leich) Request to register new user fullname: Tobias Leich userid: FROGGS mail: CENSORED homepage: why: I need to help out KTHAKORE. The following links are only valid for PAUSE maintainers: Registration form with editing capabilities: https://pause.perl.org/pause/authenquery?ACTION=add_userUSERID=6110_10a44684a7e33a85SUBMIT_pause99_add_user_sub=1 Immediate (one click) registration: https://pause.perl.org/pause/authenquery?ACTION=add_userUSERID=6110_10a44684a7e33a85SUBMIT_pause99_add_user_Definitely=1
Re: MYMETA.yml vs. SIGNATURE
I'm going to step *way* back in this discussion. I've been able to
replicate the issue, which is the first step to finding a thoughtful
resolution:
(1) All prerequisites to actually run the signature test file are
satisfied. (E.g. $ENV{TEST_SIGNATURE}, etc.
(2) MANIFEST.SKIP is in MANIFEST.SKIP and thus not added to MANIFEST
or copied to the distdir (where the signature test is actually run)
(3) ExtUtils::Manifest version prior to 1.58
(4) Run: perl Build.PL, ./Build disttest
Thus, two solutions immediately present themselves:
(a) Do *not* skip MANIFEST.SKIP. This ensures that it winds up in
distdir (including the explicit skip of MYMETA.yml).
(b) Upgrade ExtUtils::Manifest to 1.58 (which includes MYMETA among
the default skip list when no MANIFEST.SKIP exists)
Both solutions work independently. I recommend doing both of them, on
the off chance that some end user just happens to have set
TEST_SIGNATURE and has a old version of ExtUtils::Manifest.
-- David
Re: Meta.yml spec
On Thu, Feb 18, 2010 at 1:49 PM, David Precious dav...@preshweb.co.uk wrote: I think Ivan's point was more that the repo URL in question does not actually appear anywhere within the VCS::Which distribution: http://search.cpan.org/grep?cpanid=IVANWILLSrelease=VCS-Which-v0.1.2string=github Odd indeed. Ah. Yes, that's odd. Worth reporting to the CPANTS admin.
Re: Module::Build and ActiveState
On Wed, Jan 6, 2010 at 11:03 AM, Klaus klau...@gmail.com wrote: I have a patch that fixes those problems. 3 modules are to be patched: ActivePerl::DocTools::Pod, ExtUtils::Command::MM and Module::Build::Base. Who do I need to contact to have all 3 modules patched at the same time ? For Module::Build, please open an RT ticket with the patch and I or someone else will get around to it in due time: http://rt.cpan.org/NoAuth/Bugs.html?Dist=Module-Build For ExtUtils::Command::MM, you need to contact Schwern, either directly by email or via the RT queue for ExtUtils-MakerMaker: http://rt.cpan.org/NoAuth/Bugs.html?Dist=ExtUtils-MakeMaker I have no idea who you need to contact at ActiveState. Regards, David
Re: Perl 6 and the CPAN?
I suggest taking this up on the cpan-workers list instead of module-authors. David On Sat, Jan 2, 2010 at 10:26 AM, Ovid publiustemp-moduleautho...@yahoo.com wrote: Hi all, I've started writing Config::INI, an INI reader/writer in Perl 6. It's on github at http://github.com/Ovid/Config-INI. This has raised several interesting issues, but the most important is that I didn't check the CPAN, but it turns out Ricardo Signes has a Perl 5 version: http://search.cpan.org/dist/Config-INI/. Can we have identically named P5 and P6 modules on the CPAN? We should be able to, but I don't that will actually fly. I know there was a fair chunk of discussion regarding Perl 6 on the CPAN, but have we gotten anywhere? More and more Perl 6 code is being written and sooner or later, people would like someplace to put it other than github or code.google.com :) Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Announcing Module::Build version 0.36
After four months of development and 15 development releases along the way, I'm pleased to announce that Module::Build 0.36 is now on CPAN. Version 0.36 will also be included in the next release of the Perl 5.11.X development series. For more, see http://search.cpan.org/dist/Module-Build-0.36/ I would like to thank everyone who contributed patches, suggestions, testing or other support to enable this release. -- David Here is a summary of major changes since 0.35: Enhancements: - Added 'Build installdeps' action to install needed dependencies via a user-configurable command line program. (Defaults to 'cpan'.) - Command line options may be set via the PERL_MB_OPT environment variable (similar to PERL_MM_OPT in ExtUtils::MakeMaker) - Generates MYMETA.yml during Build.PL (new standard protocol for communicating configuration results between toolchain components) - Reduced amount of console output under normal operation (use --verbose to see all output) - Added experimental inc/ bundling; see Module::Build::Bundling for details. New or changed properties: - Added 'share_dir' property to provide File::ShareDir support; File::ShareDir automatically added to 'requires' if 'share_dir' is set - Added 'needs_compiler' property. Defaults to true if XS or c_source exist. If true, ExtUtils::CBuilder is also added to build_requires. - 'C_support' is no longer an optional feature. Modern ExtUtils::CBuilder and ExtUtils::ParseXS added to the 'requires' list. This ensures that upgrading Module::Build will upgrade these critical modules. - Clarified that 'apache' in the license attribute indicates the Apache License 2.0 and added 'apache_1_1' for the older version of the license (RT#50614) Deprecations: - Module::Build::Compat 'passthrough' style has been deprecated. Using 'passthrough' will issue warnings on Makefile.PL generation. See Module::Build::Compat documentation for rationale. Internals: - Replaced use of YAML.pm with YAML::Tiny; Module::Build::YAML is now based on YAML::Tiny as well - A new get_metadata() method has been added as a simpler wrapper around the old, kludgy prepare_metadata() API. - Replaced guts of new_from_context(). Build.PL is now executed in a separate process before resume() is called. (This is generally only of interest to Module::Build or toolchain developers) (RT#49350) - Add support for 'package NAME VERSION' syntax added in Perl 5.11.1 Notable bug fixes: - The test action now dies when using the 'use_tap_harness' option and tests fail, matching the behavior under Test::Harness. (RT#49080) [initial patch from David Wheeler; revised by David Golden] - Updated PPM generation to PPM v4 (RT#49600) [Olivier Mengue] - When module_name is not supplied, no packlist was being written; fixed by guessing module_name from dist_version_from or the directory name (just like ExtUtils::Manifest does without NAME) [David Golden] - Failure to detect a compiler will now warn during Build.PL and be a fatal error when trying to compile during Build. (RT#48918) [David Golden] - Auto-detection of abstract and author fixed for mixed-case POD headers (RT#51117) [David Wheeler] - resume() was not restoring additions to @INC added in Build.PL (RT#50145) [David Golden] - When tarball paths are less than 100 characters, disables 'prefix' mode of Archive::Tar for maximum compatibility (RT#50571) [David Golden] - Merging 'requires' and 'build_requires' in Module::Build::Compat could lead to duplicate PREREQ_PM entries; now the highest version is used for PREREQ_PM. (RT#50948) [David Golden] - Module::Build::Compat will now die with an error if advanced, non-numeric prerequisites are given, as these are not supported by ExtUtils::MakeMaker in PREREQ_PM [David Golden]
Fwd: MANIFEST (Makefile.pl) ignore Mercurial files
On Thu, Dec 17, 2009 at 6:18 AM, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: I have a standard MANIFEST.SKIP... For anyone interested, the ExtUtils-Manifest module comes with a very nice default MANIFEST.SKIP as part of the distribution: http://cpansearch.perl.org/src/RKOBES/ExtUtils-Manifest-1.58/lib/ExtUtils/MANIFEST.SKIP Here's a quick way to copy it to your directory: $ perldoc -m ExtUtils::MANIFEST.SKIP MANIFEST.SKIP It doesn't have Mercurial's .hg files, but I bet Randy would take a patch for it. :-) -- David signature.asc Description: PGP signature
Re: flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
On Wed, Nov 18, 2009 at 9:20 AM, Jonathan Yu jonathan.i...@gmail.com wrote: Certainly I've found for tight loops with lots of calculations, XS/C is going to be faster. Why? Because it's compiled into machine code and executed directly on the chip. On the other hand, Perl is compiled into bytecode which is then executed by the Perl Virtual Machine. That's one piece of it, but the other part is that any tight loop that is creating and destroying Perl primitives picks a lot of overhead. As an example, Vincent Pit just did some recent work in blead to optimize in-place array reversal in void context: @array = reverse @array; When this pattern is detected, the optimization just fiddles the internal pointers within the AV structure instead of reversing the array to a temporary list and then assigning it back. Vincent benchmarked it as several *orders of magnitude* faster (particularly as the array size grows). So creating/destroying Perl objects -- even just for things like argument passing on the stack -- is part of the cost of the flexibility of Perl. When that becomes a bottleneck in a tight loop, that's when XS becomes a potential option. That's not a knock on Perl -- that's just part of the design. -- David
Re: Weekend entertainment
On Sun, Nov 15, 2009 at 6:51 AM, David Landgren da...@landgren.net wrote: I wanted to share this... Some people have no sense of humour. This came up on the cont...@perl.org queue. (I shall compose a message saying Acme is fun, etc. etc. Can anyone point me to other similar Acme modules to put this in context?) I think the module is offensive -- which is not inconsistent with it trying to be funny Funny and offensive is sometimes a fine line. I'm not saying it needs to be yanked -- I don't support censoring bad thoughts. I would rather see the author withdraw it voluntarily. Even in Acme, I'd rather see the Perl community trying to be inclusive and not make jokes at anyone's expense. People do remember Alias' ill-considered Acme::Playmate talk, right? (And his very responsible apology afterwards, too) http://geekfeminism.wikia.com/wiki/Acme::Playmate_talk -- David
Re: Weekend entertainment
On Sun, Nov 15, 2009 at 11:55 AM, Jerry D. Hedden jdhed...@cpan.org wrote: Consider Jeff Foxworthy making fun of rednecks. How is that different? (Apologies if redneck jokes are too obscure for the non-Americans reading this thread.) Jeff Foxworthy is a comedian. (Damn good one, too!) But his comedic persona is that of a redneck, so his comedy is less offensive because he is poking fun at himself. And his redneck jokes are defined by behaviors and circumstance, not geography or innate characteristics of people. E.g. from his site today: You might be a redneck if your Christmas ornaments are made out of spent shot-gun shells. (And maybe I'm guilty of stereotyping, but I suspect that Jörg Walter is not a Nigerian spammer.) As the module doesn't border on a hate crime, I see not reason to even suggest that the author consider a voluntary withdrawal. I meant only that I would hope the author's attitude would be oops, sorry, I was trying to be funny and didn't mean to offend anyone which I think is just a decent way to treat other human beings. Again, a few people that can't take a joke. You can't please all the people all the time. So true. -- David
Re: Why you don't want to use /dev/random for testing
On Tue, Nov 10, 2009 at 10:01 PM, cr...@animalhead.com wrote: Many of you know that the random number generator /dev/random is subject to delays when it has not accumulated enough entropy, which is to say randomness. These delays are said to be longer on Linux /dev/random that on some other Unices. They occur particularly after a system is booted, which I hear is a regular occurrence on some smoke-test systems. FWIW, I did a visitcpan scan of distributions that match the string /dev/random/ in lib/. No guarantees that they actually *use* it -- they might just mention it in comments/docs, but here's a watch list that might need further exploration: ADAMK/Crypt-DSA-1.16.tar.gz AWKAY/Apache/Apache-SiteControl-1.01.tar.gz AWKAY/Apache2/Apache2-SiteControl-1.05.tar.gz BOBTFISH/Catalyst-Plugin-Session-0.29.tar.gz CHROMATIC/Crypt-CipherSaber-1.00.tar.gz CZBSD/Myco-0.01.tar.gz DAGOLDEN/Getopt-Lucid-0.18.tar.gz DMALONE/Crypt-IDA/Crypt-IDA-0.01.tar.gz DMUEY/Data-Rand-0.0.4.tar.gz FLORA/Net-SSLeay-1.35.tar.gz FREQUENCY/Math-Random-ISAAC-1.001.tar.gz JDHEDDEN/Math-Random-MT-Auto-4.13.00.tar.gz JDHEDDEN/Math-Random-MT-Auto-6.14.tar.gz JHOWELL/FAQ-OMatic-2.717.tar.gz JHOWELL/FAQ-OMatic-2.719.tar.gz JMASON/IPC-DirQueue-1.0.tar.gz MBROOKS/String-Urandom-0.10.tar.gz MSCHOUT/Apache-AuthTicket-0.90.tar.gz MUIR/modules/Qpsmtpd-Plugin-Quarantine-1.02.tar.gz NUFFIN/Crypt-Random-Source-0.03.tar.gz OPI/Apache2-POST200-0.05.tar.gz PTANDLER/PBib/Bundle-PBib-2.08.01.tar.gz PTANDLER/PBib/Bundle-PBib-2.08.tar.gz SMUELLER/Statistics-Test-RandomWalk-0.01.tar.gz SMUELLER/Statistics-Test-Sequence-0.01.tar.gz SOMMERB/Myco-1.22.tar.gz VIPUL/Crypt-Random-1.25.tar.gz ZEFRAM/Data-Entropy-0.005.tar.gz -- David
Re: Why you don't want to use /dev/random for testing
On Wed, Nov 11, 2009 at 2:40 PM, Jonathan Yu jonathan.i...@gmail.com wrote: I'm not sure how many of these modules use it -- in particular, I know Math::Random::ISAAC only mentions it in POD. Using /dev/random isn't very portable -- what happens when you're on Windows? Some things may check for it and fall back to other options. Or, as often happens, people release distributions to CPAN without ever knowing (or caring) whether they are portable to Windows. As I said, I just grepped for the string in lib/ as a quick way to get a short list. David
Re: Repository links in META/Pod should be http://
On Oct 31, 2009 6:38 PM, Ricardo Signes perl.moda...@rjbs.manxome.org wrote: * Burak Gürsoy burakgur...@gmx.net [2009-10-31T18:13:05] I see that some modules have git:// protocol as the repo address in META.yml and/or Pod. I don't... I'm strongly opposed. There might not be any HTTP URL to my repositor, even though a CVS or Git URL may exist. There's no reason to require things to be clickably just to support some closed-source application that is only one way to access things. -- rjbs
Re: Repository links in META/Pod should be http://
Its also largely irrelevant, since the 2.0 META spec will distinguish between repo and browseable interface. David On Oct 31, 2009 6:38 PM, Ricardo Signes perl.moda...@rjbs.manxome.org wrote: * Burak Gürsoy burakgur...@gmx.net [2009-10-31T18:13:05] I see that some modules have git:// protocol as the repo address in META.yml and/or Pod. I don't... I'm strongly opposed. There might not be any HTTP URL to my repositor, even though a CVS or Git URL may exist. There's no reason to require things to be clickably just to support some closed-source application that is only one way to access things. -- rjbs
Re: How can I tell MakeMaker to insert recommended modules into META.yml?
On Sat, Oct 17, 2009 at 7:46 AM, Hans Dieter Pearcey hdp.perl.module-auth...@weftsoar.net wrote: There are a number of problems with this, but the biggest is that nothing really does anything with 'recommends' in META.yml, so your audience is basically going to be the people who go and read it themselves. Not yet. But maybe for Christmas... :-) As the CPAN Meta Spec 2.0 is finalized around December, I would expect that there will be effort put into CPAN.pm and CPANPLUS to do something sensible with optional dependencies like that. -- David
Re: How to best detect availability of C compiler in Makefile.PL?
On Tue, Oct 13, 2009 at 9:29 AM, O. STeffen BEYer ost...@gmail.com wrote: Hi Ryan, thanks a lot for your fast response (see a copy at the bottom of this message for convenience)! See also Devel::CheckLib, which can check for a compiler for you (just don't specify a lib) and has a handy command line utility to bundle itself in inc/ and add itself to your *.PL file. But how would I then test both module versions (Date::Calc and Date::Pcalc) with the same test suite, without duplicating code? See Test::NoXS, which disables dynamic loading. I would put the tests into functions in a utility module in t/ and have separate .t files for XS and PP. The PP one should use Test::NoXS (with your module name as an argument), then load your module, then run the tests from your utility module. And how would I rely on the Perl version in the C/XS version if something goes wrong? Something along these lines? Pretty much. I'd suggest copying what List::Util does. -- David
Re: Questions about encouraging testers
On Mon, Sep 21, 2009 at 12:13 AM, cr...@animalhead.com wrote: Most automated smoke testing will just quietly exit and continue. The testers will never see the prompt. This is generally how automated testers like it (though there are exceptions). Stopping at every Nth module to figure out how to resolve someone's custom dependency takes extra time that donating some CPU cycles to the testing effort does not. The idea that you and http://wiki.cpantesters.org/wiki/CPANAuthorNotes would recommend Devel::CheckLib as a means to handle a dependency on a C library, and that the smoke testing SW does not pick up on its output and tell the tester about the dependency, is slightly mind- boggling. It's a compromise. You and other authors don't like seeing FAIL and UNKNOWN reports when a dependency couldn't be met. But CPAN Testers is a decentralized, volunteer effort. Adding a new grade NOPREREQ or whatever would mean writing a bunch of code, getting everyone to upgrade and so on. We discovered that exit 0 would shortcut the process. It was an immediate fix with no code to write and supported by all known versions of CPAN/PLUS. Perhaps in the future, this will change. Just for the record, I've installed it now and will attempt to send a test report. What I've noticed so far is that some of the test files are very slow and in other circumstances I might have hit CTRL-C by now. You might want to warn( # this test may take a long time to finish\n) or something for the longer-running test files. That sounds fishy. Here's the ending line from make test on my server: Files=10, Tests=6744, 3 wallclock secs ( 1.12 usr 0.18 sys + 1.87 cusr 0.43 csys = 3.60 CPU) Or is your CTRL-C finger really twitchy? It was probably 30 wall clock seconds for me. I'll send you output off-list. On the flip side, I just found a new version of ExtUtils::ParseXS (which I require to avoid certain false error messages), in which the Changes file says: 2.200401 - Mon Sep 14 22:26:03 EDT 2009 - No changes from 2.20_04. Which makes me feel like version number selection is like playing the stock market. Which I'm also not good at... I use a very specific pattern. In this case, chronologically: * 2.20 - stable release * 2.20_01 - dev release * 2.2002 - Makefile.PL fix -- stable release bump for Perl 5.10.1 core * 2.20_03 - dev release * 2.20_04 - dev release * 2.20_05 - dev release (lots of FAIL here, though) A special request was made from some authors to get a new release out to fix a major bug on 5.8 series perls. I judged 2.20_05 too unstable to release, so went back to 2.20_04 as the best candidate for a stable release * 2.200401 Davi
Re: Location of MyConfig.pm governing cpan configurations changed involuntarily
On Sun, Sep 20, 2009 at 9:05 AM, James E Keenan jk...@verizon.net wrote: 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. As always, the story is complicated. The problem is that Application Support has a space in the name and CPAN's default '.build directory (where distributions are unpacked and tested before installation) is placed under that .cpan path. Many parts of the Perl toolchain and various distribution's test files have problems when cwd is a path with spaces. 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: cpan o conf build_dir /your/preferred/path/here cpan o conf commit A proposed fix was for CPAN to use a File::HomeDir-my_dot_config method that would place unix-style dot-configs under the home directory. This was added to File::HomeDir around 0.71_02, but was removed in 0.80 (without any mention in the Changes file). It was only recently that this removal was discovered, and so we're back to much the same situation as we started. History of the issue is here: http://rt.cpan.org/Public/Bug/Display.html?id=32841 -- David
Re: Questions about encouraging testers
On Sun, Sep 20, 2009 at 8:51 PM, cr...@animalhead.com wrote:
1. Why are there so few test reports? Supposedly the prompt( Please enter
path...)
which is provided by ExtUtils::MakeMaker, will not hang but will sense
the smoky
environment and return the default from $libpath. check_lib_or_exit will
then
report the problem in a way that will inform the tester of the need for
the library.
Right?
Most automated smoke testing will just quietly exit and continue. The
testers will never see the prompt. This is generally how automated
testers like it (though there are exceptions). Stopping at every Nth
module to figure out how to resolve someone's custom dependency takes
extra time that donating some CPU cycles to the testing effort does
not.
OS assertions and check_lib_or_exit() are all just trying to make it
easier for authors to get quality reports. It's an arrangement
between testers and authors: if authors bail out in certain ways, then
testers won't hit the distribution with meaningless reports.
NOTE -- exit 0 means that *no* report is sent. Not even an
UNKNOWN. This is just like what happens with Perl prerequisites. If
a prerequisites can't be satisfied, then no report is sent.
2. Do you think the following start for Makefile.PL would lead to more test
reports?
I think the most effective thing that will lead to more test reports
is asking people to install libmm-dev. That's best done via personal
appeal on the cpan-testers-discuss or on #cpantesters-discuss on
irc.perl.org. That means work for someone who maintains multiple
virtual machines, so ask nicely. ;-)
Just for the record, I've installed it now and will attempt to send a
test report. What I've noticed so far is that some of the test files
are very slow and in other circumstances I might have hit CTRL-C by
now. You might want to warn( # this test may take a long time to
finish\n) or something for the longer-running test files.
However, for the Makefile.PL itself, t would be much better to assume
that the library can be found and only prompt afterwards if it can't
be found: E.g.
use lib inc;
use Devel::AssertOS qw(Unix OS390 BeOS Cygwin);
use Devel::CheckLib;
use ExtUtils::MakeMaker;
eval { assert_lib( lib= mm ) };
if ( $@ ) {
print \nIPC::MMA requires the mm library, which is available .
at http://www.ossp.org/pkg/lib/mm/\n;;
$libpath = prompt( Please enter path to libmm.so:, /usr/local/lib);
check_lib_or_exit( lib = 'mm', libpath = $libpath );
}
# Makefile.PL continues ...
That's much friendlier when I've used my system's package manager to
just install the package and it winds up in /usr/lib.
3. If #2 is yes and I submit a new version with the above Makefile.PL,
should I call it 0.59 or 0.58_01? There hasn't been a significant change
to the module itself since 0.54.
Personally, if nothing has changed in the module itself since 0.54, I
probably would have numbered subsequent modules 0.54_01, 0.54_02, etc.
Given where you are now, I would use 0.58_01, 0.58_02, etc. It
indicates to anyone using your modules that you're just doing
development work and that they don't (necessarily) need to upgrade
just yet. The automated CPAN Testers will all test any distribution
you release, so the number doesn't matter.
Or putting it differently, if you're tweaking Makefile.PL and break
something, keeping it as an alpha release means you won't cause
problems for anyone who wants to install your module for non-testing
purposes.
Regards,
David
Re: how to set $VERSION throughout distribution
On Mon, Sep 14, 2009 at 1:21 PM, Bill Ward b...@wards.net wrote: Subversion is more like mercurial/git in that sense - versions go by changesets rather than individual files. I think he meant it in the sense of having a monotonically increasing revision number, which doesn't exist for git. -- David
Re: how to set $VERSION throughout distribution
On Sun, Sep 13, 2009 at 10:45 AM, Jerry D. Hedden jdhed...@cpan.org wrote: package Workflow; use Workflow::VERSION; $Workflow::VERSION = $Workflow::VERSION::VERSION; This sort of strategy caused problems with the CPANPLUS module code awhile back in that the 'cpan-r' command showed its submodules to have no version numbers. Not sure if that's all been fixed now, but it did illustrate to me that trying to set versions via a version module is not a robust scheme. I suspect that to work correctly with ExtUtils::MM-parse_version (the canonical way to get a module version without actually loading the module), it would need to be like this: package Workflow; use Workflow::VERSION; $Workflow::VERSION=$Workflow::VERSION::VERSION; parse_version() does an eval() on a single line. This is why there is the idiom for version.pm: use version; our $VERSION = version-new(v1.2.3); -- David
Re: how to set $VERSION throughout distribution
On Sun, Sep 13, 2009 at 4:25 PM, Jerry D. Hedden jdhed...@cpan.org wrote: I use the three number form: $VERSION = q(v1.2.3); This may cause problems because it makes $VERSION a string, namely, v1.2.3. This prohibits numeric version comparisons which is the norm. The quoting definitely will cause some issues. v-strings by themselves ($VERSION = v1.2.3) generally will work OK, *except*: * Parts of the toolchain (e.g. ExtUtils::MakeMaker) can't deal with v-strings in PREREQ_PM. * Foo-VERSION will return different things depending on the version of perl and whether version.pm was loaded (by *any* module anywhere in the process). * Never use alpha v-strings, e.g. v1.2_4. How that behaves is radically different on older versions of perl. * If users say use Foo 1.002003 because they are used to specifying use 5.006002 for perl 5.6.2, this could fail on perl's compiled for long doubles with the bizarre error: Foo version 1.002003 required--this is only version 1.002003 It also means your CPAN modules will get called something like Mod-Name-v1.2.3.tar.gz which is also non-standard. It's no longer non-standard, at least as far as PAUSE and the toolchain are concerned. In fact, it's likely to become standard, following the convention that all dotted-integer versions should be expressed in normal form with the leading v. I still recommend decimal $VERSION numbers, with eval afterwards to clean up alpha version. Gory $VERSION details here: http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/ -- David
Re: Developer releases?
2009/9/5 Burak Gürsoy burakgur...@gmx.net: From: Shmuel Fomberg [mailto:semu...@012.net.il] what did I do wrong? Your distro version does not have the underscore, so it's not marked as a dev release. You should quote the version. i.e.: our $VERSION = '0.26_01'; A bare underscore in numbers are ignored. So that you could write a million as: 1_000_000 instead of 100. For more on how to deal with version numbers for distributions, see: http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/ David
CPAN Upload: D/DA/DAGOLDEN/Module-Build-0.35.tar.gz
I have just released the new major-version release of Module::Build. Many thanks to those who contributed bug reports and patches. A list of changes since 0.34 follows. -- David 0.35 - Thu Aug 27 09:12:02 EDT 2009 Bug fixes: - Fix t/destinations.t segfault on 5.6.2 0.34_06 - Sat Aug 22 21:58:26 EDT 2009 Bug fixes: - Multiple test fixes for OS2 [Ilya Zakharevich] - Generated.ppd files use :utf8 if possible (RT#48827) [Olivier Mengue] - Fixed preservation of custom install_paths on resume (RT#41166) [David Golden] - Warn instead of crashing when Pod::Man tries to create files with colons on vfat partitions on unix (RT#45544) [David Golden] 0.34_05 - Sun Aug 9 22:31:37 EDT 2009 Bug fixes: - When auto_configure_requires is true (the default), Module::Build will only add last 'major' version of Module:Build (e.g. 0.XX) to configure_requires to avoid specifying a minor development release not available on CPAN [David Golden] 0.34_04 - Sat Aug 8 11:02:24 EDT 2009 Other: - Added documentation warning that 'get_options' should be capitalized to avoid conflicting with future Module::Build options and changed the examples accordingly. 0.34_03 - Sat Aug 8 07:39:16 EDT 2009 Bug fixes: - Fixed failing xs.t if /tmp is mounted noexec (RT#47331) [David Golden] - Fixed failing debug.t on VMS (RT#48362) [Craig Berry] - Prevent par.t from dying on error in .zip extraction [David Golden] - Fixed potential runthrough.t failure on 5.6.2 [David Golden] Other: - Archive::Tar changed from 'requires' to 'recommends' so non-authors without IO::Zlib can still use Module::Build to install modules [reported by Matt Trout, fix by David Golden] 0.340201 - Sun Aug 9 22:11:04 EDT 2009 Other: - Version bump for Perl core for 5.10.1 release; no other changes 0.34_02 - Sun Jul 26 22:50:40 EDT 2009 Bug-fixes: - Bundled Module::Build::Version updated to bring into sync with CPAN version.pm 0.77 [John Peacock] 0.34_01 - Sat Jul 18 16:32:09 EDT 2009 Enhancements: - Added --debug flag to trace Build action execution (RT#47933) [David Golden] Bug-fixes: - Bundled Module::Build::Version version code updated to fix unsafe use of $@ (RT#47980) [John Peacock]
Re: XML::Rules new versions not seen by CPAN shell
On Thu, Aug 27, 2009 at 10:33 AM, David Cantrellda...@cantrell.org.uk wrote: CPAN.pm already tells you if a new CPAN.pm is available, I'm simply proposing extending that because no-one knows that the 'r' command exists. I certainly didn't. I like that idea. Also, note that this time round I've moved the warning to the end. That way it doesn't just disappear off the top of the screen, it's there in your face when the install finishes. I think that it should warn at the same time as CPAN warns about a newer version of itself -- which is at the start when you run the CPAN shell. However, I think the cpan program should warn at the end. That probably will take a little refactoring, but seems very reasonable. -- David
Re: XML::Rules new versions not seen by CPAN shell
On Thu, Aug 27, 2009 at 7:09 PM, Eric Wilhelmenoba...@gmail.com wrote: # from David Cantrell # on Thursday 27 August 2009 07:33: WARNING: there are new versions of Module::Build and Module::Install available, it is strongly recommended that you upgrade them CPAN.pm already tells you if a new CPAN.pm is available, ... Except then it also needs to tell you that there's a new Module::Starter and Dist::Zilla and App::Builder and Tool::Belt and ... I'd limit it to toolchain modules that are dual-life CPAN and Perl core. So M::B, EU::MM, EU::Install, etc. Not the rest of the toolbelt. David
Call for proposals: CPAN META Spec
[Reposted from http://www.dagolden.com/index.php/458/call-for-proposals-cpan-meta-spec/ ] The CPAN META Spec is the basis for the META.yml metadata files included in most modern CPAN distributions. Since the spec was last updated two years ago, there have been suggestions in many forums for how it could be improved in clarity or functionality, but nothing has been done. To move from ideas to implementation, I have convened a working group of Perl/CPAN toolchain developers, maintainers, packagers and indexers -- the people responsible for the tools you use to configure, build, install or search for CPAN modules -- to review proposals, reach consensus and ultimately implement a new CPAN META Spec. To ensure that we benefit from the best ideas in the Perl community, on behalf of this working group, I am issuing a public call for proposals. Process Here is the process and timeline: 1. Add proposals to the CPAN Meta Spec Proposals page on the Perl QA Wiki. Discussion and refinement is encouraged through the discussion page on the wiki or on the cpan-workers mailing list (see below for details) 2. The Call for Proposals will close on Oct. 1, 2009. 3. The working group will post proposals on the cpan-workers mailing list for public discussion 4. Public discussion will close on Nov. 1, 2009. 5. The working group will reach consensus on proposals to adopt or reject and release a new CPAN META Spec no later than Dec. 1, 2009. Criteria Since the work of implementation requires volunteer effort, the working group is looking for incremental improvements rather than complete rewrites of the spec. Proposal are more likely to be adopted if they: * Improve clarity or resolve ambiguity * Are narrow in scope * Address specific, current deficiencies * Are consistent with the general style of the existing spec * Require minimal implementation effort Resources The current spec: Browse the current spec, as converted to HTML, here: http://module-build.sourceforge.net/META-spec.html. The repository: The official spec draft file, META-spec.pod, has been moved from the Module-Build repository into its own repository on github. Please feel free to include proposed patches as part of proposals: * Repository: git://github.com/dagolden/cpan-meta-spec.git * Browser: http://github.com/dagolden/cpan-meta-spec/ The wiki: Proposals will be kept on the Perl QA Wiki: http://perl-qa.hexten.net/wiki/index.php/CPAN_Meta_Spec_Proposals The mailing list: Subscribe to cpan-workers by emailing cpan-workers-subscr...@perl.org. List archives are available at http://www.mail-archive.com/cpan-work...@perl.org/
Re: XML::Rules new versions not seen by CPAN shell
On Tue, Aug 25, 2009 at 4:38 AM, Jenda Krynickyje...@krynicky.cz wrote: Is there any problem in the way I built the modules (using Module::Build 0.2808)? Or is there anything wrong with the CPAN indexer or something??? 1.05 is the version listed in the CPAN index file, so for whatever reason the other uploads were not indexed. (Did you keep the emails from PAUSE when you uploaded? Did you *read* them?) Login to PAUSE and request re-indexing. If it's not successful, you should get an email about it. If not, email upl...@pause.perl.org to ask about it. -- David
Re: XML::Rules new versions not seen by CPAN shell
On Tue, Aug 25, 2009 at 6:56 PM, Jenda Krynickyje...@krynicky.cz wrote: On the other hand let me express my dissatisfaction with this undertested, underannounced, abrupt and pretty annoying change. It was in response to a perceived security hole. So yes, it was underannounced and yes that's annoying. Whoever decided to implement this OS SPECIFIC restriction should have at least made sure Module::Build produces conforming distributions under operating systems with different permission system, should have made sure search.cpan.org does display a warning AND SHOULD HAVE SENT A FEW ANNOUNCEMENTS. Instead of causing problems for anyone and everyone who happens to use something else than the one true actually supported OS. It's really lovely if we have to bend twice backwards to pass a restriction due to something related to a different OS. Especially if we are uploading a Win32::xxx module. It's not an OS specific restriction. It happens to impact Windows authors most. Announcements were sent to authors as problems were detected -- such as the email you apparently didn't see -- which, you'll note, includes a fixed tarball and a link to instructions for how to keep it from happening again. So it's not like whoever didn't understand that it was an annoying change. Never mind, I'll somehow get the fixed Module::Build installed and go over all my modules and see what version does the cpan shell see. Install Archive::Tar. Upgrade Module::Build. That should fix it for you. If not, email me directly and I'll take it up on #toolchain. I do wonder how many modules (or updates) are there on CPAN, that cannot be installed using the cpan shell due to this. These are the distribution in my CPAN::Mini::Devel that are not alpha, not indexed, have world-readable files/directories and were released after the change. They could be unauthorized in which case they wouldn't be indexed anyway, but I don't have access to that database offhand. ACID/Hyper-v0.05.tar.gz AERO/Lingua-KO-DateTime-0.03.tar.gz BROWSERUK/Devel-Size-0.72.tar.gz CPKOIS/BluepayBluepay20Post/Bluepay-Bluepay20Post-0.15.tar.gz CPKOIS/BluepayBluepay20DailyReport/Bluepay-Bluepay20DailyReport-0.20.tar.gz DAUNAY/oEdtk-0.421.tar.gz JAMES/Test-Email-0.07.tar.gz JENDA/Hash-WithDefaults-0.05.tar.gz JENDA/XML-Rules-1.08.tar.gz JENDA/Interpolation-0.73.tar.gz JENDA/Exception-Class-Nested-0.04.tar.gz LARSLUND/PDF-Reuse-Barcode-0.06.tar.gz LGODDARD/List-Member-0.044.tar.gz LITCHIE/Hardware-Simulator-MIX-0.5.tar.gz MAKAROW/DBIx-Web-0.79.tar.gz MAKAROW/Sys-Manage-0.62.tar.gz RGARTON/Statistics-SDT-0.034.tar.gz SADAHIRO/Unicode-Normalize-1.03.tar.gz SANKO/Acme-CPANAuthors-Acme-CPANAuthors-Authors-0.1240065387.tar.gz SCHNUECK/Weather-Com-0.5.5.tar.gz SFLEX/AUBBC-2.0.tar.gz SHARDIWAL/Bio-Tools-CodonOptTable-0.07.tar.gz SHARDIWAL/Badge-GoogleTalk-0.0.02.tar.gz TDEITRICH/Device-Jtag-USB-FTCJTAG-0.11.tar.gz -- David
Re: XML::Rules new versions not seen by CPAN shell
On Tue, Aug 25, 2009 at 10:20 PM, Bill Wardb...@wards.net wrote: Do I understand this right? If a tar file contains a directory with permissions 777 - as would be likely to happen if it was made on Windows - then PAUSE rejects it? Why doesn't PAUSE just modify the permissions in the tarfile and publish the resulting file? I believe the view is that PAUSE shouldn't modify what you upload. David
ExtUtils-ParseXS-2.20_05 - release candidate
Dear module authors, I have uploaded a new development release of ExtUtils::ParseXS: DAGOLDEN/ExtUtils-ParseXS-2.20_05.tar.gz This is a release candidate for 2.21. If you maintain or depend on an XS module, please test it with this new version of ExtUtils::ParseXS and report any problems to the RT queue: http://rt.cpan.org/Dist/Display.html?Queue=ExtUtils-ParseXS Thank you. David Golden
Module-Build-0.34_06
Dear module authors, I have uploaded a new development release of Module::Build: DAGOLDEN/Module-Build-0.34_06.tar.gz This is a release candidate for 0.35. If you use Module::Build, please test with this new version of Module::Build and report any problems to the RT queue: http://rt.cpan.org/Dist/Display.html?Queue=Module-Build Thank you. David Golden
Re: splitting up a monolithic distribution - bioperl
libwin32 did it. It wasn't that many dists. Jan Dubois might have pointers. The thing that jumps out to me as a potential problem is dependencly management. Particularly, if anything is mutually dependent, they should stay in the same dist. David On Aug 17, 2009 8:29 AM, Chris Fields cjfie...@illinois.edu wrote: All, Immediately after the next bioperl release in the next few weeks, we plan on splitting up bioperl 'core' (~900 or so modules?!?) into separate focused distributions. This has been long overdue but delayed for many reasons, primarily b/c no one wants to take it on. Is there a precedent for something like this? Any suggestions would be very welcome. chris
Re: New module: Alien::SDL
On Fri, Aug 7, 2009 at 8:21 AM, Kartik Thakorethakore.kar...@gmail.com wrote: either source or binaries. Since this will be my first CPAN module, how do I upload the module? I already have a cpan account. Read the instructions: https://pause.perl.org/pause/authenquery?ACTION=pause_04about Upload here: https://pause.perl.org/pause/authenquery?ACTION=add_uri -- David
Re: Perl Monks compromised, PAUSE accounts at risk
On Thu, Jul 30, 2009 at 10:00 AM, Andy Lestera...@petdance.com wrote: On Jul 30, 2009, at 8:58 AM, imacat wrote: Dear all, I received this mail today. Is this real? Or is it another phishing? It's real. I wrote the script. Andreas Koenig sent it out. http://www.dagolden.com/index.php/358/perl-whipupitude-to-the-rescue/ -- David
Re: Perl Monks compromised, PAUSE accounts at risk
2009/7/30 Burak Gürsoy burakgur...@gmx.net: BTW, I really *hope* that PAUSE is not dumb like PM to store passwords as plain text? The passwords on PAUSE are hashed, not plain text. The plain text passwords from Perl Monks are being hashed to find matches and matching accounts are being dealt with. -- David
Re: Test Failures - XS, does not match bootstrap parameter and version objects
On Tue, Jul 28, 2009 at 1:57 PM, Martin J. Evansmartin.ev...@easysoft.com wrote: I think a new version of version.pm was made available a few days ago by David Golden (0.77). You fails results seem to mention if (0.77). Perhaps this is the cause. I've cc'ed David just in case (apologies if I'm off the mark on this David). There was a new release, but I'm not the owner. But I'll look into this when I get a chance. I'm in transit so don't have access to a dev machine to explore it. -- David
Re: Help Needed in Sorting and Updating the List of Perl Mailing Lists
On Mon, May 11, 2009 at 6:12 PM, Elaine Ashton eash...@mac.com wrote: On May 11, 2009, at 5:37 PM, David Golden wrote: On Mon, May 11, 2009 at 11:56 AM, Elaine Ashton eash...@mac.com wrote: Well, nobody asked for the data nor did anyone ever offer updates. http://tinyurl.com/r26sxy http://tinyurl.com/o2fufa http://tinyurl.com/osbcmv Sorry, I don't hang out on that list, not to mention I had an infant at the time anyway. *shrug* People sure don't try very hardI'm pretty easy to find. I have an infant now. Somehow, I manage to find the time to read emails, answer them, attend hackathons, release modules to CPAN, post on my blog, etc. (Not as much time as I might wish, certainly). One of the links I posted (from 2007) is specifically about someone not being able to get feedback from the email address given on the site itself. I don't object to you being busy -- it happens to all of us -- but blaming others for not trying hard enough is absurd. -- David
Re: Arguments checker module
On Wed, May 6, 2009 at 6:50 AM, Jonathan Rockway j...@jrock.us wrote: You seem to hate everything. I am confused as to why people even waste their time trying to help you. [snip] Anyway, embrace modules. They are the reason to use Perl. I think Bill gets Perl. (c.f. http://www.bayview.com/training/instructors.shtml) Jonathan, I hate to personalize things, but that kind of response is an example of what people mean when they talk about the Perl community being unfriendly. Moreover, Bill said he liked Params::Validate, just that it was wordy for him. It's not the first time someone in the Perl community thought something was wordy and wrapped it, given the number of ::Simple modules on CPAN. (362 distributions with Simple according to search.cpan.org) I don't think he deserves public scorn in response to a reasonable question and reasonable objections to suggestions. -- David
Re: Puzzling error from cpan testers
On Tue, May 5, 2009 at 2:58 PM, Jonathan Leto jal...@gmail.com wrote: I very much recommend that you look at is_similar() in Math::GSL::Test, it has implemented at least a few wheels that you are destined to want: Yikes. You must have missed Test::Number::Delta when you were writing that. On CPAN since 2005. I originally called it Test::Float and got argued into a proper hierarchical name, which is probably why no one seems to know it exists. Synopsis: # Import test functions use Test::Number::Delta; # Equality test with default tolerance delta_ok( 1e-5, 2e-5, 'values within 1e-6'); # Inequality test with default tolerance delta_not_ok( 1e-5, 2e-5, 'values not within 1e-6'); # Provide specific tolerance delta_within( 1e-3, 2e-3, 1e-4, 'values within 1e-4'); delta_not_within( 1e-3, 2e-3, 1e-4, 'values not within 1e-4'); # Compare arrays or matrices @a = ( 3.14, 1.41 ); @b = ( 3.15, 1.41 ); delta_ok( \...@a, \...@b, 'compare @a and @b' ); # Set a different default tolerance use Test::Number::Delta within = 1e-5; delta_ok( 1.1e-5, 2e-5, 'values within 1e-5'); # ok # Set a relative tolerance use Test::Number::Delta relative = 1e-3; delta_ok( 1.01, 1.0099, 'values within 1.01e-3');
Re: Dual-Build Modules (What to do if both Makefile.PL and Build.PL exist)
On Tue, May 5, 2009 at 10:06 PM, Jonathan Yu jonathan.i...@gmail.com wrote: Add to this some complication from Module::Install, which also uses Makefile.PL. So in that case maybe Makefile.PL is preferred (for Module::Install to do its thing) rather than Build.PL. (On the other hand, I don't think I've seen modules that mix both M::I and M::B, so in the wild this will probably not be a problem) For a brief time, M::I would also create a Build.PL that ran Makefile.PL that ran M::I. That doesn't happen anymore. (There might be a dist or two that still has it. E.g. Yahoo-Photos-0.0.2). I would say that if Build.PL exists, you should assume that to be the preferred build tool. -- David
Re: Puzzling error from cpan testers
On Sun, May 3, 2009 at 3:07 PM, Bill Ward b...@wards.net wrote: For my module Number::Format I am getting a strange result from cpan testers that I can't replicate. See this error report... http://www.nntp.perl.org/group/perl.cpan.testers/2009/03/msg3560533.html # Failed test 'pi with precision=6' # at t/round.t line 18. # got: 3.141593 # expected: 3.141593 That's my report. Perl is compiled with -Dusemorebits (64int-ld) and is thus using long doubles. That tends to trip up direct comparisions of floating point. For floating point comparison, I usually recommend Test::Number::Delta. However, given that your module is about formatting stuff, maybe the best approach is forcing string comparison. From a quick test -- using 'eq' instead of '==' in your modules passes tests on my system. -- David
Re: a lot of controversy about Module::Build
On Wed, Apr 8, 2009 at 2:34 PM, Eric Wilhelm enoba...@gmail.com wrote: If there has been any controversy, it's been about the fact that M::B was the first tool to break from how we used to do it. This exposed I'll add just my 2 cents to say that a good deal of the controversy was hung up on getting good support for Module::Build into CPAN.pm and CPANPLUS. Between the recent work on CPANPLUS::Dist::Build and the support for configure_requires in both CPAN.pm and CPANPLUS targeted for 5.10.1, I think the controversy will be largely resolved. After 5.10.1, the official latest Perl will have full Module::Build support and the only lingering issue is what do to about those who refuse to upgrade their toolchain. That's not a controversy anymore, that's a support issue. -- David
Re: META.yml no_index
It's not explicitly prohibited to have more than one, but it's implied
that it describes a distribution, not a directory tree within a
distribution. And the current crop of tools only look for META.yml at
the top level directory.
As for the first question, I point you to visitcpan for your answer:
$ visitcpan -q -a dist -- perl -MParse::CPAN::Meta=LoadFile -e 'if (
-f META.yml ) { $meta=LoadFile(META.yml) or exit; print
$ARGV[0]\n if $meta-{no_index}{package} ||
$meta-{no_index}{namespace} }'
ACID/Hyper-0.03.tar.gz
ACID/Hyper-Developer-0.07.tar.gz
ACID/Hyper-v0.05.tar.gz
...
ANDYA/IPC-ShareLite-0.17.tar.gz
Just about any can anyone point me to a distribution? can be
answered with a little bit of visitcpan help.
http://search.cpan.org/perldoc?visitcpan
-- David
Re: Public Domain - License Text?
On Thu, Mar 19, 2009 at 2:03 PM, Jonathan Yu jonathan.i...@gmail.com wrote: If you are legally required to do so, then you may use this file under, at your option: 1. The MIT/X11 License; or, 2. The BSD License; or, 3. The Perl Artistic License, version 2.0 or later; or, 4. The GNU General Public License, version 2.0 or later; or, 5. The Creative Commons CC0 (CC-Zero) License, version 1.0 or later If you're going this way, you could even go so far as to say any OSI approved license or the CC0 is allowed. And reference this URL: http://www.opensource.org/licenses/category -- David
Re: Public Domain - License Text?
On Thu, Mar 19, 2009 at 1:31 PM, David Cantrell da...@cantrell.org.uk wrote: On Thu, Mar 19, 2009 at 12:09:50PM -0400, Jonathan Yu wrote: On Thu, Mar 19, 2009 at 12:01 PM, Scott Elcomb pse...@gmail.com wrote: Anyway, I'm not sure if it's of any value to you however the folks behind the Creative Commons licenses recently released a new Public Domain Certification called CC0 (CC-Zero). You can find more information here: http://creativecommons.org/about/cc0 I will look into this, but the problem with CC licenses is that they are not Perl-approved - that is, they do not have fields in Module::Build's license field You mean not Module::Build-approved. Module::Build is obviously buggy in this area. The Module::Build::API doc suggests that unrestricted is a valid license type. I would just use that if you really need to put something. Though I think that the latest Module::Build relies upon Software::License, so someone could probably send some CC licenses to RJBS and lobby him to include them. Then they would be Perl-approved -- at least to the extent they are encoded into the toolchain. -- David
Re: Public Domain - License Text?
On Thu, Mar 19, 2009 at 2:29 PM, Jonathan Yu jonathan.i...@gmail.com wrote: David: Interesting idea. I'll add that in as option 6. I don't want to replace the others though in case the web site disappears at some point in the future, making the license pretty ambiguous. More formally, you could say any Open Source Initiative approved license and just link to the main page: http://www.opensource.org/ I suspect that's not going away anytime soon. I just wonder if a package can really be licensed under 5-6 different licenses... To be clear -- you are *offering* a choice of licenses to end-users. They (implicitly or otherwise) choose one of those licenses to govern their use of your code. -- David
Re: Net::Vimeo::API - namespace question
On Tue, Mar 10, 2009 at 10:05 AM, Jonathan Yu jonathan.i...@gmail.com wrote: WWW::Vimeo. That would be my choice. Adding API seems redundant. David
Re: Net::Vimeo::API - namespace question
On Tue, Mar 10, 2009 at 2:38 PM, Bill Ward b...@wards.net wrote: I agree about dropping API, but prefer Net. WWW to me suggests web browsers and HTML. There are certainly plenty of web-service interface modules popping up under Net. Personally, I wish people used that only for lower-level protocols. (E.g. SMTP, NNTP, FTP, etc.) WebService is annoyingly long, but WWW' makes sense to me for modules that send HTTP requests to a site and process a response -- regardless of whether a browser is involved. But I can certainly see the other side of it. -- David
Re: Science, Engineering, Craft (was once: something about hash references)
On Tue, Mar 3, 2009 at 2:43 PM, Eric Wilhelm enoba...@gmail.com wrote: # from Jonathan Rockway # on Tuesday 03 March 2009 10:16: This is just one of the many things I have been upset with the treatment of in my Computer Science program--it's way too academic, and not applied enough, but I suppose that's University in general. I would expect application of the Science to be found in the Software Engineering program, but we've got a ways to go yet before it becomes a professional discipline -- complete with licensing and responsibility. You might be interested in this article by Peter Deming, Is Software Engineering Engineering? http://cs.gmu.edu/cne/pjd/PUBS/CACMcols/cacmMar09.pdf -- David
Re: Science, Engineering, Craft (was once: something about hash references)
On Tue, Mar 3, 2009 at 7:54 PM, Eric Wilhelm enoba...@gmail.com wrote: And nobody ever picks $good, yet they wonder why they get what they get. I think it's related to difficulty of judging future opportunity costs. Paying for $good has an immediate cost now over paying for $decent, but it's hard to assess what the future opportunity cost of $decent over $good will be. I work in risk management and it's a similar sort of thing. What's the value of losses avoided? And, for that matter, can they even be measured. E.g. well, you lost $40 BN on these CDOs, but fortunately, you invested $10 MM in better risk software that kept your losses from being $50 BN, so that's a payback of $10 BN loss avoided on your $10 MM investment. (Exaggerated example, but I hope that shows the parallel.) And when management pays for $good now, but it might be different management later that suffers under $decent or even $crappy when the project is done, you can see how the incentives don't favor $good. -- David
