in reply to Re: What's the best way to use Any YAML (not YAML::Any)
in thread What's the best way to use Any YAML (not YAML::Any)

That's a valid question. I'm not comfortable doing so for a few reasons:
  • Comment on Re^2: What's the best way to use Any YAML (not YAML::Any)

Replies are listed 'Best First'.
Re^3: What's the best way to use Any YAML (not YAML::Any)
by CountZero (Bishop) on Mar 17, 2014 at 19:35 UTC
    Does your application only rely on CORE modules? If not, you will have to assume that those non-CORE modules are installed with the users anyhow or they know how to install them. Little extra effort to install *some* YAML module too.

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

    My blog: Imperial Deltronics
      This particular distribution does depend upon non-CORE modules, but the YAML support is optional (which apparantly I haven't stated).

      I don't think that requiring installation of a particular package when an adequate alternative is already installed is a satisfying solution. I haven't attempted to code such a requirement into Makefile.PL (or cpanfile) and see how the various CPAN clients handle it. I should probably do so.

      The run-time code would still need to select amongst the installed packages, so the original question woould still be cogent.

      I wonder if some sort of capabilities database would be of help here. Modules providing capabilities would be registered upon installation. At run time the database would be queried to determine which modules were available; if one hadn't been loaded, one would be.