I'm writing a Perl module and right now I'm including in Makefile.PL all of the dependencies. The only problem is I have all of the latest versions of the modules required, but I don't want to limit anyone who has early versions (and either can't update them or requires older versions for old code). Is there any way to find out what would be the lowest version usable with my module without downloading and testing all of the versions? Thanks!
No, there is not an automated way to tell. You probably want to start with reading the Changelog for each module and seeing what changes have occurred.
Ever heard of Dist::Zilla? It won't help you with the version problem... but it helps you with a lot of other stuff for creating, maintaining and releasing modules. As mentioned by others, the only way to know the versions working is write tests and test against them...
Related
ANSWERED: Basically, it can be done with no major side-effects if you compiled your own perl and you did it the same way your OS did. While it isn't a recommended practice, I've been able to run like this for more then a month. I would conclude it is relatively safe to do if you know what you are doing.
We came to the conclusion at work today that we needed to upgrade perl to 5.10.0
CentOS 5.x comes with perl 5.8.8.
We determined that the effort involved in maintaining scripts with #!/usr/bin/perl was futile.
According to some install stuff on CPAN and other places, it isn't a 'good' idea to replace the OS's version of perl. I already updated the link in /usr/bin/. So my question is, how bad is it really to replace /usr/bin/perl?
I've not noticed any adverse effects in our systems yet, but I'm prepared to correct the link (back to 5.8.8) as soon as there is a problem.
I'm worried that there may be some modules in the CentOS standard distro that aren't included in CPAN's source 5.10.0. I'm still trying to figure out what those modules might be.
Thanks in advance.
In my experience, the best practice is to compile your entire stack (Perl, Apache, ImageMagick, ...) from source yourself. That gives you complete control over which versions of everything are used and when everything gets upgraded.
Replacing /usr/bin/perl with one you compiled is a crap shoot. The OS might be using /usr/bin/perl as part of its maintenance or init scripts so changing it could brick your server or cause strange failures.
So ignore the system Perl, build your own, and fix your scripts to refer to your version of Perl.
Generally newer versions of Perl5 attempt to maintain backward compatibility with older versions. But that's not 100% assured. For example, a script that depends on an undefined behavior in Perl 5.8.8 (which shouldn't happen but sometimes does), that behavior may be different under 5.10.0. Nevertheless, it's usually fairly safe to assume that a script written for Perl 5.8.8 will run under 5.10.0 assuming there are no other factors involved.
But there usually are other factors (modules, byte compatibility for XS code, and so on). The list of possible gotchas is huge. That doesn't mean that any one of them will snag you on this go-around, but there is potential for problems.
If you've already got an upgraded Perl in /usr/local/bin, go ahead and use it. But don't dismantle or upgrade the old /usr/bin/ version. It's only a small chunk of hard drive (very small by today's standards).
By the way, a lot of people speak highly of perlbrew (App::Perlbrew on CPAN) as a tool to help maintain multiple versions of Perl.
Well, if you do decide to change the location of where Perl is installed, that is completely up to you and where you prefer it to be. But, keep in mind that any scripts that exist with a shebang line pointing to #!/usr/bin/perl will possibly break.
My recommendation would be that after you have installed it, create a soft link in /usr/bin/perl pointing to the executable for the new version of Perl that you installed. Just a thought. Its a work around to avoid breaking anything.
Creating the link above would certainly help to avoid the possibility of 'bricking your server' as #Mu pointed out.
Regards,
Jeff
What are the advantages/disadvantages of using postgresql compiled from source compared to the ubuntu postgresql package? Which of the two are recommended to be used on a live production environment?
Thanks in advance.
I'd recommend distribution provided package over self-compiled one. You'll get automatic security updates from your distribution, sane file locations and ability to verify or restore files using your package manager. You'll be able to rollback failed update fast using old package, etc.
If you'll compile yourself you'll have to very often check if there is new version available with security updates, you'll forget what options did you use for compilation and if you mismatch them then an update can make your data unreadable. You won't be available (on vacation) when new security update is published and your update will be late. Or you'll forget to update at all. You're lazy and you'll have to work more.
I know this is an old question, but there is one very real advantage to building from source. If you find a bug, submit it to the pg mailing lists, and get a patch you can apply it within a few hours, easily. I know this, because I've done it twice in the last two years in production.
The only advantage with compiling it yourself is that you could optimize the build yourself with different features and/or compiling modes. But on the other hand this means your build is much less tested then one distribution via the package system. So doing it yourself might end up not being so great. Plus updating/redoing it as Tometzky mentioned, end up being a lot more work. Unless it's very needed to build it yourself, then don't.
(this is not specific to postgresql, but everything in a production environment)
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.
I'm writing a programmer's text editor (yes another one) in Perl called Kephra, which is also a CPAN module of course and bundled with Module::Install. Recently I saw that Module::Build has gone into core, so if I switch I could reduce dependencies. Is there any other reason to switch?
We use Module::Build in our group.
The main reason is Easy Extensibility.
Module::Build allows you to do more with your build process in pure Perl through subclassing. If you want to do more using Module::Install, you have to have knowledge of how Makefiles work, AFAIK. Since you presumably already know Perl, this can be an advantage.
As you said, using Module::Build removes the dependency on an external make program, which can be viewed as a good thing.
However, the main cons that I can think of are:
Although Module::Build has hit core, not everyone will be using an up-to-date version of Perl. For users with older versions of the core, you will be creating a new dependency.
Lots of veterans (not necessarily Perl people) are used to the perl Makemaker.PL; make; make install paradigm, and can be thrown off by having Build.PL instead. Hopefully this isn't a big deal.
Module::Build has occasionally broken our builds when its functionality has changed because the documentation didn't cover an edge case which we were using. The edge case was then changed and documented, but we had to re-code our subclass to get our build to work again (this happened for us at the recent upgrade from 0.2808 to 0.3).
All that said, though, I still recommend Module::Build simply for the extensibility. If that's not an issue for you, you may be better off sticking with Module::Install.
The cud as already been chewed a bit on this before in "Which framework should I use to write modules?"
After spitting out the cud I decided to go with Module::Build but clearly different answers are possible! (though I've been happy with M::B so far).
Well, Module::Build is a pretty good module, it's supposed to be a drop in replacement for ExtUtils::MakeMaker, that is, replace the Makefile.PL by a Build.PL, which generate a Build instead of a Makefile. It was also meant as "simple things should stay simple, hard things should be possible".
Module::Install takes a different approach and generates a Makefile.
Also, don't forget that not everyone runs the latest version of everything :-)
I don't remember any comparison of those modules, but I think you could find a few things from Module::Build and Module::Install respective cpanratings pages.
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.