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.
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 need some of your help.
I searched everywhere on the internet, but I could not find how to create a plugin for Gaim, the predecessor of Pidgin.
I do NOT want to create a Pidgin plugin. I want to create a Gaim plugin, but since Gaim is very old, well, it is hard to find documentation for it.
(PS : If you know how to write a plugin for Gaim, please note I want to make one for Windows - not Linux.)
(PPS : I'm french. Sorry for my bad English.)
You're going to run into a number of issues here...
First off, Gaim hasn't existed for 15 years, and of course we (the Pidgin core team many of who got involved during the Gaim days) aren't going to support it for that reason.
Secondly, building on windows has always been a pain for us as we had to carry all of the dependencies. I imagine most of the links that you might find are all long dead because of the 15 years that have passed since that. That said you might be able to get away with using our win32-dev directory from https://data.imfreedom.org/pidgin/win32-dev.7z but of course that's completely untested and that directory is used to build the Pidgin 2.x.y releases.
Finally, as you've found out, most of the documentation from Gaim has been gone for a very long time. We did set up https://gaim.pidgin.im as a joke which was the last copy of the site we had before the rename, but there's not much there when it comes to development documentation. So your best bet is to look at existing plugins. I still have the source code for guifications1 available at https://keep.imfreedom.org/grim/guifications1/file/default.
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.
Is there any way to obtain, or has someone already obtained and compiled documentation from MS Technet Library for offline use?
I know of the Visual Studio Help Downloader at codeplex https://vshd.codeplex.com/ and I am looking for something similar for the Technet Library.
The Library itself has an option to select articles for export however, it is very limited in number of pages to add per click. This means you have to drill down on every subject and add it to your selection. Not very usable, besides the examples state you should be able to download as pdf or html, but I only get the html option, which is annoyingly impractical.
Ideally I would like to have the complete offline documentation for a single top-level subject (e.g. "Scripting with Windows PowerShell" at https://technet.microsoft.com/en-us/library/bb978526.aspx). If possible, including an index/TOC.
I know of the built-in Get-Help, the books available etc. but the Technet Library has more detailed information available which I'm after. Any known method of downloading this in bulk would be greatly appreciated.
All my google search results seem to either point to the built in export funcion, or people reminiscing about the old offline Technet subscription.
Ok, its not great. But its better than the above... I know this is old. But I was looking for this. This is the best I found. So Ill leave my breadcrumbs for the next fool to stumble down this road. If someone else finds better, hopefully theyll continue to pass it on.
On Github, you can download the entire Doc repo as a zip. Read it with microsoft code and a markdown extension.
Ideally, Id like to see this as a CHM (rather than a PDF).
https://github.com/PowerShell/PowerShell-Docs
I was surprised to find that this is well documented, and actually is a thing:
Taking TechNet Offline
When you start the process, it'll give you some instructions, and once you click "Start," you'll be shown the hierarchy of the entirety of that root page you linked on the left. Note the instructions in orange at the top.
I didn't go much further then this, but let us know if this worked in full, and as you expected it to. Nice feature there! I learned something myself today.
I have had mixed success with HTTrack You can give it a site a page and it will go through all links and resources recursively, saving them locally.
It requires some tuning and playing around with to get right, There might even be a newer better equivalent these days.
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