On the removal of some core modules
I’m sure most of the readers of this blog will have seen that both Module::Build and CGI.pm are up for removal from the Perl core. I thought I would toss my $0.03 (inflation) in on the matters.
Module::Build
This makes me very sad, but if I had a vote I guess I vote to remove it. Indeed, I hate ExtUtils::MakeMaker, I know nothing about Makefiles nor the magic that EUMM uses to precognitively manipulate them. I could as easily perform feats of magic with EUMM as I could perform actual feats of magic (that is to say, there is almost no chance). I am good at Perl, I can make Perl classes and subclasses do very cool things. I will continue to use Module::Build until there is something better available.
The sad thing is though, MB is bad too. It is extremely overdesigned and for all that the returns are less than good. The underlying object is near impossible to comprehend or extend. The worst part is, given that the object MUST be serialized, its one of the few objects I’ve seen that essentially cannot be! For this reason I have started a port of Module::Build based on Moo (cleverly called Moodule::Build) on my github. It’s VERY far from complete, but it is showing promise. Since the underlying object is a simple Perl hashref (as Moo objects are) serializing should be straightforward and adding accessors and subclass should be as easy as any other Moo(se) project is.
Leon has started his own Module::Build::Tiny and while admirable (and impressive) it cannot do XS yet. Until this is possible or until Moodule::Build or some other candidate emerges, EUMM and MB are the only way to go. I wish it wasn’t true but now that cpan clients can bootstrap build modules, there is no reason to have more than one in the core and MB is not a good example of the Perl we know and love.
That logic goes first so that I can say that:
CGI.pm
There is absolutely no reason that this module should still be in the core. I have seen arguments ranging from nostalgia to pleas that some companies do not allow any external modules to be installed. As to nostalgia, we can tip our hat to the past without propagating it further. To those companies who say that there may be no external modules (and I feel for their employees as I say this) you must be out of your mind!!
CGI.pm is no better than other web frameworks simply because it is in the core. Do you believe that because it is there it is better vetted or otherwise recommended by “the Perl people.” This is completely backwards!! We should discourage its use and do so by removing it. The crutch of Coredom has allowed it to live on much too long! If there must be some framework in the core (and no I don’t expect this to be Mojolicious, nor would I want its progress slowed down by being so), perhaps someone could make some minimal modern framework would could be included. Surely there must be some ultralight so-small-it-can-barely-work-but-just-does thing that could be added.
In one of the posts I saw, someone recommended that perhaps some of the constituent tools, those that are common in all frameworks, like escaping html entities, could be encorified. But please lets not encourage or even associate with the kind of code that we are trying to compel the world to forget about. Perl can reclaim some of its good name by showing off good code written in a modern way.
We have the tools lets not keep permitting newcomers and old-hat-haters to continue to see bad Perl lying around and indeed semi-blessed by staying in the Perl core.
As I delve into the deeper Perl magic I like to share what I can.
While I am not quite sure that I would eject it from core, do note that with configure_requires, Module::Build can always be installed from CPAN. Nobody is suggesting deprecating M::B altogether. Just kicking it out of the core since it’s not needed for bootstrapping the core and CPAN toolchain.
Wouldn’t it make sense to include Plack then instead of CGI? And I’d love to see cpanm included as well to let everyone install modules without requiring root privileges. Don’t know if there are consequences to this as I’m not involved in p5p…
There is always local::lib for local install
FYI, CPAN.pm detects if you don’t have write access to your Perl and can bootstrap local::lib for you.
This has been in the core since Perl 5.14.
You do have to re-run autoconfiguration if you have a legacy CPAN config file hanging around.
I think people are misunderstanding my point. I know that configure_requires and the other bootstrapping mechanisms exist, this is why I’m ok removing Module::Build from the core. I’m sad because I had hoped that MB would “win” and EUMM might eventually be on its way out.
Actually, I just released a version that does basic XS ;-)
Hi Joel
The problem with your choice of name, Moodule::Build, is that it looks like a typo, which just adds confusion, especially for beginners.
How about Install::Tiny?
Yeah, I have this problem quite often. Think of Moodule::Build as a working codename. I would think of something better before I would release it.
Hi Joel, could you say more about the serialization troubles for Module::Build? I don’t think I’ve heard that before, though it’s possible I’ve lost those brain cells at some point.
Hi Ken, the problems are essentially that it has to manually do it. The complications added to the “meta-object” needed to do so make extending that meta-object for other purposes difficult. That’s not really an answer, perhaps better to just say that the underlying hashref could really stand to be cleaner and the mechanisms for adding attributes needs a facelift too.
I guess I still don’t understand what you mean by the serialization issue. What has to manually do what? And what is the “meta-object” here? What “attributes” do you mean in your last sentence? I’m sure your points are valid, but I’m not following.
If I were to redesign M::B now (which is not out of the question, really) I would get rid of M::B::Compat (not because it failed, but because IMO it succeeded and is no longer necessary) and get rid of the by-platform class hierarchy.