I have been using Frontier::RPC2 for my XML-RPC server, with Frontier::Client on the client side... but have noticed these modules have not been maintained recently.
Discussion at the bottom of this page mentions some fresher alternatives on CPAN. What would the pros and cons of these be? I honesty don't have an immediate need to switch, but there are some annoying "uninitialized" variable warnings produced by Frontier::RPC2 which I'd love to rid myself of... they are clogging up and making it difficult to find more salient warnings in my webserver log.
Any recommendations for upgrading my web service?
You could just fix Frontier::RPC2 so it's warnings clean. That's kinda the point of free and open source software. :)
If you are already using this module and it works fine except for the warnings, why switch? Just fix the warnings. Submit a patch to RT for the module. If the maintainer has disappeared, the admins at modules#perl.org can help you get your patch applied.
Related
When I run composer updates I'll occasionally get messages that packages are abandoned and I should use a different one instead, like Package webflo/drupal-core-require-dev is abandoned, you should avoid using it. Use drupal/core-dev instead. I don't have experience with Composer so I'm curious as to what is seen as the best practice for replacing outdated packages.
Where do these messages come from? I'm unsure if the source is always reliable.
I think the best practice is quite clear from the message "you should avoid using it". How/When to do this is not as clear. Abandoned packages will not receive updates, but composer will not be able to tell you how difficult it will be to transition to the recommended alternative. It might be that all you have to do is replace the package, because it was only a name change or having to modify your code as well.
In your case webflo/drupal-core-require-dev only contains a composer.json and the required packages match with what the alternative drupal/core-dev provides. That means replacing the package should be as easy as changing the name in your composer.json and then do a composer update drupal/core-dev.
For packages where the answer is not as straightforward, you have to rely on automated/manual tests to see if everything still works. Static code analysis tools might help as well. You will have to set them up before you do the change, so that you can see how their output differs and fix the new issues that come up.
You should do the switch to the new dependency as early as possible. Leaving it in will likely cause more work in the future when replacing it and might pose a security risk (if it is outdated and insecure). I understand that this is not always possible and using something like roave/security-advisories to tell you when there are known security issues in a package might help postponing it and giving some sense of security.
This is a canonical question for the above problem, inspired by this answer and this question. Please edit and improve it.
I'm trying to install a module from CPAN, using the CPAN/cpanm/CPANPLUS client. However, I'm getting build or test errors when I try to install it. What should I do?
Does it build at all?
The first thing to consider is, is your module building at all? If it isn't building, you should check for existing bug reports, file one if necessary, and perhaps try to fix the issue yourself (steps 2 and 3b/3c below).
If it builds but tests fail, follow these steps.
1. Determine if the test is valid
The purpose of these tests is to test. If there's a problem, you need to know about it, and not sweep it under the rug. Resolve the issue one way or another. Is there a problem with something on your system, or is this a problem with the test itself. If this is a problem with the test, does it still affect you? If this is a system problem, is this something you might run into? For example, let's say there's a test that checks for connectivity between your system and a Windows system. If you don't connect to Windows systems, maybe that particular test doesn't apply to you.
2. Check MetaCPAN for bug reports
If you have a test failure, go to the MetaCPAN webpage for that module, and check the left hand side for RT issues to see if someone else is getting the same errors. If no one is, you should open an RT ticket, or a ticket in the project's bug tracker of choice.
There may be patches available from other users. If the patches make sense to you, you can try applying them and rerunning the tests.
You can also click on the Testers link on MetaCPAN. The QA testers webpage will show you the various Perl versions, module versions, platforms, and show you which tests are failing on particular platforms on which versions. You might need to install an alternative version of the module.
At this point, there are a few paths you can take.
3a. Force the installation
Only once you've determined that the failed test doesn't necessarily apply to you, do a force install:
cpan> force install Date::Calc
This will run through the entire install, except that it will skip all testing. (Or maybe it still tests, but doesn't fail if a test fails.). The module will still fail on compiler errors, or if something can't get written to your system. It merely ignores tests.
This should be the last desperate attempt to get something installed. You've should have already resolved that the failed tests are bugs or not meaningful for you. Or, someone is standing beside you with a gun to your head saying, "Install that module, or I'll pull the trigger!".
3b. Find an alternative module
Or, you can decide to use another module. CPAN is full of various approaches to problems (TMTOWTDI), so there many be one there that does what you want.
3c. Write some code
Or, you can analyze why the test is failing and either fix the module or the code. Bug reports with potential patches are often appreciated by busy module authors. If it doesn't look like the author wants to take your fix, you can always fork an existing module, or write a fresh one.
If the author has gone MIA, you may be able to adopt the module and maintain it yourself. The general process for adopting a module is first to try to submit code to the author that fixes it, and then wait a while, maybe a month, for the author to pick it up. If there's no response, try alternative means of contact, email, Google+, whatever you can find. After that, you can go on Perl IRC chats, mailing lists, etc, looking for someone who knows where the author might be. If none of that works after a few months, the PAUSE admins can investigate and turn the module over to you.
This is based on this excellent answer
I'm getting ready to set up a full CPAN mirror for internal use at my company. However, we have several internal Module::Build based distributions that I'd like to make available to people from this mirror. These distributions should ONLY be available from our mirror; they are internal libraries only. Essentially, once people have set up their CPAN config file to load "cpan.mycompany.com' mirror, I'd like them to be able to do a
cpan install MyCompany::Bundle
cpan install MyCompany::Other::Module
On their command line to install any number of internal, custom module distributions. Ideally, as versions of these module distributions are incremented, all of those versions would be indexed by our internal CPAN mirror and made available, just as as previous versions of CPAN modules are made available.
After the initial question, I was able to come up with some other possibilities.
There's CPAN::Inject, but it looks like I can't use it to get a cpan install My::Module syntax.
Then there's MyCPAN::App::DPAN, which also looks interesting, and almost looks like what I need. Does anyone have experience with this tool?
Another one I just came across was CPAN::Site. This seems to also be able to set up a custom CPAN distribution. Any thoughts on this tool?
If you're using CPAN::Mini to create your mirror, then you use CPAN::Mini::Inject to add your own modules to it.
To do this with a full CPAN mirror, CPAN::Site covers this nicely. It lets you make a mirror, and then inject your own libraries right into it, complete with tools to help you manage setting it up and keeping it up to date.
I would like to second the suggestion for CPAN::Site - the author is responsive and will gladly apply fixes if you ask or file a bug report on the CPAN RT.
I've been using it recently to make a "micro-cpan" containing only what a particular application needs and nothing else, along with cpanminus to make installation in any environment dead-simple. However, don't ask me for my solution - miyagawa++ was at YAPC::NA this year and showed off "Carton" which does all that and more, way better than my hacky stuff.
CPAN::Mini::Inject is perhaps a bit too "low-level" in that it requires that you specify a whole lot of information about each dist up-front before injecting into the minicpan - I feel that just about all of that should be auto-detected by analyzing the dist, for example by using CPAN::ParseDistribution.
MyCPAN::App::DPAN is actually quite cool, but has a bit of a learning curve and may not be the right tool for the job. I've also found it has a tendency to choke on some badly-formed dists and detecting that involves treawling through the logs (as far as I can tell - maybe there's a better way to do it) However, I'd highly suggest checking it out.
If you're still interested in MyCPAN::App::DPAN, I've just posted how I use it to create a mini CPAN-like directory structure, in (one of) the answers to this question:
Internal CPAN - what module
(I don't know if it's OK to link to my own answer here. Let me know if it isn't.)
I need to create a Zip archive after filtering the list of files I want to include. Preferably I'd like the module to work in both Windows and Linux.
Since I need to filter the list of files, I don't really want to to use an external program. I'd rather not introduce external dependencies either so I can compile the script into a single executable on Windows (using ActiveState PDK).
What I already tried
Until now I've used Archive::Zip found on CPAN but it has a major bug on Windows machine that use non-ASCII filenames: the filenames get corrupted in the archive as they don't get translated into unicode.
There is a bug report filed for that but it hasn't been updated in over 10 months and in the module documentation the developer is rather unhelpful (of the "fix your computer or get rid of Windows" kind).
Update:
Thanks to the clarifications from brian and Alan Haggai Alavi it seems that enough love is being put in Archive::Zip to get these bugs out soon and finally have a fully functioning zip module in Windows.
Although the module documentation says some stupid things about Windows, the current maintainer is Adam Kennedy, the same guy who brought you Strawberry Perl. He's definitely not anti-Windows. He released a version October, so they are working on it. There's also an open grant from The Perl Foundation to fix Archive::Extract bugs.The bug you mention, RT 35334: Filename Encoding by Archive::Zip, maybe just needs someone to show it some love. That could be you. People solve the problems that bother them, so maybe nobody interested in the module needs this just yet.
The module has had problems, and I've been following its progress since I use it in a couple projects. It has gotten a lot better recently and can certainly use some love. Sometimes open source means helping to fix the problems that you encounter. I know this doesn't help you solve your problem immediately, but that's how I think you're going to get this done aside from system() calls.
The above said bug has been solved very lately by the addition of Unicode filename support under Windows. A release featuring the fix will be available in CPAN within a week.
You could try the standard-distribution Archive::Extract. It may not be any better than Archive::Zip, but the documentation says that, if there are problems, it goes under the hood to try to use command-line tools on your system to unzip the file. This is probably most robust on Unix, but Windows has a zip archive utility, and it should be accessible via the command line. Plus, Archive::Extract can handle many other types of compression (theoretically).
Of course, it may turn out that Archive::Extract simply figures out what kind of compression the file uses and then passes it to the appropriate other library, which might be Archive::Zip.
You might also try IO::Uncompress::Unzip and it's counterpart, IO::Compress::Zip, for just unzipping, reading, and rezipping. If absolutely necessary. Again, I don't know how much better these will work, but they are all part of the standard library.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
What's the best framework for writing modules -- ExtUtils::MakeMaker (h2xs) or Module::Build?
NOTE This advice is out of date. Module::Build has been removed from the Perl core but lives on as a CPAN module. The pros and cons still stand, and my opinions about MakeMaker still stand.
As the former maintainer of ExtUtils::MakeMaker, I like to recommend Module::Build because MakeMaker is a horror show. Module::Build is so much better put together. But those aren't your concerns and I'll present my "least hassle for you" answer.
Executive Summary:
Because Module::Build support is not 100% in place through all of Perl, start with MakeMaker. If you want to do any customization at all, switch to Module::Build. Since their basic layout, options and interface are almost identical this will be painless. As seductive as it looks, avoid Module::Install.
Fortunately, Module::Build can emulate MakeMaker which helps some, but doesn't help if you're going to do any customization. See Module::Build::Compat.
For CPAN releases using Module::Build is fine. There's enough Module::Build stuff on CPAN now that everyone's dealt with getting it bootstrapped already.
Finally, the new configure_requires option lets CPAN shells know to install Module::Build before they can start building the module. Unfortunately only the latest CPAN shells know about configure_requires.
Oh, whatever you do don't use h2xs (unless you're writing XS code... and even then think about it).
MakeMaker Pros:
Comes with Perl and used by the Perl core (therefore it is actively
maintained and will remain so forever)
Everything knows what to do with a Makefile.PL.
Most module authoring documentation will cover MakeMaker.
Uses make (those who know make can debug and patch the build
process)
MakeMaker Cons:
Requires make (think Windows)
Difficult to customize
Even harder to customize and make cross platform
Difficult to debug when something goes wrong (unless you understand make)
Module::Build Pros:
Easier to customize/subclass
Pure Perl
Easier to debug (it's Perl)
Can emulate MakeMaker in several ways
The CPAN shell will install Module::Build for you
Module::Build Cons:
The Module::Build maintainers (and indeed all of the Perl Toolchain Gang) hate it
Older versions of CPAN clients (including CPANPLUS) don't know anything about Module::Build.
Module::Install Pros:
Slick interface
Bundles itself, you have a known version
Everything knows how to deal with a Makefile.PL
Module::Install Cons:
Requires make
Always uses bundled version, vulnerable to external breakage
Difficult to customize outside its interface
Mucks with the guts of MakeMaker so a new MakeMaker release will eventually break it.
Does not know how to generate a META file using the v2 meta-spec
(increasingly a problem with newer tools)
There are two questions here.
First, never use h2xs. It's old outdated nastiness, though I suppose if you're actually trying to turn a header file into XS code, it might be useful (never done that myself).
2011 update: I strongly recommend taking a look at Dist::Zilla, especially if you think you'll be maintaining more than one module.
For creating a new module, use Module::Starter. It works great, and has some nice plugins for customizing the output.
Second, you're asking what build system you should use. The three contenders are ExtUtils::MakeMaker (EUMM), Module::Build (MB), and Module::Install (MI).
EUMM is a horrid nasty piece of work, but it works, and if you're not customizing your build process at all, works just fine.
MB is the new kid, and it has its detractors. It's big plus is that if you want to heavily customize your install and build process, it's quite possible to do this sanely (and in a cross-platform manner) using MB. It's really not possible using EUMM.
Finally, MI is basically a declarative wrapper on top of EUMM. It also packages itself along with your distro, in an attempt to work around problems with users trying to install modules with old toolchain modules. The downside of the "package self" trick is that if there's a bug in MI itself, you have to re-release all your modules just to fix it.
As far as customization goes, there are some plugins for MI, but if you want to go beyond them you'll be back at the problem of dealing with Makefiles and build tools across a dozen+ platforms, so it really isn't going to help you too much in that realm.
I just uploaded Distribution::Cooker to CPAN. It's what I use to make new distributions. The nice thing about it is that your distributions can be whatever you like: you're just cooking some templates. I don't care if anyone uses it. For me it's simple, low tech, and doesn't cause extra problems.
You might start with something like Module::Starter to make your starter templates then add your own boilerplate and favorite way of doing things. You choose not only whatever you want in each file, but which files show up in the distro. As you figure out how you like to do things, you simply update your own templates.
As for Makemaker and Module::Build, the future is Module::Build. It's only us old guys using Makemaker anymore. :) There are ways to use both (or pretend to use both) at the same time. Look at the Module::Build, Module::Build::Compat, and Module::Install docs. Module::Build was kicked out of Perl's Standard Library and it's future is uncertain. It's back to Makemaker as a build system.
Although this is a bit of a cop-out answer, try using each just to get a little experience with each.
You also might want to look at Dist-Zilla which is a new author-only tool to create distributions. Because it just helps build the distribution, it doesn't ship with your code or do any installation, it can do a lot of powerful stuff.
The only trouble with compatibility regarding Module::Build is when a user tries to install modules without updating their CPAN client (CPAN.pm or CPANPLUS.pm) If they are installing your module from the CPAN, they can just as easily upgrade their client from the same mirror.
If you don't want to do anything complicated in your build process, sure: use EUMM. But if you have a build problem on a different target platform, you might end up in the Makefile, which is different on every variation of make.
Module::Build gives you lots of features (anything you can think of if you extend it) and is all perl so you never end up debugging a makefile. Module::Install gives you features, but you have to bundle it and everything ends up running through 'make' in the end.
I also recommend Module::Build and Module::Starter (with the TT2 plugin).
Module::Build is better by any means, but it is less widely supported than ExtUtils::MakeMaker (more specifically, older versions of Perl don't support it out of the box). It depends on your needs.
Personally, I recommend Module::Install, as do a lot of folks I know - the likes of the Catalyst and Moose folks also use it.
Here's a little clarification of the direction I hoped the responses would take:
pros/cons of various of frameworks
compatibility/install base of frameworks
suitability for internal (local) vs. external (CPAN) releases
not bare "use X" answers
Dave's answer has some good pro/con info. Leon's answer alludes to compatibility but isn't explicit. As brian d foy mentioned, only the old hats use EUMM, but I'm not convinced that MB is a good framework for things destined for CPAN due to it not being part of the core until 5.9.
There are pros and cons to both. These days I use and recommend Module::Build and Module::Starter.
EU::MM still seems to be the most widely supported and popular one, but Module::Build is catching up. Also, check out Module::Starter for a module that will help you get started.