Re: Did the JSON module change?

[nilesOien]

So, as I noted above, when I installed JSON::XS, the behavior went back to what it was before, this :

my $data3;
$data3->{"num"} = "3";
my $addr = $data3->{"num"} + 7;
my $body3 = $json->encode($data3);
print $body3;

Prints this :

{
   "num" : "3"
}

What's the moral of the story here? Is it that I should always install JSON::XS? Or that I should type explicitly by doing stuff like :

$var = "" . $var;

Before sending stuff off to JSON? And/or did I just get a "bad" release of JSON for my purposes? Or all of the above?

[hippo]

What's the moral of the story here?

That's a very important question and I suspect you might end up with a hatful of different answers. Here's mine.

You said that the problem occurred after installing a new module via cpanm, which caused a lot of updates and that you are running with /usr/bin/perl on Centos 6. This means that you are using modules installed directly from CPAN via an automated installer (cpanm in this case) with the system perl. I'd say that the moral here is not to do that.

CentOS 6 has packages for both JSON and JSON::XS available via yum. It's therefore absolutely fine to use these with the system perl. However, as soon as you go monkeying around with non-packaged modules all bets are off.

Many monks here will contend that you should not use the system perl for any userspace applications at all and instead install your own perl from source, keeping the two perls entirely separate. This approach has its merits.

I'm an old hand and am (mostly) happy enough to use the system perl for my tasks but I am very careful not to pollute it with conflicting modules or to install newer versions of packaged modules into the system tree. Usually I will install modules by hand rather than use cpan/cpanplus/cpanm so I can see exactly what is happening at each step and even decide for myself which depedencies need updating, etc. On those rare occasions when using an automated installer is worth it I will ensure that the target directory of the installs is not into a system tree but into a user-controlled tree and so will no affect any OS use of the system perl and would be much simpler to back out if required.

So for me the moral is: don't mix the system perl with user-installed modules unless you are very, very sure you know what you are doing. If in doubt, install your own perl which you can mess up without banjaxing your system.

[nilesOien]

The TL;DR is : I suspect you're right.

Some more detail : For my own personal machines, I use Arch linux. This is VERY lightweight, to the point that you have to install a cron package to be able to run cron jobs. For my Arch machines, I've been using cpanm, because there are few to no perl modules installed by default. That seems to have worked OK, because cpanm winds up managing pretty much all the perl modules.

CentOS is a different animal. It comes with a reasonable number of perl modules installed by default. And we always wind up wanting some module that is not available in the system package manager (ie yum) yet. The one I wanted in this case was GeoIP2, which is pretty new. Up until now I've been using cpanm for anything not available in yum. But after this, I'm thinking the way to go may well be to download the source from CPAN and build by hand.

I'm certainly open to hearing about other, better management schemes. I'm relatively new to perl, for one thing. And what I've come up with as described here wasn't something I thought about too much, I just kind of fell into it. A workmate was also suggesting that building by hand may be the way to go.

Having my own separate perl... Hmmm.... Also something to think about.

Thanks!