Installing Term::ReadLine::Gnu on OS X, the easy way

If you try to install Term::ReadLine::Gnu on Mac OS X, you will ordinarily run into this unpleasantry from the Makefile.PL (which will likely end up in such as ~/.cpanm/build.log):

The libreadline you are using is the libedit library. Use the GNU Readline Library.

Here I will assume that you are using Homebrew and have installed GNU Readline:

brew install readline

Even so, you will get this error. This is because of how Homebrew installs Readline. Since OS X ships libedit as libreadline, Homebrew tries to avoid conflicts with system software by installing Readline as “keg-only” software – that is, it’ll install it within its package-managed filesystem hierarchy beneath /usr/local/Cellar, but it won’t link the libraries into /usr/local/lib, so that they won’t be visible to software that isn’t explicitly linked against it.

There is an easy and obvious way around this:

brew link --force readline
cpanm Term::ReadLine::Gnu
brew unlink readline

This makes Homebrew link the shared libraries into /usr/local/lib – which Homebrew ordinarily refuses to do for packages marked keg-only, like Readline is, hence the scary --force. Of course, all said and done, we unlink the package again straight away, so as to not cause conflicts. By doing this, Makefile.PL run from cpanm picks them up to link. We can confirm this:

otool -L ~/perl5/perlbrew/perls/**/Term/ReadLine/Gnu/Gnu.bundle

Its output should include something like the following line:

/usr/local/opt/readline/lib/libreadline.6.2.dylib (compatibility version 6.0.0, current version 6.2.0)

This /usr/local/opt is another Homebrew-ism:

$ ls -l /usr/local/opt/readline
lrwxr-xr-x  1 user  admin  24 14 Jul 04:53 /usr/local/opt/readline@ -> ../Cellar/readline/6.2.4

Note well that I actually have Readline 6.2.4 installed!

$ brew info readline | head -1
readline: stable 6.2.4

That means doing it this way is not only easier than the hard way found elsewhere on the web (here or there), it even allows me to brew upgrade readline without breaking Term::ReadLine::Gnu.

Backcompat is holding us back!

“Let’s free ourselves from the shackles and do something bold!”

I always cringe when I hear this battle cry. Isn’t that sentiment exactly what set the trajectory for the Perl 6 effort? Maybe it’s just been so long that people have forgotten.

But that is precisely how Perl 6 became such a amazingly long trek: once you remove the constraint of staying compatible, everything is suddenly, potentially, up for reconsideration. Then when you start changing things, you discover that changes in one part of the language also affect several other, remote parts of the language. So it starts with the simple desire to fix a handful of obvious problems in obvious ways… and spirals out as you make changes, and further still as you make changes in response to your changes, ever further and further.

At that point, it is exceedingly likely that the project will fizzle out before it ever comes to any fruition. But even if you have the perseverance, you face an uphill battle: unless your project has the community’s implicit blessing as the successor (as Perl 6 does, due to Larry’s presence), it is likely to simply slip into oblivion… the way Kurila did.

So yes: backcompat is holding us back… the same way that gravity is. It keeps us from floating away untethered.

Note that I’m not saying it doesn’t really hold us back. I’d love to travel to space easily, too! I still await Perl 6, as well.

But what I think, every time someone proposes to throw off the shackles of backcompat and go for it, is that we already have one Perl 6 – we don’t need another.

A decade in CPAN toolchain

Dave Cross:

I’m not going to object to Module::Build leaving the core. I’m sure there are good reasons, I just wish I knew what they are. I am, however, slightly disappointed to find that Schwern was wrong ten years ago and that ExtUtils::MakeMaker wasn’t doomed.

Schwern wasn’t wrong and MakeMaker remains doomed all these years later. It’s still around only because there hasn’t been anything to take its place. Module::Build looked like it was going to be that usurper – but didn’t work out.

Note that the reason that, between EUMM and M::B, M::B is the one leaving the core, is that EUMM is necessary to build the core and M::B is not. The reason for that is that no one bothered to port the existing MakeMaker-dependent infrastructure to Module::Build. And that never happened because M::B never gained the necessary features (XS support, mainly) fast enough for anyone to want to – because it wasn’t sufficiently much better than EUMM for anyone to want it enough to add the features.

However, EUMM is about as marginally maintained nowadays as M::B. Both are doomed, though their type of doomedness is one that’s accompanied by remarkable staying power. (Break-the-CPAN status tends to have that effect.) RJBS is on record that, should EUMM ever become unnecessary to building the core, it will make its exit stage left much the same as M::B is making now.

So… what happened?

It’s the things we know that just ain’t so

chromatic:

Posting grand pronouncements about what Perl 5 has to become or the new name it absolutely must adopt won’t do anything. That’s irrelevant.

“What people manning the booths at non-Perl conferences say is the perception of Perl among those outside the echo chamber is irrelevant; I know the REAL problems Perl is having: they are the ones we think mu…

Making DBI’s type info data usable for its quote method

I’m putting this here mostly as future copy-paste fodder:

my %sql_type = do {
    my $ti = $dbh->type_info_all;
    my $tidx = shift @$ti;
    my ( $n, $t ) = @$tidx{qw( TYPE_NAME SQL_DATATYPE )};
    map {; uc $_->[$n], $_->[$t] } @$ti;
};

Now you can say things like $dbh->quote( $latitude, $sql_type{'DOUBLE'} ). This is useful in situations where you cannot use placeholders, e.g. when generating some kind of fixture.sql file from CSV data.