Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Re: RFC: How to Release Modules on CPAN in 2011

by Anonymous Monk
on Dec 28, 2010 at 22:42 UTC ( #879523=note: print w/replies, xml ) Need Help??

in reply to RFC: How to Release Modules on CPAN in 2011

Did I form a misimpression or jump to a false conclusion about something because of my brief experience?

Yes. One simple example However, it is inherently less portable because it assumes that make is installed.

make has been a prerequisite to build perl/modules for a very long time, and the newest versions of cpan/cpanp(or is it Module::Install/Module::Build/ExtUtils::MakeMaker) will install make if its missing (on win32).

But they start much earlier, with the first paragraph

The last day or two I've been learning how to prepare a module for CPAN distribution. There doesn't seem to be a good tutorial anywhere explaining how this all works. The two tutorials I found on Perl Monks are quite old. One was written in 2002 and the other in 2005. Neither discusses newer tools like Module::Build. Nor do they explain how CPAN works, let alone discuss how this process can be safely and reliably customized.
Well, the two tutorials you linked to are good, they're more comprehensive than your apparent rebuttal, they mention I believe you intended to write a tutorial and not rebuttal, so its best to avoid invoking other tutorials :)

Also, this link requires a PAUSE account.

These do not
On The Naming of Modules
You should definitely check out Module::Install.

Keep up the good work, I'm sure this will eventually make a good addition to Tutorials: Modules: How to Create, Install, and Use: Creating and Distributing Modules

  • Comment on Re: RFC: How to Release Modules on CPAN in 2011

Replies are listed 'Best First'.
Re^2: RFC: How to Release Modules on CPAN in 2011
by ELISHEVA (Prior) on Dec 29, 2010 at 10:16 UTC

    Thank you for such a careful readthrough and the honesty to be critical.

    I certainly did not intend this as a 'rebuttal'. The tutorials and all the links you have listed are fine resources and this document simply couldn't have been written without them. They were my starting point, but truth be told, they only underscore my point about either absent or hard to find documentation that brings it all together for 2011.I only mentioned the Perl Monks links specifically because this is, after all, Perl Monks. It was by no means my sole reading list.

    • perlnewmod - also only discusses h2xs. It appears this hasn't been updated in years.
    • perlmodinstall - this is an excellent article describing how to manually unpack a tarball and install an application. However, it appears to have been written at a point when was in its infancy.
    • perlmodlib - advertises the fact of CPAN and list all of the mirrors and discusses the modulelist. It also has a brief section on module design and naming conventions. It does not describe CPAN meta data, nor the client tools that a released package needs to work with (i.e. and Again, it appears that the main body of text was written at a time when CPAN served primarily as a tarball repository from which people manually downloaded.
    • perlmod - an excellent article, but it discusses modules as a language element rather than the process of creating and distributing new ones.

    If by more comprehensive, you mean more in depth discussion about the module itself, my neglect of their excellent words on that matter was intentional.

    Many tutorials on distributing modules have a rather significant section dedicated to module design and coding conventions. I deliberately left such things out unless they affected the actual distribution and testing process. First, module design is a huge topic and one close to my heart. It isn't something I would want to treat lightly. Second, there are many excellent resources devoted to this topic. Third and most importantly, the purpose of this document is not to cool the heels of an over-eager newbie. I assume my target audience is someone who knows programming and Perl itself fairly well, but doesn't know publishing Perl modules well. Distributing bundles for clients is not exactly the same thing as preparing packages to play nicely with CPAN and

    That being said, I think this tutorial would benefit from a "see also" section that would include many of the links you listed. There are links scattered through the tutorial itself, but there are many more not mentioned, some of which you listed above. A few of the links you mention should have also been included in the body of the tutorial. Thanks for the reminder.

    make has been a prerequisite to build ...

    Perhaps you are reacting to the word "inherently"? I think that might have been a bit too strong, as it implies unsolvability. It is a solvable portability problem, though not necessarily for a novice and not necessarily for all users on a system.

    As I understand it make does not ship with all installations of Perl and does not automatically require it. Not all users build their Perl from scratch so the fact that one needs make to build Perl or XS modules is not really relevant to someone who has installed a pre-build binary Perl interpreter and just wants to download Perl only modules from CPAN.

    Some system administrators, even in Linux land, restrict access to or even remove tools typically used for binary compilation (make, cc) for security reasons.

    In a CB discussion on this issue this AM (for me, PM for those in the US), there seemed to be mixed feelings about make and portability. Some CPAN clients (there is more than one) will auto-download make/nmake/etc for you if a make like tool is missing. Module::Install is one such client. Some distributions like Strawberry Perl ship with a make-ish tool (dmake I think). Some clients (older modules) will just bomb if make is missing. For non-novice users there is also the possibility of running perl with the -V:make option.

    You can, of course, gain control over the tools and environment used to build your package by bundling software or declaring your preferred tools as pre-requisite. For example, if you want to benefit from Module::Install 's auto-download features, you would need to do that because it isn't core. But there are those who don't like packages that magically install unexpected software, so that option has to be considered carefully as well. One advantage of tools like Module::Build is that it has been in the core since Perl 5.9 and so requires no extra pre-requisites or bundling.

      Some system administrators, even in Linux land, restrict access to or even remove tools typically used for binary compilation (make, cc) for security reasons.

      That also means those administrators are entirely responsible for installing modules.

        Only if they require compilation. There may still be an open policy about installing scripting language modules especially in personal work areas, on the assumption that scripting languages allow less direct access to the OS and so less possibilities to subvert security and load balancing policies. A classic example is an account on a shared web server that provides ssh access to a shell. ftp and wget may be enabled but not make,cc, or other tools viewed as CPU intensive. Sometimes it isn't even security - it is just a way of crippling the account so that they can steer heavier users into higher priced VPS accounts.

        Is this wise? Does it really make things secure? Don't these servers have automatic shut-offs that kill processes if they consume too many resources? We can debate. But it is what is.

      make has been a prerequisite to build ...

      Perhaps you are reacting to the word "inherently"? I think that might have been a bit too strong, as it implies unsolvability. It is a solvable portability problem, though not necessarily for a novice and not necessarily for all users on a system....

      Nope. Consider If the intent is to inform, its best to remain factual when touching upon a subject, its better than the alternative :)

        Number of distributions using is not the issue. Number of downloading sites able to use the distribution is the measure. Module::Build is core since 5.9. make is not.

        Again, it comes back to philosophy - should the downloader mold themselves to the distribution or should the distribution mold itself as much as possible to the person wanting to use it?

      I wish I could kiss you, Elisheva. IMO, the issue of stale perl documentation/modules is probably one of the most imposing obstacles the Perl community faces today. It has been around for so long, solving so many problems, and in so many different ways, that it is really hard to discover what's the very best way/most current/most supported way to do some of the most basic tasks in the language.

      I find that I most often:

      1. Get discouraged with new mods and stick with old methods.

      2. Learn a new mod only to discover, once I fall in love with it, that it's no longer supported or outdated or has been replaced by something newer.

      3. Have completely gone about approaching the problem wrong, and that my solution will have to be completely redone if I were to apply it to anything other than the very specific problem I just solved.

      I just spent the last month or so learning I had fun with it, I learned a ton, and then realized that my solution is probably about five years too old to be applicable to modern solutions (as cool as I thought it was to learn). That's demoralizing.

      Turns out that the object method of invoking is only one way to use it, and I still don't entirely follow whether the functional or object methods were better.

      In attempting to learn the module, I looked at dozens of tutorials, and found an assortment of books. And even then, I think the most current was from 2007.

      If a tutorial is to be relevant, I'd really like to know if it's still being used/done this way. I appreciate having learned ancient history of computing--imo, that's how you learn the foundations of analysis--is understanding the underlying history, but in order to really engage, I need to know what current methods work best.

      Also I know there's always the option to update the most current versions of perl docs, but those docs are seldom at the level of tutorials. They don't contain a lot of examples, nor do they tend to be filled with practicle case use examples.

      I admit I'm lazy. I don't want to do a lot of legwork, to know whether or not the Perl Hacks book that's copyrighted in 2005 is current with my Active Perl distro of win32 v 5.12.2 and the SDL module hack... I see a lot of information about MacOS, but is it being used in the realm of PC's still? Or am I about to go learn some really cool tricks that are of ancient date but of little use to me in the longterm?

      Anyhow, thanks for the detailed, updated discussion of Module::Build. it's one of the topics I've wondered about, and just seeing how it applies, helps me to get a grasp on some of the better practices used among current programmers. And I don't have to buy the latest book, fish through 700 pages of a book that is on its eighth revision, in order to find the new nuggets...

      Best regards, --Ray

      For non-novice users there is also the possibility of running perl with the -V:make option.

      LOL, did you try it?

      $ perl -V:make make='dmake';
      perl Makefile.PL MAKE=DMAKE

        I think you are assuming that the person on the downloading side is someone understands that Perl has command line options beyond "perl myscript", knows how to find and read perlrun, isn't scared to use options other than the script name or -mSome::Module, and knows how the command line options interacts with CPAN::Config, assuming they even know there is a CPAN::Config . That is likely true for a command-line comfortable developer who is selecting modules for a project, but not necessarily for someone just looking for a ready-made bit of functionality to use on their website.

        Nor is it necessary true for an experienced developer who "grew up" using GUI development tools and only occassionally uses Perl. The mechanics of turning code into software is often a mystery to them, some sort of black magic that happens when they click the build button. Even the need for a "make" program is confusing because they have no real understanding of how the process happens without a GUI.

        However, it comes down to philosophy - should our goal be to make a package that can be installed without a burp for someone who thinks everthing should be point and click (or command w/o options and enter) or should it be aimed only at people who are agile at the command line and comfortable looking up command line options?

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://879523]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (4)
As of 2021-04-18 18:52 GMT
Find Nodes?
    Voting Booth?

    No recent polls found