Extended x_ fields pertaining to dependencies outside perl toolchain

[kentfredric]

I wrote a Gist on this earlier, but @karenetheridge made me realise a gist is probably a bad format for discussion.

The full body of it is here: https://gist.github.com/kentfredric/a5c902e7d9fa801e4168 , but the top keys are:

• some kind of structure to convey binary executables as dependencies
• some kind of structure to convey header files and libraries as dependencies[1]
• some kind of structure to convey operating-system specific blocks/requirements ( ie: not in regards to prereqs, but in regards to "this dist wont work here" )
• and some kind of structure to covey "general" interpretations of "Interpreters".

That last one is basically a generalisation of the first, in terms of "This needs a C compiler of some description" or "This needs a C++ compiler" or "This might need a Java VM or a python runtime" etc, etc, but exists due to the obvious breadth of competing technologies for the same scope in this regard.

Also needs some proviso for "requires" vs "recommends" vs "suggests".

It is of course assumed that within the CPAN toolchain, all or most of these traits are impossible to be detected automatically ( especially with regard to versions of dependencies ), but the intent is to have these dependencies structured sufficiently so that a non-CPAN downstream who can manage Non-CPAN dependencies can make use of that data automatically ( as long as they implement the glue themselves ) ( But this is a secondary concern that seems natural once the first is addressed )

But the primary reason is of course to have metadata to help searching and discovery by consumers allowing them to weed out dists and dependencies they're not able to use, and allow any manual interactions they'd be required to complete more apparent.

[1] At this time, this is presently only expressed in terms of "needs library", work needs done here, but comparing with Devel::CheckLib aught to be useful.

[mohawk2]

This is an issue relevant to Alien::Base; I have opened an issue here: Perl5-Alien/Alien-Base#99

[DrHyde]

As well as being able to say unambiguously "this requires a C compiler" or suchlike, it would be nice to be able to say "this does not require a C compiler". Right now CPANdeps uses a heuristic for this, and will assume that you need a compiler if there exists, for example, a file called this-never-gets-compiled.c in the dist. That can easily lead to false positives.

[mohawk2]

I think another way would be to have an Alien module, eg Alien::Compiler::C, and depend on that. There could also be eg Alien::Compiler::C::gcc.

[kentfredric]

I think another way would be to have an Alien module, eg Alien::Compiler::C, and depend on that.
There could also be eg Alien::Compiler::C::gcc.

Personally that sounds like conflation of existing technology to mean new things it previously didn't mean.

It could well work that way, but that mechanism seems so easy to lead itself to being broken as soon as somebody decides they'll ship Alien::Compiler::C::gcc::ButMaintained

Then you've got a whole bunch of auxiliary concerns to weed out.

And that basically means using existing prereq structures to indicate non-perl requirements, and that's going to essentially be not much better than a heuristic.

It would probably work for CPAN toolchains due to the side effects being "If you require that and its not installable then it will fail dependency installation", but not hugely useful for downstream who can natively map meta keys to their vendor packages.

( And won't be hugely useful for varied complex searching tricks like might be useful to metacpan and friends )

[karenetheridge]

I think another way would be to have an Alien module, eg Alien::Compiler::C, and depend on that

That works fine during installation, when the client is determining prerequisites, but not for static analysis up front. The advantage of (not-requiring-code-evaluation) metadata is to facilitate this up-front analysis by things like distribution browsers (metacpan.org) or package managers. I don't think we should be assigning magic meaning to module dependencies (e.g. "if /win32/i is in the module name, then it requires a MSWin32 architecture").

[haarg]

See also #79