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
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.
I have a Perl application which is used in two contexts: It can be used as a diagnostic tool which displays information about a system, or as a testing tool which sends Modbus commands to that system. The problem I have is that allowing the user to send commands to the system in a diagnostic context is a potential safety risk, so I want to create two executables: A testing version that includes the Modbus module and a diagnostic one that does not.
My current solution is to include the Modbus module like this:
BEGIN { eval { require Modbus; }; Modbus->import; }
This only includes the Modbus module if I use the option -M Modbus while building the .exe with PAR Packager. The issue with this approach is that it fails unless this is the only place where Modbus is imported. So if another developer who isn't aware of this risk comes along, it only takes one require statement to bypass this fix.
Is there a way for me to prevent a specific module from being included in the executable unless I explicitly want it to be (either with the -M option or some other method)? I've been trying to figure something out with Devel::Hide, but haven't had much luck. All the solutions I've found so far fail the "other developer who doesn't know about this" test.
I'm using Strawberry Perl 5.20.3.3, but I can upgrade if necessary.
When I've done this sort of thing, I've created a small module that is included if it is present and not included if it is not:
eval { require MaybeItsThere }
In my Makefile (or whatever build system you want), I have targets for development and production builds. One of the subtasks for the dev build creates that MaybeItsThere file. It can also set whatever it needs for PERL5LIB and so on such that only the dev build can load it.
However, as you say, the enterprising developer can quickly find out what they need to do to get the features they want.
Having read through your comments, it seems that you're not going to be able to enforce correct usage. (You gave examples how the module has already been misused by people sidestepping your build process.) I would suggest an alternative approach.
Document the problem at that place where someone would find a workaround.
In other words, if some other developers is going to look at the code or at the build to see the name of the missing module, let them see a warning about the dangers right there. Put a comment block explaining why the Modbus module should only be used when diagnostics are disabled or filtered. Make the build's failure put a warning right there at the same place as the name of the missing module; use a die "Modbus should not be used when user interaction is enabled."; or something similar to convey the message in the same place where the other developer would be looking for the solution.
Ultimately, you can't force someone to use your build tools, but you can try to educate them while they're trying to work around you, instead of documenting the problem somewhere else that they might not see.
I have a couple of Dist::Zilla plugins that I wrote when I was very new to Moose and to Dist::Zilla both, and I'm currently trying to update them to make them a bit more robust, and less error-prone.
One thing I would like to do is to give the user feedback if I detect that they have given me contradictory or impossible instructions. Things like:
[ MyPlugin ]
include = all
exclude = all
Dist::Zilla does appear to have an (undocumented) internal logging system which I originally hooked into when I wrote my plugins, but which no longer seems to work (probably due to internal changes). So, how should I give the user feedback these days?
(Meant to put this in the comment but hit length limit).
Caveat: I've only written a couple of small dzil plugins myself, and am not very familiar with its internals.
dzil uses Log::Dispatchouli, which is also written by rjbs. Log::Dispatchouli is used by several other projects (including projects started by people other than rjbs), so it's not exactly an internal dzil logging system.
From what I understand, Log::Dispatchouli only has two logging levels, normal and debug. Debug logs are not normally seen in output; you have to enable debugging first. Normal (and debug) logs can be muted if you enable muting.
To enable debugging in dzil, add a -v command-line switch. This does not seem to be documented in 'dzil help' nor 'dzil help COMMAND'. But rjbs blogged about it.
Now to produce logs inside the dzil plugins, you just call $self->log(...) or $self->log_debug(...). The second one will be seen only if user passes -v option.
I downloaded some module from CPAN and added to it extra functionality. Could I post the newest module on the CPAN? If yes, how should I do this? Is it possible at all? Should I contact the person who wrote the original module? Could someone help about the procedure to update this specific module?
You won't be able to upload and index a module as the same name unless you are a co-maintainer. Uploading it as a different name isn't very productive for the community as there are now two (or more) slightly different versions.
Contact the author
Submit your patches to the RT queue for the module (or the issue tracker it specifies in its docs)
If it's on Github, fork the project, make the change, and submit a pull request
If the author is unresponsive (which means no response, not a negative response), we have ways to pass on maintainership of abandoned modules. We take this process very slowly because we want to give the original author or current maintainer every chance to respond. Some people might be swamped at work, on holiday, and so on. However, most situations turn out very well.
You can upload anything that you like to PAUSE, but if you are not some sort of maintainer, PAUSE won't index it. It will still show up in your CPAN account and people can still download it through the CPAN website, but the CPAN clients won't see it (since they work according to the index). Some of the search sites will show it as an "Unauthorized release".
It would be unhelpful to blindly upload a module that you've added functionality to under the same name as the module that it's based on (it happens sometimes and often creates a mess). But you do have options that would be helpful:
First, you could contact the module's author or maintainer, emailing a diff or patch showing what you would like to see added. Be sure to supply relevant documentation as well, and explain your rationale.
It could be that the module author will accept the patch and apply it to an update of the module himself. Or it could be that by way of prevention of creeping featurism, the author/maintainer rejects the upgraded functionality, and that leads you to a second option.
The second option is to get your own PAUSE account, and either subclass or otherwise extend the module. But be sure to give it your own new module name, full documentation, and probably an explanation within the documentation that this is an extension of xyz module with the following additional functionality... If you're extending Math::BigInt, you might call it Math::BigInt::Frobcinate (just an example).
When you do attempt to make contact with the module author, please be patient. Sometimes it takes awhile to let things run their proper course.
I recommend that you attempt to contact the author.
Additionally, you can upload your module changes as a patch via rt.cpan.org; there should be a link from the module's website on CPAN. Refer to the CPAN FAQ: How do I report/fix a bug in a module/script? This tracking system is used for requests such as yours, not just for reporting bugs.
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.)