JSON::Any and the problems of metapackage dependency

Edit: Have a look at the comments to this post.

Recently, I released WWW::Mixpanel, which requires JSON encoding and decoding. Without significant thought, I decided to change my usage of JSON to JSON::Any, figuring that little bit of flexibility may be useful to someone.

Unfortunately, I found out the hard way that JSON::Any and dependencies don’t play nice. Looking at the JSON::Any metafile I saw that it doesn’t require any of it’s possible implementations to install before it installs properly. This means that on a number of test systems which didn’t have any JSON package installed, my dependency on JSON::Any meant there still wasn’t a JSON package available. I’ve been spoiled a bit by the great metapackage handling of debian.

Chatting in#distzilla, the feedback seemed to be that JSON::Any wasn’t useful anymore, and that there wasn’t really competition for JSON packages.

It was an easy decision for me to switch WWW::Mixpanel v0.02 to depend on JSON (and not JSON::Any), but it made me realize that I’ve got a bit of work to do looking into metapackages in perl (if such a thing is being supported), and also reminded me how great cpantesters is.

 

Post to Twitter Post to Digg Post to Facebook Send Gmail Post to LinkedIn Post to Reddit Post to StumbleUpon

About Tom
I work in a healthcare technology startup. These days, I attempt to code in Perl, and this blog is about the Wild Perl we write, startup life, and many other things.

11 Responses to JSON::Any and the problems of metapackage dependency

  1. gfx says:

    Why do you avoid JSON? JSON.pm is just a wrapper to JSON::PP and JSON::XS, so JSON::Any does not improve flexibility in the term of portability. Moreover, while JSON::PP behaves the same as JSON::XS, JSON::Any is sometimes not.

  2. Tom says:

    I don’t avoid JSON. Sorry if that was unclear. I’ve updated the text.

    I am suggesting that JSON::Any has dependency problems (or, rather, causes my module to have dependency problems since it didn’t behave as I thought it would). I will probably avoid JSON::Any in the future, and just use JSON directly. The new release of WWW::Mixpanel moves from JSON::Any to JSON.

    I was considering a bit the larger question, how should these metapackages behave in Perl? I haven’t looked into it, but at the very lease a package like JSON::Any should not be ‘installable’ without any supported implementations.

  3. gfx says:

    I see.

    As Sartak said (http://twitter.com/#!/sartak/status/52899266959650816), unconditional dependencies are sometimes
    problematic.
    I’d like a more flexible meta spec.

  4. Marc Mims says:

    I use JSON::Any in Net::Twitter. From its Makefile.PL (using Module::Install):

    sub has_json_xs () {
    my @order = qw/JSON::XS/;
    for my $provider ( @order ) {
    eval “require $provider”;
    return 1 unless $@;
    }
    return;
    }

    if (has_json_xs()) {
    requires ‘JSON::XS’ => 0;
    } else {
    requires ‘JSON’ => ’2.02′;
    }

    @order used to contain other options, but over time, they’ve been removed, so that could obviously be simplified.

  5. Tom says:

    Thanks! Is there a more standard way of doing this in the META file? I saw some tweets going around but I’m not sure if they were proposals or implemented.

    It may be better to bring something like this into META?

  6. Chris Thompson says:

    Though I don’t maintain it any more, I created JSON::Any back in the day in a much more “Wild West” atmosphere. There were several other JSON parsers like JSON::Syck, JSON::DWIW and JSON::PP none of which had supremacy at the time. It served a valid purpose in that era.

    Net::Twitter uses JSON::Any because I wrote that too. Marc took it over from me for version 3.x and I can’t claim to have written a single byte that’s still in use, but when I wrote the 1.x and 2.x trees I used JSON::Any because it was my module.

    I’m not involved enough anymore to have a strong opinion on the issue, but I’m not sure that JSON::Any serves much of a purpose anymore, other than as a guard against JSON.pm radically changing their interface when they go to 3.xx, like they did from 1.xx to 2.xx.

  7. Tom says:

    Hi Chris,

    Thanks for your reply and background on this. What do you think abut the META functionality, as some way to support metapackages like JSON::Any by requiring at least one concrete implementation for successful install.

    Above Marc pointed out the he uses some (I presume) hand-written code in the Makefile, but it would be better to have more formal metapackage support in the META file perhaps?

  8. Hey, I saw you mention this in #distzilla and while I agree with the advice you were given, I think you came away with the wrong assumption.

    JSON::Any tries the hardest it can to make sure that some JSON file is installed. As you have discovered there is no (that I know of) static way to define a complex dependency like “any(JSON JSON::XS JSON::DWIW)”. The logic that Marc presented from the Net::Twitter Makefile.PL is very similar to the logic already in the current JSON::Any Makefile.PL


    unless (has_json) {
    requires 'JSON' => '2.02';
    }
    else {
    feature 'JSON',
    -default => 0,
    'JSON' => '2.02';
    }

    where has_json is defined just before and is a simple check to see if one of the non-deprecated backends is installed.

    I’m more than welcome for someone to present me with a better solution, but one didn’t exist the last time I edited the build system for JSON::Any.

  9. Tom says:

    Thanks for your reply.

    I wonder if cpantesters script has trouble with my Mixpanel (v0.01) module or with JSON::Any? It was those types of failures that originally made me go to IRC asking if I should force a JSON implementation in place.

    It looks like some test runs either don’t install a concrete JSON implementation (which seems strange given your makefile code), don’t include it in INC, or have installed and removed it, but left their JSON::Any around.

    Failing: http://www.cpantesters.org/cpan/report/54d76f2c-5a4c-11e0-9835-8e99bcb8094c
    versus
    Success: http://www.cpantesters.org/cpan/report/64fb7952-59e3-11e0-b6da-c8181257ed08

    If some uninstall or INC problems are popping up during cpantesters runs, that may inform the META discussion.

  10. Chris Thompson says:

    I defer to Chris Prather below, he took JSON::Any over and will have a clearer understanding of how the build system works.

  11. Chris Prather says:

    I am traveling for a week starting tomorrow but if you drop me a note on IRC (/msg perigrin) I will try to take a look as soon as I can. I have also uploaded a new version of JSON::Any that explains better it’s place in the world.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>