Here's some meta fields I feel would be useful to have. Not that they can presently be acted on automatically by toolchains, but their presence would be simply useful to have from an indexing perspective.
We already have Devel::CheckBin and its partner Dist::Zilla::Plugin::Devel::CheckBin.
Something it obviously cant do is ascertain automatically what the version of that binary is, because there's no universal way to determine a binaries version.
However, having such metadata would be useful to a human who can validate it manually by whatever means.
// binary name : binary version (as per PM version spec)
{ 'x_needs_bin': {
'bash':'4.0',
'make':'>=4.0 <5.0'
}}And this feature can be added to the respective Dzil plugin as-is, defaulting the minimum version as 0
( more notes on versions later )
Again, this has limitations with checking, and its not obvious how to automatically determine versions, despite the fact we have CheckLib tools to check for it.
But code will invariably still need some libraries, and may need specific versions of those libraries, so having it in the meta is again useful for search and downstream purposes.
{ 'x_needs_lib': {
'glibc':'2.95',
'libm':'>=4.0 <5.0'
}}As with above, we can stuff this feature into the relevant dzil plugins today and everything using it will get it.
( more notes on versions later )
This one is a bit of a messier one because there's presently a demand for the data this could provide, and presently the primary way of doing that is via heuristics.
As the heuristics are fallible, an author may wish to be entirely clear about the kinds of language interpreters a dist needs.
It may occur that a dist can utilize a C compiler, for example, but it may not necessarily NEED it.
For this, I propose this:
{ 'x_needs_interpreter': {
'c':'88',
}}or similar. Its also assumed if an x_needs_interpreter is present, but empty then it will work as PurePerl, even if there is no compiler.
Though I'm conflated to as to how versions should work here entirely, because some things need only support for a given language standard ( hence why my example says "c:88" ), but may actually require specific version ranges of specific compilers. Ugh. ( more notes on versions later )
This is basically a metadata mapping of Devel::AssertOS and similar, making it apparent that a given dist works only on a specific operating system.
Again, this is hoped to be useful from a metacpan query aspect, allowing people to easily search for/exclude things that don't work on their OS ( and by proxy, weed out things that are dependent on things that only work on certain OSes )
This only seems to need to be an array at first blush
{ 'x_needs_os': ['Linux', 'MSWin32' ] }But I'm probably prematurely culling it and you may need some kind of version range support for different OSes ( like maybe it only works on windows 7!? )
Because all of the above inherently depend on various things outside perl scope, people are simply going to want/need to represent dependent versions in a manner that is entirely inconsistent with Perl versions. In fact, its going to also need a much broader range of version syntax than version.pm can ever be seen to support, such as versions with words and spaces in them.
Obviously we can't ever hope to handle such data respectably in perl space, and thus the data is obviously not intended to be consumed to automated tools to check the versions of things, and is instead, exclusively intended for human consumption.
But the space proviso makes me feel uncomfortable about using the normal ranged version spec for this, and a structured approach sounds necessary to communicate all the data unambiguously.
Whereas Perl normally needs single scalar version specs, we could potentially have:
{ key: {
depname: [
{ ">=": "Karmic Koala" },
{ "!=": "Babbling Bozo" },
{ "<=": ":þ" },
]
}}And that would be unambiguous to anything that had to parse it. ( Because it seperates perl conventions from dependency conventions entirely ).
You might ask "who needs to parse it". Well, Perl toolchain obviously doesn't at this stage as the toolchain itself has no way to manage non-CPAN dependencies.
BUT DOWNSTREAM LINUX VENDORS DO. So having more of this data up-font could plausibly aid in downstream packaging efforts, especially for source-based distributions like Arch or Gentoo who practically have to translate META.* into a recipie of some kind in bash.
Downstream vendors and add their own utilities that forge recipes from metacpan, and add rules for how to handle those fields where present, and apply conditional translations on the records provided for their dependencies in question ( normalising "app" versions to "vendor" versions in the process )
Obviously, all of the above names and structures are non-final and simply intended for discussion.
Obviously, at some point, somebody may wish to indicate "hey, we dont NEED this, but things will be better if you have it" ala recommends, suggests, etc. And "hey, that conflicts" is eventually going to turn up as well, and these concepts will cross much of the above things.
For instance, the "requires OS" might want to simply represent "Not windows, but anything else is fine", and I've left out support for that, because I'm an idiot and don't know how.
P.S. Comments on this gist don't notify anyone, give your comments here: Perl-Toolchain-Gang/CPAN-Meta#82
Or of you don't github: email me at kentfredric@gmail.com or ping me on irc.perl.org as kentnl